Bei Radwegen macht die Breite oft den Unterschied zwischen “Guter Radinfrastruktur” und “Unbrauchbarer Radinfrastruktur” aus, deswegen wollen wir versuchen diese Info zumindest für die Radvorrangrouten in Nürnberg zu ergänzen.
Habt ihr irgendwelche Tipps wie man das effizient macht? Bisher haben wir hauptsächlich mit Maßband gemessen. Für 5km haben wir auf die Art 2h gebraucht…
Mit einem Laser-Entfernungsmesser würde man sich zwar nicht viel Arbeit sparen, sich aber zumindest nicht so unbeliebt machen. Leider hat sich meiner im grellen Sonnenlicht als ziemlich unbrauchbar herausgestellt.
Wenn man in die Mappillary Aufnahmen einen Maßstab einblenden könnte, dann wäre schon viel gewonnen. Oder gibt es irgendwelche Bastel-Lösungen für Breitenmessungen, wie den OpenBikeSensor?
Die sogenannten “Fahrradstraßen” sind in Nürnberg praktisch vollständig auch für den Autoverkehr freigegeben und werden auch gern zum Parken verwendet. In den besser ausgebauten Fahrradstraßen ist auf beiden Seiten eine gestrichelte Linie aufgemalt, die den Abstand angibt, den Radfahrer von den geparkten Autos halten sollten und dürfen.
So wie ich die Dokumentation von “width” verstehe ist das bei Straßen der Abstand “von Bordstein zu Bordstein”. Diese Breite interessiert uns als Radfahrer nicht, wir wollen die nutzbare Breite eintragen, d.h. den Abstand zwischen den gestrichelten Linien.
Gibt es dafür einen Tag oder können wir uns einen ausdenken? Z.B. “usable_width”?
Das größte Problem beim Eintragen der “width” in OSM ist die Schwankung der Breite.
Hier gibt es zwei Fälle:
Die Breite schwankt so in der Größenordnung von einem halben Meter, z.B. zwischen 90 und 120cm
Die Breite schwankt extrem, weil z.B. Bushaltestellen, Litfassäulen oder Teile von Gebäuden den Radweg verengen.
Eine einfache Lösung für (1) wäre, dass wir die Breiten auf halbe Meter auf- und abrunden, also für 90cm und für 120cm den gleichen Wert eintragen: “1”
Ist das zulässig? Oder müssen wir dann “est_width” verwenden?
Bei (2) stehen wir ziemlich auf dem Schlauch: Wir können ja die Wege nicht alle paar Meter aufteilen, bloß um eine halbwegs exakte Breite eintragen zu können. Oder doch?
Die erste Idee war die minimale Breite eines Segments einzutragen. Aber es gibt die Realität nicht vernünftig wider, wenn wir z.B. bei einem 100m langem Segment “1” eintragen, nur weil auf 5m die Breite durch eine Bushaltestelle verengt ist.
Die nächste Idee war die minimale Breite, die maximale Breite und vielleicht noch einen geschätzten Durchschnitt einzutragen.
Und letzte Idee war, dass wir in solchen Abschnitten gar keine Breite eintragen. Aber dann sollte bei dem Abschnitt zumindest vermerkt sein, dass er bearbeitet wurde keine Breite ermittelt werden konnte, z.B. mit “width=volatile” oder einem eigenen Tag?
Was meint ihr?
Bei der Angabe der Breite des Weges selber (width) und - mindestens genau so wichtig - der maximal zur Verfügung stehenden Breite (maxwdith:physical - z.B durch Poller, Straßenlaternen, Mülleimer etc.) gibt man für einen Abschnitt immer den kleinsten Wert an. Es macht Sinn bei starken Schwankungen oder bei besonderen Engstellen die Wege entsprechend zu teilen bzw. die Barrieren als Punkt auf der Linie einzutragen.
Wie gut sind denn die bei euch verfügbaren Luftbilder? Mit richtig guten Luftbildern lassen sich Breiten schon so auf ~20cm genau erfassen (mindestens für markierte Fahrradstreifen auf der Fahrbahn). Wie @dieterdreist erwähnte geht das sehr gut in JOSM. Z. B. Kann man mit dem building-Tool (ein JOSM-Plugin) leicht ein Rechteck aufspannen z. B. zwischen Markierungsinnenseite und Bordsteinkante und dessen Breite ablesen.
Da hab ich bisher auch nichts gesehen, was wirklich besser ist als (gute) Luftbilder oder das schon genannte StreetMeasure… Das Kalibrieren ist herausfordernd und in Diensten wie Mapillary fehlen dafür die Daten (oder das Interesse an photogrammetrischer Prozessierung).
Was bei paving_stones meist sehr gut geht – falls die bei euch z. B. bei Hochbordradwegen verbaut sind: Einfach Steine zählen, da sie üblicherweise normiert sind (z. B. 10 oder 20 cm breit).
Gibt es! width:effective. (Bei “normalen” Straßen könntet ihr überlegen, stattdessen den Parkraum zu mappen (siehe Street Parking) – die nutzbare Breite ergibt sich dann aus width Minus Breite der Parkstreifen (je nach Ausrichtung/orientation 2 bis 2,2 m bei parallel, 4,5 m bei diagonal, 5 m bei perpendicular))
Wenn irgendwas für einen “kurzen Abschnitt” die übliche Breite (width) des Weges einschränkt, würde ich einen Punkt mit maxwidth:physical auf den Weg setzen (wie @OSM_RogerWilco schon erwähnt hat, würde das auch als zusätzliches Attribut an der Linie funktionieren, aber als Punkt ist es genauer).
Relativ simpel nutzt er den Linearmodus seiner GoPro (Aufnahme ohne Objektivverzerrung)
An einem Punkt misst er ein Kalibrierungsmuster ein (erstellt mit Gimp) und legt es dann mittels XNconvert als Stapelverarbeitung über Bilder bzw. man kann sie auch über Videos legen.
Danke für die ganzen Tipps, ich werd sie alle ausprobieren und hier schreiben was rausgekommen ist.
Hier so eine Art Zwischenbericht:
Die Engstellen als Punkte eintragen scheint sinnvoll, dann braucht man nicht nur wegen der Breite den Weg mit seinen ganzen anderen Attibuten zu fragmentieren.
Blöd für Auswertungen (Karten, Statistiken) ist, dass es dann nicht reicht sich den Weg anzuschauen, sondern man auch lesen muss was bei den Punkten steht. Im Moment hab ich noch keinen Plan wie ich das machen soll.
Was das Henry-Tool macht hab ich nicht ganz verstanden
Im Store gibt es StreetMeasure nicht bzw. dort wird mir angezeigt, dass es mit meinem Smartphone/Android nicht funktioniert. Setzt das Lidar vorraus um vernünftig zu funktionieren? Mal schauen ob ich die App manuell installiert kriegen und ob/wie gut sie funktioniert
Irgendwelche EXEs von privaten Seiten wie MB-Ruler installiere ich nur ungern, ich hab ähnliche Anwendungen aus dem Microsoft-Store ausprobiert, bisher war ich noch mit keiner so richtig glücklich.
JOSM mit Luftbildern und zweckentfremdeter “Gebäude eintragen” Funktion funktioniert gut und wäre wahrscheinlich die schnellste Methode. Die Frage nach Genauigkeit die für Messungen gefordert wird hat sich bei der Methode dann auch erledigt, denn bei den Luftbildern bei denen ich das bisher probiert habe ist eh nicht viel mehr als ein halber Meter drin.
Pflastersteine sind auf Radwegen glücklicherweise eher die Ausnahme, aber ich hab auch schon daran gedacht sie zum “Kalibieren” einen Maßstabs zu verwenden, den man dann über die Mappillary-Aufnahmen legt
In Fahrradstraßen den Parkraum zu mappen klingt für mich nach der besten Lösung, weil die auf diese Art gespeicherten Informationen auch für sich einen Wert haben. Vielleicht gibt es ja Statistiken, ob Radfahrer öfter gegen aufgerissenen Türen fahren oder öfter gegen Autos, die rückwärts aus der Parklücke fahren, dann wäre das auch ein Qualitätskriterium für die Radinfrastruktur.
Also anhand eines Bildes, bei dem man die Breite von Objekten erkennen kann (Pflastersteine) erstellt er sich eine Grafik und fügt diese dann per Stapelverarbeitung in alle anderen Bilder (des Videos) ein?
ja, es geht auch über die Analyse von Videodaten, Lidar ist bei kurzen Distanzen genauer, früher 5m jetzt 10, bei 2,5cm Genauigkeit, sofort auf dem Telefon und selbst im Dunkeln. ARCore nutzt afaik die Googlecloud, d.h. du brauchst internet und Licht.
ARCore führt die Berechnungen immer lokal auf dem Smartphone aus (auch wenn Lidar/ToF nicht verfügbar ist), Internet ist nicht notwendig/wird nicht verwendet.
Nach allem was ich gelesen habe unterstützt mein Fairphone kein ARCore. Also hat es wahrscheinlich keinen Sinn es über das APK zu probieren. Oder doch?
Bei gepflasterten Radwegen könnte man die Breite aus der Pflasterung ableiten (also “wie viele Steine breit der Weg ist”). Hier würde ich mir eine App wünschen bei der man die Standardsteine, und das Verlegemuster auswählen kann, Anzahl der Steine angibt und dann die Breite berechnet bekommt. Das wäre vermutlich am schnellsten und genausten auch aus Fotos ableitbar. Man könnte natürlich auch versuchen darauf ein ANN zu trainieren.
.
Ich bin auch Teil der ADFC Gruppe, die sich zum Ziel gesetzt hat das Nürnberger Radwegenetz zu kartieren.
In den letzten Tagen hat sich herausgestellt, dass wir vermutlich nicht die Kapazitäten haben die Wegebreiten mit “width=” für das gesamte Nürnberger Radwegenetz einzutragen. Dafür sind es einfach viel zu viele km.
Ein Ansatz das Projekt doch noch zu retten wäre zu überprüfen welche Radwege den Qualitätsansprüchen der Stadt Nürnberg entsprechenden. So könnten wir dann ableiten wo die Stadt noch nachbessern muss.
Zur Einordnung wollen wir die gültigen technischen Regelwerke für Fahrradwege heranziehen. Zum einen die ERA (Empfehlung für Radverkehrsanlagen) und zum anderen den Mobilitätsbeschluss (Stadtratsentschluss zur Förderung des Umweltverbundes).
Dafür bräuchten wir die Tags
“ERA2010=”
“ERA2026=”
“RVR_Standard=”
mit den Werten
“nicht_erreicht”
“Mindestmaß”
“Regelmaß”
Wie schätzt ihr das ein? Können wir das in OSM so machen?
ich würde da nicht drei verschiedene Tags draus machen sondern dies in ein (Haupt)Tag packen
Macht es wirklich Sinn alle drei Standards an einem Weg gleichzeitig zu erfassen?
Müsst ihr dazu nicht trotzdem die Breite einigermaßen genau bestimmen?
Ich würde mir das so vorstellen:
width:standard=era_2010|era_2026|rvr (nur ein Standard, bevorzugt der neueste der erfüllt wird)
width:standard:compliance=minimum|not_met|standard|exceeds) (für den Standard die eine Bewertung)
Wenn ich länger drüber nachdenke find ich die Erfassung der “Normen” eher nicht zielführend. Wer soll diese Daten pflegen? Wer hat die Zahlen dafür im Kopf? Breite messen muss ich eh, dann kann ich sie auch als Zahl erfassen.
Die Breite muss ja nicht jeden Meter auf cm genau gemessen werden.
