f.zz.de
Here is another nice example of a user correcting a bad turn restriction.
Red was the old route, Green is the new one. These are pretty common issues in
OpenstreetMap today. Mappers have a hard time understanding and maintaining
turn restrictions as they are hardly visible. So correction of these types
of issues is more or less just by accident.
Fixed in:
https://www.openstreetmap.org/changeset/156654745
Heute über Bielefeld Mitte.
In Münster mit Rhea. Politisch stabile Kapelle.
Gestern war ein schöner Tag um Kurven zu malen. Fast den ganzen Tag durchgehend
Sonne auf den Modulen.
Hier kann man schön sehen wie die Ausrichtung der Module in die verschiedenen Himmelsrichtungen
den gewünschten Effekt hat. Die Module kommen zeitversetzt je nach Sonnenstadt.
Ziel ist es ja viel Morgens und Abends zu haben um fast eine eckige Gesamtkurve zwischen
Morgens um 8 und Abends um 8 zu haben in der man den Strom selber verbrauchen kann.
Leider sind die module für früh Morgens und spät Abends immer teilbeschattet irgendwann.
Nachdem ich ja schon ein paar Wochen mit Algenbildung in der Bewässerung kämpfe
die immer wieder sie Silikonschläuche zusetzt hab ich jetzt mal wieder was neues
probiert.
Ursprünglich habe ich eine "Mindestaktivierungszeit" für die Pumpen eingebaut. D.h.
die drücken das Wasser über ein paar Stunden da raus so das das nicht zu lange
in den dünnen Schläuchen steht und durch die Sonne erwärmt wird.
Leider hat das wenig Erfolg gezeigt. Immer noch Bildet sich graubraunes
festes Algensubstrat in den Schläuchen. Wobei mir immer noch nicht klar
ist WO sich das genau bildet. Wenn ich es merke sind die Schläuche zu. Es
könnte auch sein das das angesaugt wird aus dem Kanister.
Im Kanister selber schwimmen auch kleinere "patches" so das ich jetzt es mal
mit "Filtern" probiere. Die patches sinken nach unten, der Schwammbestandteil
schwimmt oben. D.h. wie ein Skimmer nehme ich eher Wasser von oben, und ich
ziehe keine Bestandteile ein.
Stay tuned.
Okay... Die Verpackungen der 90er können dann mal weg.
Mein erstes Handy. Siemens S4 ....
Nein ... Ich hab nicht ALLES aufgehoben.
Ein Gedanke war ja noch das die Aufständerung mit Beton ökologisch ja gar nicht
so schlau ist weil Zement beim Brennen Energie verbaucht.
Also mal recherchiert.
https://www.baunetzwissen.de/beton/fachwissen/herstellung/energie-in-der-zementherstellung-8201021
Ich brauche ~300kg Beton - Nach dem Artikel werden aus 1t Zement 2.8t Beton
also sagen wir ein drittel. D.h. ich brauche 100kg Zement.
2.8 Mio Kilojoule sind ~777kW/h für 1t Zement. Also braucht das ganze 77kW/h
für die Herstellung. Dazu kommen die angegebenen Elektrischen Energiemenge von
111kW/h.
D.h. der Zement für die Aufständerung braucht rund 90kW/h für die Herstellung.
Diese sind schon erzeugt noch bevor die Aufständerung unter den Modulen ist.
Für die Aufständerung des Balkonkraftwerks hatte ich ja eine Aufständerung in
Beton konstruiert und gieße die gerade. Die waren bisher auf 35° Aufständerung
Designed was in Deutschland so in etwa den besten Ertrag liefert.
Ertrag spielt aber ja gar keine rolle weil ich ja nur den Eigenverbrauch
optimieren will. Damit brauche ich früh in den Morgenstunden und bis spät
in den Abend möglichst Leistung. Damit sollten die Module eigentlich fast 90°
haben was bei mir auf dem Flachdach eher nicht so einfach machbar ist wegen
der Windlast die ich nirgends los werde. Ausserdem ist die Sicht zum Horizont
nach Ost/West nicht so optimal so das mit 90° eh nichts bringen.
Also mal rumgespielt wie weit ich denn komme im Winkel. Dabei hilft FreeCAD.
Hier ein Screenshot mit dem Macro "CenterOfMass" das mir den Massenmittelpunkt
angibt. Für alle Elemente die Dichte angeben d.h. Beton mit 2.3t/m³ und dann
sieht man schön das der Massenschwerpunkt schön in der Mitte liegt. Für meinen
Geschmack noch zu hoch.
Also mal sehen.
Seit 3 Monaten habe ich mehrere Bewässerungscomputer laufen die mit
Peristaltik Dosierpumpen Pflanzen nach dem Bedarf, also der
Bodenfeuchte, bewässern. Ich hatte immer mal wieder so den Eindruck
das die Sensoren mit der Zeit unzuverlässiger werden, vor allem "zu wenig"
anzeigen - was in diesem Fall heisst - "Jaja - Boden ist feucht genug".
Gleichzeitig zeigten die Pflanzen aber eher Wassermangel, und die Töpfe
waren relativ leicht. Also irgendwas passte da nicht.
Des Rätsels Lösung war dann das hier. Die vermeindlichen Bodenfeuchte
Sensoren sind nicht Wasserdicht. Die Feuchte zieht von der Seite in das
Platinenmaterial und greift sowohl den Lötstoplack wie auch das
Kupfermaterial an. Da das kapazitive Sensoren sind wird das Dielektrikum
dann leitend, was eigentlich isolierend sein sollte. Damit verliert
die Kapazität an wert.
Ich habe jetzt die nächste Generation in Kunstharz getaucht um das zu verhindern.
Ich bin gespannt wie lange die dann halten.
Da ich ja Platz und die Möglichkeit habe musste ein Balkonkraftwerk
her. Damit die Ausbeute der Module besser wird ist es sinnvoll
diese entsprechend in die Himmelsrichtungen auszurichten und diese
Aufzuständern so das der Winkel zum Horizont besser wird.
Damit sie auch nicht vom Dach geweht werden ist es dazu notwendig
ein bisschen Gewicht an die Module zu hängen.
Beides miteinander verbindend hab ich das ganze als Betonform
konstruiert, gebaut und gegossen. Aktuell 35° was für Morgens
und Abends zu wenig ist, aber besser als nichts.
Vielleicht kommt als Form nochmal irgendwas 50°+ raus für die Abend
und Morgenmodule.
Ziel ist es ja nicht einen hohen "Peak" ertrag zu erwirtschaften, sondern
möglichst den ganzen Tag >400W zu haben um die Grundlast vom Haus abzufedern.
Für die Einspeisung des Peaks bekommt man ja keinen Cent.
Das geht natürlich im Hochsommer total einfach weil selbst das Streulicht
reicht. Aber für die Module nach Osten und Westen, d.h. Sonnenauf und
Sonnenuntergang möchte man fast 90° haben.
Jedenfalls sind mittlerweile die ersten kWh erzeugt und jetzt im Sommer
speise ich im Mittel mehr Strom ein als ich beziehe. D.h. das Haus
ist Strompositiv. Nur leider stimmen natürlich die Zeiten nicht. Abhelfen
würde da nur ein kleiner Speicher. Vermutlich würden 2-3kWh reichen
um die Nacht abzudecken.
Jedenfalls wieder ein schönes Bastelprojekt was mich schon ein paar
Wochen beschäftigt, und auch noch beschäftigen wird.
Es müssen noch 4 teile gegossen werden, und die Nachbarn scharren auch
alle schon mit den Hufen.
Trockenzeit aktuell ~36-48h je Betonteil - also wird das noch ein paar
Tage dauern.
Kostenkalkulation
- 3 Sack Beton ~14€ für 2 Betonteile
- 4 Schrauben M8x80 Edelstahl 2€
- 4 Solarklemmen 6€
Sind 22€ für die Aufständerung eines Moduls.
Wenn man drauf verzichtet die in unterschiedliche Richtungen aufzuständern dann
kann man das mittlere Betonteil für 2 Module nehmen. Es sind jeweils 2 Löcher
in der Gießform vorgesehen. Dann kommt man mit 37€ für die Aufständerung aus.
Mit Message.
Auf der A33 bei Hövelhof und noch 2 stops. Was macht Amazon da? Krass. Fährt da einer aus Borchen extra für mich los um mir meine Silikonschläuche zu bringen?
Heute am Marktkauf. Ein schöner Transit. Das wäre so mein Oldtimer Traum.
Heute vor einem Jahr wurde der OSM Note 2615742
eröffnet und hat eine kleine Tradition und hat sich fast zu einem Meme entwickelt.
Also zum Geburtstag am 9.4. um 19:25 haben sich
Hartmut Holzgraefe,
niederfeld_16 und
ich
uns am Note getroffen und gequatscht und haben auf den Geburtstag angestoßen.
Es war sehr nett einfach rauszukommen und die fellow OSM Mapper zu treffen.
An der Situation vor Ort lässt sich nichts ändern. Das ist einfach ein Minenfeld
und wir bei OSM können das nicht abbilden. Ein access=no/private ist da das
einfachste.
For a very long time i have been running a tasking manager 2 instance
for me and the regional community to fix and revalidate
stuff around here. TM2 had a very short and reliable documentation
and you could set it up in 5 Minutes without ANY deeper knowledge of
python, node or postgres.
I had been staying at TM2 as all newer versions failed
for me to build or deploy easily.
Today - another try - current git TM.
And it fails again.
It does not build on Debian/Bookworm as it is not compatibly
with python 3.11 which is the obvious default version on
Debian/Bookworm.
So fixing that in pyproject.toml and setting the
requires-python = ">=3.11,<3.12"
And then running
pdm lock --update-reuse
The documentation even misses the point in better creating a venv
which i obviously did beforehand.
Then i have the backend installed and when you get the idea
that your postgres database needs the postgis extension enabled
and also change your TM_LOG_DIR= to something writeable (I dont have a /home/appuser)
you can populate your database with flask db upgrade.
Then going back to trying to build your frontend you need to make
sure to install yarnpkg on your system. Debian has a yarn
binary from cmdtools which is confusing at first.
Then replace all yarn executions by yarnpkg.
Then you get to the point where the frontend starts to build
and then horribly fails because of npm requirements
beeing outdated and failing to build with newer openssl
having fixed issues:
Error: error:0308010C:digital envelope routines::unsupported
When you try to look for it people suggest to downgrade nodejs
which is:
"We have fixed a security issue and your project does not build? Downgrade to a version pre-security-fix"
WTF? This hipster tool bubble is so doomed.
As i am a sysadmin, C, C++ and perl programmer and not into JS, npm, yarn, nodejs,
react and whatever "modern tools" are beeing used, i stopped here once again.
And NO - docker is not the solution when the requirement is to downgrade to less secure
versions of the dependencies and just hide it away. How are you going to fix these
issues in your production environment other than ignoring it?
Das Baujahr des Hotels kann man am Fahrstuhl erkennen. Besser ist aber das Telefon.
Nachdem ich aus dem OpenData Portal für Schleswig-Holstein ~17000 Dateien
gezogen habe und das ALKIS lokal in einer PostGIS wieder zusammengepuzzelt habe
fällt auf das es spannende Löcher im ALKIS gibt.
So sind die militärischen Flughäfen Jagel und Husum-Schleswig nicht im ALKIS
Export mit vorhanden. Aber es ist mitnichten so das alle militärischen Anlagen
ausgenommen sind. So ist die "Wehrtechnische Dienststelle 71" in Kiel
komplett vorhanden.
Jedenfalls habe ich jetzt einen Hausumring export und kann das Alkisdiff SHS produzieren:
https://osm.zz.de/dbview/?db=alkisdiff-shs&layer=buildingnotinosm#54.4581,9.52897,15z
Lübeck ist sehr hübsch. Sie haben auch noch eine große Menge Gaslaternen die auch sehr schön sind.
I have been with OpenstreetMap for 15 years. I started with an empty white
nothing and early decided on mapping in a very systematic way like "All
maxspeeds", "all building", "all traffic lights" and did that early with tools
like Mapillary by first making Photos of all streets.
I also started using the data for civil engineer planning for Telecom
infrastructure. For traffic simulations and other interesting purposes.
For 10 years i am running Quality Assurance for routing by calculating
~250k routes every 30 Minutes and watch for temporal changes in those routes.
So i guess i have a deep understanding of tagging schema. I think in
hierarchies and dependencies of objects and their tagging.
Lately (for the past couple of years) i see people in for example Germany
going into Micromapping. Every little stone, hedge, light, knob or straw needs
to be mapped in extreme detail. Per se i dont see a problem in that undertaking.
The problem that now arises all over the place is that established tagging
schemata are getting "abused". For whatever reason half-way usable tags are
beeing re-used for micromapping for "physically similar" objects although these
objects have a completely different sematic meaning.
This post was motivated by the abuse of highway=traffic_lights. Pure pedestrian
crossings have been described with a highway=crossing crossing=traffic_lights
for ages. Now people start to map additional highway=traffic_lights at every
simple pedestrian crossing. So we went from a simple node to a node triplet with
additional highway=traffic_lights.
As these 2 crossing types have completely seperate semantic properties this
makes whole crossings indistinguishable from pure pedestrian crossings.
As routing profiles make use of these different semantic properties in estimating
the delay of a traffic light this basically breaks these estimations, and worsens
routing.
Turning on to a discussion on why people start doing that always ends in
the data consumer should fix his software
without really explaining how people are going to put a tangent to a point. Once
removed information can not be brought back.
As a resume:
Micromapping by abusing existing tags breaks semantic meaning of data.
I think in the long run this "mapping for the renderer" and missing thinking in
semantic meaning will "kill" Openstreetmap, or better, reduces the data usability
for something else than a "pretty, colourful map".
I also think think this attitude of "somebody else must fix it" is also the best
argument for the existence of Overture Maps.
Nachdem die Temperaturen nicht mit "draussen schrauben" vereinbar waren ist Henri in die Garage umgezogen. 3 Tage quasi non-stop Dinge instandsetzen. Bremsen, Ölwechsel, Nebelschlussleuchte, Kennzeichenbeleuchtung, Armaturenbrett etc.
Dann schnell zum TÜV. Eigentlich sah es auch gar nicht so schlecht aus bis auf das die Fahrzeugidentifikationsnummer fehlt. Es gibt ein Typenschild, es gibt Papiere, aber da wo die Nummer eingeschlagen sein sollte ist ein Reperaturblech.
Ein paar hilfreiche Schrauber von Weka konnten dann weiterhelfen und eine neue Nummer einschlagen, nur fehlt die offizielle Bestätigung das das wegen Reperatur woanders eingeschlagen werden musste.
Also gibt es noch keinen TÜV.
Jetzt geht's erstmal an das Garage aufräumen
When putting in barriers like this barrier=bollard you might want
to go back and check the routing.
In this case at least we as OpenStreetmap using OSRM send
through traffic through this farmyard.
I am currently extending my RouteQA slowly around Northrhine-Westfalia
in Germany. I now extend to areas where mappers extensively mapped
lanes=1 instead of lane_markings=no which breaks routing in a lot
of subtle little ways at least for OSRM.
lanes=1 means it is not possible for two way traffic to pass each other
without going to the curbs or shoulder. This causes the default OSRM car
profile to assume half the average speed of the maxspeed.
So a road with maxspeed=50 and lanes=1 without any oneway tagging
is assumed to have a max average speed of no more than 25km/h.
Thats a pretty good assumption if its really too narrow.
Now if you have a tertiary or better road in city limits with
a maxspeed of 50, and a parallel road with 30km/h the smaller
side roads suddenly is faster because 30km/h is better than 25km/h.
So please stop tagging lanes=1 for roads which are wide enough for
passing traffic without getting into each others way. The correct
tag is lane_markings=no
In the default OSRM profile lane_markings=no has no penalty at all
which IMO also needs fixing which why i opened
an issue for the OSRM backend
Nevertheless - be careful with lanes=1 - its a hefty penalty for
routing.
This is an example of broken routing in Borken near the Dutch border
from my QGis view on the RouteQA.
As one can see the Butenwall is used but also the parallel Wallstraße. The
Wallstraße would be used in ALL cases if it would not be a oneway.
The Butenwall as a secondary should be MUCH better - but it (was) tagged
with lanes=1 as there are no lane markings. As a secondary it
is wide even for trucks to pass each other without issues.
Erst ganz ruhig und minimalistisch mit Rhea und Dad ... Ein Rotwein zur Feier des Tages.
Dann Turmblasen und Weberei, wobei letzteres eher mit Jungvolk voll war.
In my RouteQA initiative i mostly care about temporal changed routes,
e.g. routes which change because mappers make changes to the map data.
I try to catch mistakes early e.g. reversed oneways, broken turn
restrictions, access restriction and the like.
When i add "clusters" e.g. areas i check routes within, i also try to fix
the most obvious routing mistakes e.g. shortcuts or rat-race roads.
Almost all cases are caused by sparse tagging. Mappers focus
on the higher class roads which carry extensive tagging about
maxspeed, lanes, lane_markings, surface and the like. All
the small side or rough roads lack these information and suddenly
the side roads are mathematically better. This is probably true for
a single vehicle, but considering we direct most of traffic to these
smaller roads these roads will never cope with the traffic we send.
The first thing is that i fix the sparse tagging by iterating on the side roads
and fill the gaps. In 98% of the cases this will fix shortcuts or rat-race
issues. But there are hard to fix cases i up to now had no clue how to fix.
I started a thread on
osrm-talk
and the routing mailinglists which basically returned "unfixable", "you need to
fix the engine", "the side road is better so what", "this is easy" or "unfixable
without mobility or live data".
I don't buy the "mobility or live" data as thats not for hobbyists, or non
profits. You need money to buy and its a huge undertaking to process
that huge stream of data.
The other options are assuming "something magic happens".
So i sat down and made a "Proof of concept" inventing a tag for customizing the
route weight and using that in an OSRM profile.
The tag i used is route_weight_factor:motor_vehicle which shall contain a
float from -0.8 to +0.8.
This then will be multiplied with the calculated weights from the physical tags
like lanes, lane_markings, maxspeed, road class etc.
So a -0.8 means we go down to 20% of the speed of the road.
Here is the git commit for the car profile change:
https://github.com/Project-OSRM/osrm-backend/commit/c199019fefc8b0d31e45a6599c0a7f1343af2cfe
This enables to fix issues like this:
The small side-road is barely wide enough to fit a car. Sending 2 way traffic
through there is definitely not an option. There is no legal restriction so we
cant really exclude it. So we need want to make it worse than the way around.
It shows on how mappers would be able to influence and fix routing in case
something like this would get an established tagging.
Also it would allow us to respond to public bodys e.g. city councils
asking for routing changes in OpenStreetMap.
Continuing the OpenstreetMap antipattern blogpost series here is another one.
This is a single landuse, spanning 12km. It follows streets in
a tree like shape.
As for the obvious, this kind of landuses are prone to break. People tag highway tags on them,
move them around by accident, and as they ALWAYS span more than your edit area nobody really
is brave enough to do something with them. So this way/landuse stayed in the Database for 12 years,
despite beeing semantically nonsense.
In this case we have a landuse=grass which is in itself a broken tagging as its not a use in itself.
The Wiki article about landuse=grass tells
you that most likely your tagging is wrong and you should use something else.
In this case the mappers intention was to not let any gap show up on the map between roads
and landuses. We know about mappers glueing landuses to roads which is a semantic error in
the OSM dataset as linestring object do not have a dimension as areas do have. This is another
hack to eliminate the gaps between roads and adjacent landuses.
Nevertheless this is broken. The road itself is never a landuse=grass, its not even
a landcover=grass, its tarmac or asphalt. Adjacent to the road there are the shoulders,
which may carry grass from time to time, or a ditch which has grass on its banks.
Concerning the tracks, these carry a surface tag themselves so this landuse
just trys to map for the renderer to get gaps in the background of the map
closed.
So the antipattern is to not hack OSM data to do background filling. Not with glueing
landuses to linestring objects, not by filling these with huge landuses as a last resort.
As long as we dont have a language/tags to fully describe road areas (which the shoulder
and the ditch belong to) we should not hack around and fake objects to close gaps.
Und noch eine alte Ape als Teileträger.