Diary Entries in German
Recent diary entries
Beim autofreien Sonntag Mai 2023 dort langgeradelt. Eine Karte gibt es hier: https://www.radwanderland.de/radrouten/Wied-Radweg Vergleiche mit: https://osmrm.openstreetmap.de/relation.jsp?id=544300 und: https://cycling.waymarkedtrails.org/#route?id=544300&type=relation
Dabei habe ich Fehler festgestellt und denen gemeldet:
Die offizielle Route von der Internetseite entspricht nicht immer den Gegebenheiten vor Ort. Beim Mappen kann man sich also auf die offizielle Route nicht verlassen.
beim autofreien Sonntag habe ich mir den Wied-Radweg etwas genauer angesehen und mit der Karte verglichen in: https://www.radwanderland.de/radrouten/Wied-Radweg
Dabei habe ich die „Details der Routenführung“ aktiviert.
Aber es sind mir einige Differenzen aufgefallen:
Burglahr bis Peterslahr (Heckerfeld, Kur-Kölner Straße, Auf dem Heidstock, Kirchstraße): Eingezeichnet grün für “Streckenverlauf abseits von Straßen (z.B. auf Wirtschaftswegen)”, aber das sind Straßen, wenn auch ruhige, richtig wäre also nach Ihrer Legende hellblau für “Streckenverlauf auf Straßen ohne Radweg mit geringer Verkehrsbelastung”. (Bild 01)
Der Tunnel hinter Peterslahr ist gesperrt wegen einer Baustelle. Auch wenn das eine temporäre Maßnahme ist, eine Internetseite anzupassen geht schneller als diese Baustelle fertigzustellen. (Bild 02)
Hinter Mettelshahn führt der Radweg laut Karte auf der L269 bis zum Kreuzbruderweg beim Kloster Ehrenstein, dann links über die Wiedbrücke zum Rad- und Fußweg auf dem alten Bahndamm. Laut Beschilderung führt er aber gleich hinter der Mettelshahner Schweiz bei einem Parkplatz schräg hoch auf eine Wiedbrücke und den Bahndamm. Siehe Bild 03 und 04: Wegweiser bei Abzweig zum Kloster - Wied-Radweg führt geradeaus weiter.
Der Sinn der Streckenführung in Neustadt südlich der Bahnhofstraße erschließt sich mir nicht. Dort führt der Radweg rechts (nördlich) der Wied über einen Holperweg “In der Kirchwiese” neben einem Gewebegebiet. Viel angenehmer ist es, schon vorher bei der Berschau den Bahndamm zu verlassen und auf einem geteerten Weg links der Wied am Naturschutzgebiet Berschaue vorbei bis zur L255 zu fahren. (Bild 05)
In Neustadt (Kirchplatz, Wiedtalstraße, Raiffeisenstraße) ist der Weg grün eingezeichnet, aber das sind Straßen, richtig wäre also hellblau oder gar dunkelblau, weil die Straßen zeitweise viel befahren werden.
Krummenau bis zum Wendehammer ist ebenfalls eine Straße, auch hier ist grün falsch, richtig wäre hellblau.
Bei Steeg ist ein Radweg neben der L255, hier kann also rot eingezeichnet werden statt blau. (Bild 06)
Das Gleiche gilt für Kodden ab der Bushaltestelle: eingezeichnet grün, richtig wäre hellblau. (Bild 07 und 08)
Hinter Kodden führt ein schöner neuer Radweg über eine Wiedbrücke und dann an der L255 entlang. Dieses Wegstück, unten an der L255 entlang, ist fälschlicherweise hellblau eingezeichnet, richtig wäre hier grün, denn an dieser Stelle ist das ein von der L255 getrennter Radweg. (Bild 09 und 10)
Die kleine Brücke bei Oberhoppen ist jetzt gesperrt, deswegen müssen Radfahrer jetzt ab der L255-Wiedbrücke vor Oberhoppen auf der L255 weiterfahren. Das wäre hellblau oder dunkelblau einzuzeichnen. Ebenso hinter Oberhoppen, rot für “Streckenverlauf auf Radwegen an Straßen” ist hier falsch, es gibt hier keine “Radwegen an Straßen”. (Bild 11)
Abseits dieses Gebietes habe ich mir die Wege nicht angesehen, aber ich fürchte, da werden noch mehr Fehler drin sein.
Letzte Woche war ich auf der Velocity in Leipzig. Alles darüber hier:
http://warumichradfahre.blog/2023/05/16/ich-war-dabei-velocity-2023-in-leipzig/
Bin in Leipzig auch einiges an Rad gefahren, vor allem mit Rädern von Nextbike und Swapfiets (siehe http://warumichradfahre.blog/2023/05/12/swapfiets/).
Dabei war OSM total hilfreich. Mit der Android App OSMAND+ fand ich Wassertürme in Leipzig, die ich mit keiner anderen “Standard-App” wie Komoot z.B. gefunden hätte. Total toll.
Erweitert: https://osm.org/user/cyton/diary/401173
Der Ablauf ist sehr ähnlich geblieben, ich schildere aber nochmal alles, den vorherigen Eintrag muss man also nicht gelesen haben.
Interessante Layer
Straßenbäume, Anlagenbäume
Sind zwei separate Datensätze, sind aber identisch aufgebaut. Leider fehlen teils Bäume, teils an der falschen Stelle, teils um eine Nummer versetzt, oder kombinierte Fehler. Teils fehlen neue Pflanzungen, oder gefällte sind noch zu sehen. Leider haben die neuen kleinen Bäumchen scheinbar nie eine Nummer, das dauert wohl einfach immer.
Straßenbefahrung 2014
Ich habe mich auf die Bäume und anderes Straßenmobiliar konzentriert. Es gibt im “Straßenbefahrung 2014” Layer mehrere interessante WMF, aus denen ich Daten ziehen kann, um diese vor Ort zu prüfen.
- Gebäudeeingänge, Zeigen wo ein Gartentor oder eine Tür in einer Häuserfront ist, liegen logisch gesehen also auf der Flurstücksgrenze.
- Abfallbehaelter Muellbox, ist wohl nur
amenity=waste_basket, hab aber noch nicht genug davon gesehen. - Sitzbank, sicherlich nur
amenity=bench - Kabelkasten und Schaltkasten, scheinen alle
man_made=street_cabinetzu sein, egal wofür oder von wem. Wenn eineanzenthalten ist, scheint diese die Anzahl Türen bzw. die Breite anzugeben. - Poller,
barrier=bollard, auch zu wenig gesehen bisher, um mehr dazu zu sagen - Gehwegüberfahrt, Polygon von Einfahrten, also
area:highway=service+service=driveway. Wenn diese mehrteilig sind, geht die Pflasterung des Gehweges darüber, wenn nicht, ist die Pflasterung der Einfahrt durchgehend. Was ich hier in Josm mache ist parallel zur Fahrbahn die inneren und äußeren (also an der Fahrbahn und Flurstücksgrenze) Knoten nehmen und dazwischen einen neuen setzen, diesen dann zentrieren dazwischen, mittels shift+b. Diese zwei Knoten verbinde ich zu derdriveway-linie, welche ich zu Zaun/landuse=residentialverlängere, sowie zur Straßenlinie. Ans Ende kommt noch eine potenziellebarrier=gateNode, aber das mache ich meist vor ort in Vespucci.
Alle diese sind aber mit deutlicher Vorsicht zu genießen, da die Daten halt schon etwas älter sind.
Öffentliche Beleuchtung
Laternen, die Daten sollten selbsterklärend sein.
Datenaquise
Erst die Datenlayer vom geoportal Berlin in Qgis anzeigen, dann diese herunterladen als kml.
Dann die kml in JOSM öffnen, das dauert erstmal etwas. Die kml Datei dann als .osm Datei speichern.
Die .osm Datei mit meinem Python-Script umformen. Dort ändere ich die tags und metadaten, damit sie dem OSM standard entsprechen, bzw. als zu löschen markiert sind.
Diese veränderte .osm Datei wieder in JOSM laden, und source=* und source:date=* hinzufügen, sowie natürlich fehlende Haupt-tags wie natural=tree, highway=street_lamp, oder man_made=street_cabinet etc.
An alles tagge ich außerdem ein fixme=check if exists, damit Vespucci das anmeckert und ich nichts übersehe, das lösche ich dann, wenn etwas wirklich existiert, oder aber das gesamte Objekt wird gelöscht, da es nicht existiert.
Diese Datei dann auf mein Android Handy befördern, und dort in Vespucci öffnen.
Vor Ort alle ref und etwa die Position prüfen.
Meist sind Bäume korrekt oder einige auf einmal falsch positioniert.
Dann etwaige an den Bäumen oder Laternen fehlende Nummern mit ref:signed=no merken.
Eventuell auch falsch-nummerierte, bzw. Unstimmigkeiten zu nummerierten Objekten allgemein in note=* an dem Objekt erfassen, damit in Zukunft niemand unnötigerweise verwirrt ist.
Für Einfahrten, kleine Verbindungs-Gehwege, Einfahrtstore sowie Gartentore messe ich mit StreetMeasure die Breiten. Das App-wechseln ist recht nervig, am liebsten hätte ich eine Möglichkeit das aus Vespucci Direkt aufzurufen, so wie Streetcomplete das auch tut.
Wenn man genug hat vom Herumlaufen, die modifizierte Datei in Vespucci wieder abspeichern.
Zu Hause dann die Datei aus dem Handy laden und in Josm nachjustieren.
Hochladen.
Ich bitte um Verbesserungen für diesen Workflow. Am liebsten hätte ich etwas das StreetComplete näher kommt, Vespucci ist sehr umständlich zu Bedienen.
Seit einigen Monaten mappe ich wieder 3D Gebäude, hier einige meiner Werke:
Haus der Wirtschaft, Selm:
https://demo.f4map.com/#lat=51.6951653&lon=7.4658714&zoom=20&camera.theta=63.352&camera.phi=142.094
Maggi Werk, LH:
https://demo.f4map.com/#lat=51.7703899&lon=7.4232912&zoom=18&camera.theta=76.849&camera.phi=33.35
Ascheberg Kirche und HIT Markt:
https://demo.f4map.com/#lat=51.7896585&lon=7.6180370&zoom=18&camera.theta=65.913&camera.phi=-96.83
Kreuzkirche Oelde-Stromberg:
https://demo.f4map.com/#lat=51.7997369&lon=8.2031816&zoom=19&camera.theta=52.212&camera.phi=-44.404
Wie findet man eigentlich den Beitrag den man revertieren möchte, wenn man nur weiß wo er räumlich ungefähr stattgefunden hat?
Bezieht sich auf: Ungelöster Hinweis Nr. 3615449
Erweiterte Version ist hier: https://osm.org/user/cyton/diary/401534
Erst die Datenlayer vom geoportal berlin in Qgis anzeigen, dann diese herunterladen als kml. Anlagenbäume und Straßenbäume sind separat im geoportal.
Dann die kml in JOSM öffnen, das dauert erstmal etwas. Die kml Datei dann als .osm Datei speichern.
Die .osm datei mit meinem python script umformen. Dort ändere ich die tags und metadaten, damit sie dem OSM standard entsprechen, bzw. als zu löschen markiert sind.
Diese veränderte .osm Datei wieder in JOSM laden, und source=* und source:date=* hinzufügen, sowie natürlich natural=tree.
Diese Datei dann auf mein Android Handy befördern, und dort in Vespucci öffnen.
Vor ort alle ref und etwa die position der Bäume prüfen.
Dann etwa an den Bäumen fehlende Nummern mit ref:signed=no merken.
Zuhause Dann die ursprüngliche Datei laden und vom Handy die fehlenden ref abschreiben, etwaige positionsunstimmigkeiten oder fehlende Bäume nachtragen, oder gefällte löschen.
Hochladen.
Ich bitte um Verbesserungen für diesen Workflow. Am liebsten hätte ich etwas das StreetComplete näher kommt, Vespucci ist sehr umständlich zu Bedienen. Leider ändern sich oft die sichtbaren Layer, das nervt etwas.
Die AP 7 ist komplett Mautfrei
You can’t use the cistern because it is locked by key. You don’t reach the water .
English version below.
tl;dr: Probier doch mal die Overpassabfrage für Straßen mit veralteten Parkraumdaten in deiner Gegend aus oder für Straßen gänzlich ohne Parkrauminformationen, um zu sehen, ob es Handlungsbedarf gibt :)
Try the overpass queries for streets with deprecated parking data in your area or for streets without any parking information at all to see if there is a need for action :)
Das Tagging von Parkplätzen entlang von Straßen hat vor kurzem ein großes Update erfahren: Das vorherige parking:lane-Schema wurde mit bestehenden OSM-Konventionen harmonisiert und durch ein einfacher und flexibler anwendbares Street-Parking-Taggingschema abgelöst. Existierende Daten nach dem alten Schema müssen nun also geprüft und in die neue Form überführt werden.
Für das Verständnis des neuen Parkraumschemas hilft dieser Schnelleinstieg. Aber auch, wer sich nicht tiefer mit diesem komplexen Schema beschäftigen möchte, kann dabei helfen, die Daten zu vervollständigen und zu aktualisieren. Dafür gibt es helfende Werkzeuge, in deren Benutzung ich hier einführen möchte.
Woran erkennt man alte Parkraum-Tags?
Alle Tags an Straßen, die mit parking:lane oder parking:condition anfangen, gehören zum alten Schema und sollten aktualisiert werden. Diese Overpass-Abfrage listet dir alle Straßen, die das alte Schema verwenden (oben links auf den grünen Knopf Ausführen klicken). Bleibt die Abfrage leer, sind entweder noch keine Parkraumdaten erfasst (siehe unten) oder sie sind bereits auf dem aktuellen Stand.
Die Tags des neuen Schemas beginnen nur noch mit parking:left|right|both, also ohne die Bestandteile lane und condition. Aktuelle Parkraumdaten lassen sich mit dieser Abfrage finden.
OSM Parking Lane Tag Updater
Das Tagging-Schema für Parken im Straßenraum erscheint den meisten Usern (zu) kompliziert, aber keine Angst: Der OSM Parking Lane Tag Updater hilft dabei, es ohne großes Hintergrundwissen von der alten in die neue Form zu übersetzen und die OSM-Daten auf diese Weise “halbautomatisch” zu aktualisieren.
Es ist Absicht, dies nicht weiter zu automatisieren, denn einige Daten sind schon viele Jahre alt und können sich in der Zwischenzeit geändert haben. Während des Aktualisierens sollte das im Abgleich z.B. mit Luftbildern auffallen und kann direkt korrigiert werden. Außerdem können die alten Parkraumdaten Fehler oder komplizierte, nicht dokumentierte, teils phantasievolle Tags enthalten, bei denen man im Einzelfall entscheiden muss, wie damit verfahren werden soll. Der Tag-Updater gibt Hinweise aus, wenn er auf solche Tags stößt und hilft beim Umgang damit.
Den Tag Updater verwenden
Nach Start des Online-Tools erscheinen zunächst einige Hinweise, die mit Klick auf “About this tool” ausgeblendet werden können, um die Oberfläche übersichtlicher zu halten. Anschließend könnt ihr auswählen, ob ihr die Daten direkt über die OSM-ID eines Straßensegments einladen wollt (Option 1) oder per Copy and Paste hinein- und herauskopieren wollt (Option 2). Die folgende Kurzanleitung geht auf Option 2 ein.
Wählt ihr Option 2, könnt ihr alte Tags links in das Feld einfügen, mit Klick auf Update übersetzen (Shortcut: Alt + Enter) und aus dem rechten Feld wieder herauskopieren. Mit etwas Übung lassen sich auf diese Weise viele Daten in kurzer Zeit aktualisieren:
- Ein möglicher Weg, dies effektiv zu tun, ist, alle alten Tags gemeinsam im OSM-Editor auszuwählen (mit alphabetischer Reihenfolge und dem gemeinsamen Prefix
parking:sollte dies leicht möglich sein) und direkt auszuschneiden bzw. zu kopieren und zu löschen, um sie später nicht mit den neuen Tags zu vermischen. Dann in den Updater einfügen, übersetzen und zurückkopieren. - Ein anderer möglicher Weg ist es, aus dem OSM-Editor einfach alle Tags – auch die, die nichts mit Parken zu tun haben – auszuschneiden und ins Tool einzufügen und nach dem Übersetzen unter dem Ausgabefeld die Option Copy All Tags zu klicken. Dann werden auch alle Tags wieder zurückkopiert, nun allerdings mit ausgetauschten aktualisierten parking-Tags.
Achtet stets darauf, das Ergebnis kurz mit einem Luftbild oder im Zweifelsfall anderen Quellen wie Straßenfotos (falls vorhanden, insbesondere Mapillary oder KartaView) abzugleichen, um es auf Aktualität und Fehler zu prüfen. Ein sehr gutes grafisches Feedback im Editor gibt außerdem der Parkraum-Style in JOSM (siehe unten).
Review-Funktion des Tag Updaters bei fehlenden oder unverständlichen Tags
Der Tag Updater basiert auf einer Übersetzungsliste mit vorgegebenen Werten. Enthalten die eingefügten OSM-Daten Fehler oder unbekannte Attribute, kann der Updater sie nicht übersetzen und gibt Warnhinweise aus. In diesem “Review new tags”-Bereich unterhalb der Ein- und Ausgabefelder könnt ihr die ausgegebenen Tags prüfen und ggf. überarbeiten oder vorgeschlagene Werte übernehmen. Durch die Umstellung des Tagging-Schemas kann es außerdem Situationen geben, in denen nach Möglichkeit weitere Tags manuell ergänzt werden sollten, um die Angaben zu vervollständigen. Die häufigsten Hinweise und der Umgang damit sind im OSM-Wiki erläutert.
Wer mit einem der Hinweise im Updater nicht weiterkommt oder sonst irgendwelche Fragen oder Probleme mit dem Tagging hat, kann mich gern anschreiben und ich helfe gern bei der “Übersetzung”!
Fehlende Parkraumdaten ergänzen
Vielerorts fehlen Parkraumdaten in OSM sogar noch gänzlich. Als interessantes und den Straßenraum fast aller Städte prägendes Attribut rückt es aber mehr und mehr in den Fokus einiger urbaner Mapper (diese Overpass-Abfrage zeigt aller Straßenabschnitte, an denen Parkstreifenattribute weder nach dem neuen noch dem alten Schema erfasst sind).
Die wohl einfachste Möglichkeit zur Erhebung von Parkraumdaten ist das StreetComplete Parking Overlay. Dafür in der Android-OSM-App StreetComplete über das Einstellungsmenü oben rechts und “Overlays” die Option “Parkstreifen” auswählen. Straßen werden nun entsprechend vorhandener Parkraumdaten eingefärbt. An rot gefärbten Straßen fehlen noch Parkraumattribute. Um diese zu ergänzen, einfach auf das Straßensegment klicken und die passenden Daten für die linke und rechte Straßenseite auswählen. Ändern sich die Position oder Ausrichtung der parkenden Fahrzeuge entlang des ausgewählten Straßensegments, kann die Straße über das Menü unten links (drei Punkte) an der passenden Stelle aufgespalten werden.
Natürlich lässt sich Parkraum auch mit den anderen OSM-Editoren mappen. Dafür wird dann aber ein Blick in die Dokumentation zum Kartieren von Parkplätzen im Straßenraum nötig sein. Ein hilfreiches Tool ist auch der Zlant Parking Lanes Viewer und Editor, mit dem Parkstreifeninformationen angezeigt und bearbeitet werden können (für letzteres unten rechts auf Editor klicken). Auf Grundlage dahinterliegender Luftbilder lässt sich so auch auf effektive Weise und aus der Ferne Parkraum kartieren.
Tipps für JOSM-User
Um Parkstreifen-Taggings korrekt anzuwenden, ist es sehr hilfreich, ein visuelles Feedback im OSM-Editor zu bekommen. Für den OSM-Editor JOSM gibt es dafür einen Map Style, der ganz einfach über die Einstellungen, den Reiter “Kartenstile” und dort einer Suche nach “Parkstreifen” aktiviert werden kann. Der Stil visualisiert sowohl physische Parkraumtags (Position und Ausrichtung der Fahrzeuge) als auch Parkbeschränkungen und markiert Straßensegmente mit veralteten oder widersprüchlichen Parkraumtags. Auch eine Vorlage zum Mappen von Parkstreifen lässt sich unter gleichem Namen finden.
In JOSM lassen sich außerdem Daten mit Overpass herunterladen, sodass sie gezielter und übersichtlicher bearbeitet werden können. Dafür muss der “Expertenmodus” eingeschaltet sein, wofür im Einstellungsfenster unten links ein Häkchen gesetzt werden muss. Nun im Dialog zum Herunterladen von Daten oben “Von Overpass-API herunterladen” auswählen, den Inhalt der oben verlinkten Abfrage einfügen und Daten herunterladen. Auf diese Weise lassen sich alte Daten sehr effizient und zielgerichtet aktualisieren.
Und wofür ist das eigentlich alles nützlich?
Parkraum ist ein prägendes Merkmal vieler Städte und dort fast überall gegenwärtig, aber dennoch bisher nur bei wenigen Mappern im Fokus. Dabei können OSM-Daten in diesem Bereich ganz nebenbei eine wertvolle Datenlücke in der Stadtplanung schließen – denn niemand anderes (weder Kommunen, noch Behörden oder Unternehmen) verfügt über strukturierte Daten zum Parken auf den Straßen. Wenn überhaupt, gibt es Erhebungen für einzelne Stadtteile oder Parkzonen, aber diese sind fast nie als offene Daten verfügbar und nicht miteinander vergleichbar.
Das OSM Parkraumprojekt aus Berlin hat demonstriert, dass man mit den OSM-Daten vielfältige Analysen anstellen kann, bis hin zur Interpolation von Stellplatzzahlen für ganze Städte (Work in Progress), der detaillierten kartographischen Darstellung des Parkraums und Berechnungen zur Parkraumdichte. Der Autor dieses Posts ist Teil der Projektgruppe, die zwischen September 2022 und Februar 2023 durch den Prototype Fund gefödert wurde, um die Analysemethode für Parkraumdaten aus OSM weiterzuentwickeln.
OSM bietet in diesem Bereich also ein großes Potential und ein Alleinstellungsmerkmal, was bisher kaum ausgeschöpft wird. Ihr alle könnt dazu beitragen, das zu ändern! In diesem Sinne: Viel Spaß beim Parkraum mappen :)
EN
The tagging for parking spaces along streets recently got a major update: The previous parking:lane scheme has been harmonised with existing OSM conventions and replaced by a street parking tagging scheme that is easier and more flexible to use. Therefore, existing data based on the former scheme needs to be reviewed and converted to the new scheme.
This quick guide helps to understand the new parking scheme. But even if you don’t want to deal with this complex scheme in depth, you can help to add and update the data. There are some tools to help with this, and I would like to introduce you to their use.
How can you identify old parking tags?
All tags on streets that start with parking:lane or parking:condition are old, deprecated tags and should be updated. This overpass query shows all streets that are tagged with the old scheme (click on the green button in the upper left corner to run the query). If the query remains empty, either no parking data has been recorded yet (see below) or they are already up to date.
The tags of the new scheme just start with parking:left|right|both, i.e. without the lane and condition infixes. Up-to-date street parking data can be found with this query.
OSM Parking Lane Tag Updater
The tagging scheme for street parking seems (too) complicated for most users, but don’t worry: The OSM Parking Lane Tag Updater helps to translate it from the old to the new syntax without much background knowledge thus updating the OSM data “semi-automatically”.
It is intended to not fully automate this, because lot of the data is already many years old and may have changed in the meantime. During the updating process, this should be noticed by comparing it e.g. with aerial photos and can then be corrected. Moreover, the old parking lane data may contain tagging mistakes or complicated, undocumented, sometimes fancy tags, for which you have to decide on a case-by-case basis how to deal with them. The tag updater issues notices when it encounters such tags and helps reviewing them.
Using the Tag Updater
After starting the online tool, you will first see some notes that can be hidden by clicking on “About this tool” to keep the interface clear. You can choose whether you want to load the data directly via the OSM ID of a road segment (option 1) or copy and paste it in and out (option 2). The following brief instructions focus on the second option.
If you choose the second option, you can paste old tags into the field on the left, translate them by clicking “Update” (shortcut: Alt + Enter) and copy them from the field on the right. With some practice, you can update a lot of data in a short time this way:
- One possible way to do this effectively is to select all old tags in the OSM editor (with alphabetical order and the shared prefix
parking:this should be easy) and cut or copy and delete them directly to not mix them with the new tags later. Then paste into the updater, translate and copy back. - Another possible way is to simply cut and paste all tags from the OSM editor - even those that have nothing to do with parking - and click the Copy All Tags option below the output field after translating. Then all tags will be copied back again, but now with the replaced, updated parking tags.
Always make sure to briefly verify the result with an aerial photo or, in case of doubt, other sources such as street photos (if available, esp. Mapillary or KartaView) to check for up-to-dateness and mistakes. A very good visual feedback within the editor is also provided by the parking lanes style in JOSM (see below).
Review feature of the tag updater for missing or ambiguous tags
The tag updater is based on a translation list with predefined values. If the pasted OSM tags contain mistakes or unknown attributes, the updater cannot translate them and provides warnings. In this “Review new tags” section below the input and output fields, you can check the output tags and revise them if necessary or accept suggested values. Due to the changes in the tagging scheme, there may also be situations where additional tags should be added manually, if possible, to complete the information. The most common warning notes and how to deal with them are explained in the OSM Wiki.
If you are stuck with one of the warning notes in the updater or have any other questions or problems with the tagging, feel free to contact me and I will be happy to help with the translation or issue!
Complete missing street parking data
In many places, street parking data is still completely missing in OSM. However, it is becoming more and more the focus of some urban mappers as an interesting attribute that dominates the streetscape of almost all cities (this overpass query shows all streets where street parking attributes are neither mapped according to the new nor the old scheme).
Probably the easiest way to collect street parking data is the StreetComplete Parking Overlay. To do this, in the Android OSM app StreetComplete, select the setting menu at the top right, choose “Overlays” and select “Street parking”. Streets are now coloured according to existing parking data. Streets coloured in red are still missing parking attributes. To add these, simply click on the street segment and select the appropriate values for the left and right sides of the street. If the position or orientation of the parked vehicles along the selected street segment changes, the street can be split using the menu at the bottom left (three dots).
Of course, street parking can also be mapped with the other OSM editors. However, this may require a look at the documentation on mapping street parking. Another helpful tool is the Zlant Parking Lanes Viewer and Editor, which can be used to display and edit parking lane information (for the latter, activate the Editor at the bottom right). Using aerial photographs in the background, street parking can be mapped effectively and remotely.
Tips for JOSM users
To use street parking tagging correctly, it is very helpful to get visual feedback in the OSM editor. For the OSM editor JOSM there is a map style for this purpose, which can easily be activated via the preferences, the tab “Map Paint Styles” and there a search for “Parking lanes”. This style visualises physical parking tags (position and orientation of vehicles) as well as parking restrictions and marks street segments with deprecated or conflicting parking tags. A preset for mapping parking lanes can also be found under the same name.
In JOSM, it is also possible to download data via Overpass queries to allow more targeted editing of the data. For this, the “expert mode” must be activated, for which a tick must be set in the preferences menu at the bottom left. Now, in the dialogue for downloading data, select “Download from Overpass API” at the top, paste the content of the query linked above and “Download data”. In this way, old data can be updated very efficiently and in a targeted manner.
And what is all this actually useful for?
Street parking is a dominant characteristic of many cities and is present almost everywhere, but isn’t focused on by many mappers yet. But OSM data can close a valuable data gap in urban planning here - because no-one else (neither municipalities, nor administrative authorities or companies) has any structured data for street parking. If at all, there are surveys for individual districts or parking zones, but these are almost never available as open data and are not comparable with each other.
The OSM Parking Project from Berlin has proven that OSM data can be used for a wide range of analyses, including the interpolation of parking space counts for entire cities (work in progress), the detailed mapping of parking space and calculations of parking densities. The author of this post is part of the project group funded by the German Open Source Prototype Fund between September 2022 and February 2023 to further develop the analysis method for parking data from OSM.
OSM therefore offers great potential and a unique feature in this field, which has hardly been exploited so far. You all can contribute to change this! With this in mind: Have fun mapping street parking :)
Mein Weg zu OSM
Der nicht aktuelle Stand der OSM-Karte im Rahmen des Ausbaus der (Eisenbahn) S-Bahnlinie 13 (S 13) von Troisdorf nach Bonn-Oberkassel motivierte mich im Mai 2020 bei Openstreetmap aktiv zu werden. Der Bonner OSM-Stammtisch, der sich einmal im Monat trifft (diskutieren führt oft schneller zur Erkenntnis), hat mir beim Einstieg in das Mappen geholfen. Er ist auch heute noch eine gute Unterstützung
Aktivitäten
Bei verschiedenen Mappings fiel mir auf, dass bei Eisenbahnweichen oft das Tag railway=switch fehlte. Ich stellte mich der Herausforderung, die entsprechenden Node zu finden: Mit Overpass-Turbo wurden die Eisenbahnstrecken selektiert, mit einer Datenbankanwendung die “verdächtigen” Node’s identifiziert, als Overpass-Query in die Zwischenablage exportiert und in der Karte markiert. Die Entwicklung nahm einige Monate in Anspruch. Das Know-how als Dipl.-Ing. der Elektrotechnik mit Schwerpunkt Datenverarbeitung und viel Erfahrung in der Basic-Programmierung halfen. In den DACH-Ländern sollte es keine ungetaggten Eisenbahnweichen geben.
Die nächste Herausforderung bestand darin, die Daten dieser Weichen zu ergänzen. Dabei ist es hilfreich, wenn die Daten symbolisch dargestellt werden. Ein entsprechender MAPCSS-Stil musste her! Dieser sollte die Konfiguration der Weichen und wesentliche Daten darstellen.
Weitere MAPCSS Styles helfen, die Richtung des OSM-Weges und die Geschwindigkeiten anzuzeigen.
Zur Zeit arbeite ich an einem Style für die Darstellung von Eisenbahnsignalen.
Hier ein kleines AutoHotKey Skript zur schnellen Adresserfassung. Mit F7 wird die Adresse des sich unter dem Mauszeiger befindlichen Gebäudes automatisch gesetzt. Dabei wird die letzte Hausnummer um 1 oder 2 erhöht.
Ablauf: Das erste Gebäude bearbeitet man ganz normal mit dem Adresspreset. Man setzt entweder den +1 oder +2 Button, je nach Schrittweite der Hausnummmern. Dann wandert man mit dem Mauszeiger von Haus und Haus und drückt F7.
Voraussetzungen: Das Preset “Anmerkung/Adresse” muss man sich auf Taste F10 legen. Modus muss Selektion (Taste S) sein.
Das Skript zB. als schnelle-hausnummern.ahk abspeichern und zum Starten doppelklicken.
#NoEnv
SendMode Input
f7::
Click
Click
Sleep, 2
Send {F10}
Sleep, 10
Send {Enter}
return
In diesem Blogpost zeige ich ein Python Skript mit dem osm2pgsql Importe automatisiert werden können. https://jakobmiksch.eu/post/osm2pgsql-replication-script/
Logopädie List Lister Meile 85 a 30161 Hannover
Logopädie Kleefeld Scheidestraße 21a 30625 Hannover
Logopädie Hainholz Bömelburgstraße 35 30165 Hannover
Logopädie Bothfeld Sutelstraße 10 30659 Hannover
Logopädie Burgdorf Weserstr. 6 31303 Burgdorf
Langenhagen Walsroderstr. 47a 30851 Langenhagen
In einer Korrespondenz auf dem issue-tracker eines Routers auf Basis von openstreetmap Daten bin ich auf die default Einschränkungen für die verschiedenen Arten von Wegen hingewiesen worden.
Im lokalen Forum wollte ich daraufhin anregen, dass die Berechtigungen von track auf etwas der Realität näheres als ein vollmundiges yes gestellt werden.
Ein Vorschlag eines Teilnehmers aus einem Drittland war partial, was meiner Auffassung so ungefähr das bedeutet, dass es vor Ort noch erhoben werden muss. Dergleichen finden sich aber nur auf zehn Prozent der als track erfassten Wege. Trotzdem hätte ich beinahe geglaubt, dass das auf ganz Österreich gut zutreffe.
Offensichtlich ist das nicht so. Von mancher Seite wird der Standpunkt vertreten, dass wenn vor Ort nichts ausgeschildert ist, dann ist yes sehr wohl richtig. Mir entzieht sich bis dato, was das damit zu tun hat, ob in den openstreetmap Daten eine Einschränkung erfasst ist oder nicht.
Nun ja, es könnte in der Tat in den meisten Fällen so sein, dass wenn nichts erfasst ist, auch nichts ausgeschildert ist. Das allerdings deckt sich nicht mit meinen Beobachtungen in Tirol.
Wie das nun belegen? Sind ja hier wie dort nur Anekdoten! Also amtliche Daten geholt, den Intermodales Verkehrsreferenzsystem Straßengraph, a.k.a die GIP für mein Bundesland.
Das Shapefile in JOSM laden dauerte ewig. Wenn einmal geladen lief das Schieben des Ausschnitts aber recht flott. Super Sache dieser Editor. So lässt sich gut beurteilen, wie die openstreetmap mappings und die Kategorien in den amtlichen Daten korrespondieren. Sie tun es, mit Unschärfen an den Rändern zwar, aber Ja!
Dann entdeckte ich das geojson Format und kam auf die Idee, damit wäre es möglich, die Daten direkt auszuwerten. Hier zwei jq Einzeiler:
-
Geh/Rad/Wanderwege extrahieren, kann in den Editor geladen werden:
jq '. | .features |= map(select(.properties.OBJEKT=="S-FRW"))' Verkehrswege.geojson > Wanderwege.geojson -
Statistik über die Gesamtstrecke der amtlichen Klassen:
jq '[.features[].properties] | group_by(.OBJEKT) | map({(first.OBJEKTBEZEICHNUNG): (map(.Shape__Length/1000) | add | floor)}) | sort | add' Verkehrswege.geojson
Das Ergebnis vom zweiten Auftruf:
{
"Autobahn": 310,
"Autobahn - Brücke": 33,
"Autobahn - Nebenanlage": 36,
"Autobahn - Rampe": 107,
"Autobahn - Rampe mit Brücke": 9,
"Autobahn - Tunnel/Galerie": 39,
"Bahnlinie - hochrangig": 878,
"Bahnlinie - hochrangig: Brücke": 4,
"Bahnlinie - hochrangig: Tunnel/Galerie": 132,
"Bahnlinie - lokal": 66,
"Bahnlinie - lokal: Brücke": 0,
"Bahnlinie - lokal: Tunnel/Galerie": 1,
"Forstwirtschaftliche Weg": 17695,
"Landesstraße B": 926,
"Landesstraße B - Brücke": 34,
"Landesstraße B - Parkplatz": 15,
"Landesstraße B - Rampe": 30,
"Landesstraße B - Tunnel/Galerie": 34,
"Landesstraße L": 1234,
"Landesstraße L - Brücke": 28,
"Landesstraße L - Tunnel/Galerie": 18,
"Privatstraße": 34,
"Privatstraße - Brücke": 2,
"Privatstraße - Parkplatz": 0,
"Privatstraße - Rampe": 0,
"Privatstraße - Tunnel/Galerie": 5,
"Radweg, Fußweg, Wanderweg": 1654,
"Schnellstraße": 25,
"Schnellstraße - Brücke": 1,
"Schnellstraße - Nebenanlage": 0,
"Schnellstraße - Rampe": 7,
"Schnellstraße - Rampe mit Brücke": 1,
"Schnellstraße - Tunnel/Galerie": 41,
"Singletrail Strecke": 232,
"Wirtschaftsweg": 3548,
"Örtliches Straßennetz": 9191
}
Erklärung zu jq dazu. Die Kategorien an sich schon interessant. Überraschend jedoch: Mit knapp 18.000 Kilometern sind Forstwege die vorherrschende Straßenart überhaupt! Auf wie vielen davon darf jeder und jede mit Auto, Motorrad, Lastwagen, Rad usw. fahren? Ausgeschildert ist das übrigens recht gut. Beim Ausbau mögen die Hiesigen anderen Landesteilen hinterherkinken, beim Aufstellen von Schildern sind sie top :)
Der “gute Wanderweg” ist ja fast immer ein Pfad, Tracks sind nicht so beliebt und dürfen auch bei Premiumwegen nicht zu oft vorkommen. Und bei Pfaden fehlen mir oft: Ein Tag, dass die Attraktivität einstuft, unabhängig von den schon vorhandenen Tags (s.u.). Da könnten eingehen: schöne Aussicht, Schatten im Sommer, etwas Licht im Winter, interessante Wegführung, Nähe zum rauschenden Bach. Wie man so etwas definieren könnte, ist nachzulesen auf den Seiten der Weg-Zertifizierer (also Wander-Institut etc.).
Wir haben ja eigentlich schon eine ganze Menge an Tags, die die Attraktivität beschreiben können: die Breite, die glatte Wegoberfläche und die Sichtbarkeit (Visibility). Hier scheint mir der Haken zu sein, dass die meisten Renderer diese Tags gar nicht auswerten. Und wozu trägt man Tags ein, wenn sie in den Karten nicht auftauchen? Änderungen am Rendern könnte also helfen.
Trotzdem meine ich, dass es für Apps wie Komoot nicht einfach ist, einen “schönen” Wanderweg per Autorouter zu erzeugen. Und die Zukunft der Wanderkarte liegt ja irgendwo bei diesen Apps.
Ich würde mir ein neues Tag für Premium-Eigenschaften wünschen, das widerspiegelt, ob ein Pfad von einem normalen Wanderer als “Traumpfad” oder als “langweilig und öde” eingestuft wird - also eine Art von Grade 1 - Grade 5.
Das Thema ist mir zu komplex, um es (gleich) in englisch zu schreiben. Ich bin auch kein Experte, kenne nicht mal die Probleme und Notwendigkeiten so genau. Das hier ist also eher ein Brainstorming mit einigen Schlagworten:
- Anything will be an area
- There has always be Vector Tiles
- Don’t tag vor the Vector Tiles
- Make the problem to the solution
Area als neuen Objekt-Typ ist nur Tagging-Sugar, die Verpackung wird einsichtiger, der Inhalt bleibt. Ein Kreisverkehr braucht kein area=no mehr, der Spielplatz keine identischen End-Nodes. Trotzdem bin ich dafür. Einige Editoren haben Areas ja auch schon im Interface. Ich sehe in Zukunft immer mehr Areas, auch für Wege. Am Ende ist jeder Fleck Erde Teil irgend eines Areas. Das ist gut für zoomed Rendern, für Rollstuhl-Karten und 3D Rendern. Es ist nur schlecht für rooting; vielleicht sollte im Way-Object eine Hilfe sein, eine Liste zu den anschließenden Wegen.
Vektor Tiles sind im Kern geordnete Informationen für ein Gebiet. Die brauchte man auch schon bei den ersten Bitmap-Renderern. Aus der Tagging-Anarchie wurden, und werden, Objekte in Layer gefiltert. Und dabei wird entschieden, was überhaupt sichtbar wird! Erst im nächsten Schritt werden die Objekte zu sichtbaren Linien, Flächen oder 3D Objekten. Daher dürfen Vektor Tiles nicht das aussehen festlegen und auch nicht bestimmen, was auf die Karte kommt. Allerdings gibt es “normale” Objekte, die jeder braucht und Seltene für Spezial-Karten. Mein Ansatz wäre: Immer zwei Tile-Dateien bereit zu stellen, eine die kompakt alles “normalerweise” notwendige enthält und eine mit wirklich dem ganzen Rest; schräge Sachen notfalls in einen Layer “sonstiges”. Den muß der Rendere dann nach dem Tagging der Objekte selbst sortieren.
“Don’t tag for the renderer!” sollte jeder kennen. Wird das in Zukunft auch für die Erstellung der Vektor Tiles gelten? Denn dabei wird schon viel geprüft und entschieden. Ein Editor könnte diesen Schritt transparent machen und das Objekt darstellen, wie und wo es in Tiles erscheinen würde. Dann ist es nicht mehr weit, bis man “direkt” in der Tile Editiert. Am Ende könnte das bisherige Tagging-Durcheinander komplett entfallen.
Aus dem offenen Tagging eine Zuordnung zu den Render-Layern zu schaffen ist auch heute schon notwendig. Allerdings kann hier jeder Renderer machen was er will. Wenn das schon für die Vektor-Tile gemacht wird, wird es vereinheitlicht/zentralisiert. Die meisten, aber nicht alle wird das freuen, erst recht, wenn das dann schon im Editor erzwungen wird. Nein, freie Tags müssen bleiben. Auch wenn die Vector-Tile die nicht “brauchen” kann, müssen sie mitgenommen werden. Der Renderer hat dann das Problem aber auch die Freiheit.
Zurück zum Data Model
Die Way-Nodes als Liste in das Way-Objekt scheint mir ok zu sein. Wenn der Weg jetzt einen Zebrastreifen hat, ist das ein eigenständiges Node-Object. Oder nenne wir es vielleicht gleich POI-Object! Nur hat dieses dann keine eigene Geo-Position sondern eine Referenz auf den Way und in die Liste dort.
Die Object IDs machen Probleme? Können wir sie vielleicht ganz los werden? Ich kann mir nicht vorstellen, das jeder Renderer immer alle World-Objekte scannt um die aus dem benötigten Gebiet zu finden; da gibt es schon Indizierungen, 2D Bäume oder so was. Ist das im Grunde genommen nicht schon eine Einteilung in Tiles? Wenn wir das Datenmodel schon so gestallten, dass die Objekte in Tiles-Datensätze sortiert sind würden die erwähnten Rechenprobleme würden doch entfallen. Ja, an den Grenzen gibt es viel Hirnschmalz einsetzen. Ds muß ja jetzt jeder Vektor-Tile-Builder auch schon schaffen.
Die Way-IDs sind also eher kleine Indices in die Tile-Lokale-Datenbank. Node IDs braucht es garnicht mehr? Zum Karten Rendern vielleicht nicht, aber für Busslinien etc. schon. Referenzen in Relationen brauchen ggf. neben der Objekt-ID auch die Tile-“ID”. Wenn die OSM-Objekte schon in Tiles sortiert sind kann man sie gut auf verschiedene Rechner verteilen. Editieren im Datensatz aktualisiert quasi sofort die Vektor Tile.
Natürlich sollte der editierende Mensch nicht auf die Tile-Grenzen achten müssen. Ja aber wie sollte dann das OSM-API aussehen? Immer noch nur lat/lon oder schon Tile-bezogen? Denkbar ist beides. IDs werden weiter benötigt. Wenn sie aber schon “Tile.Nr” sind, muß der Editor das auch können. Und wenn ein Objekt über die Tile-Grenze geschoben wird?! Wenn ein Way über nicht nur ein bisschen über die Tile-Grenze ragt? Wenn der oben genannte Zebrastreifen ausgerechnet in der benachbarten Tile ist? Vielleicht brauchen Tiles einen gewisse Überschneidungsbereich und wenn der nicht reicht, wird der Way automatisch gesplittet in Zwei. Wenn eine Relation POIs in ganz Europa auflistet? Sind Tile.ID stabile Referenzen? Als Byte-Offset nicht; und ein Objekt-Index nur, wenn gelöschte Objekte nicht neu vergeben werden. Sollten Objekte besser Rückwärts-Referenzen zu ihren Relationen haben?
So einfach ist das alles nicht, wie ich das hier erträume !!!
Welches Zoom-Level meine ich? Na so 18 vielleicht? Dann kommt man schnell an einzelne Daten. Und wenn die Dateien zu klein und zu viele werden kann man je 4 oder 16 Zusammen fassen, aber so, das nach dem Laden die einzelnen (PBF-)Teile wieder unabhängig verarbeitet werden können. Ob man das auch bis zum World-File treiben sollte? Warum nicht? Über Changesets möchte ich aber lieber nicht nachdenken.
Da war noch die Küstenlinie der Kontinente. Erst mal Teilstücke als Way. Mit Links zu den Nachbarstücken? Relationen für die Teile eines Bezirks oder Lands? Super Relationsbaum bis zu “Australien”?
Ich lege diesen Text jetzt mal hier offen ab; er kann sich aber noch ändern!
Ich habe highway=milestone DE aktualisiert und man kann sagen: naja.
Na gut, es sind über 1000 milestones hinzugekommen, aber 800 allein auf wahrscheinlich einen einzigen Mapper in SH. Oder ich hab ‘nen Knick in der Optik.
Entweder hier wird in den Kommentaren ordentlich rumgemault oder ich schau demnäxt nochmal selbst, wie das genau kommt…
Ich habe https://wiki.openstreetmap.org/wiki/User:Dex2000#fertig “Autobahnen und Abfahrten ohne Lanes” aktualisiert und da kamen innerhalb der letzten 12 Monate über 300 (von 33 in ‘22) dazu. Mir fehlt grad die Zeit zu schauen, wo das herkommt, Freiwillige vor ;)
P.s. und Disklaimer: fehlende Lanes sind kein Fehler im Datenmodell! Aber (imho) nicht wünschenswert.
Heute war ich mal seit längerem wieder mappen, mit StreetComplete. Dabei ist mir aufgefallen, dass hier in Holzlar schon viel gemappt wurde :) Gibt es eigentlich in Holzlar eine kleine Mapping-Community?