Was sind denn die Genauigkeitsanforderungen an das “width” Feld? Einer der Vorschläge aus meinem ursprünglichen Post war die Breiten auf halbe Meter zu runden (1 1.5 2 …), darauf ist leider keiner eingegangen.
Damit wären für ca. 90% der Wege die prinzipiellen Probleme erledigt: Messen könnten wir bei dieser Genauigkeit oft mit Luftbildern, und bei mäandernden Wegen mit ständig wechselnder Breite bleibt dieser gerundete Wert meist konstant.
Dafür würde ich est_width statt width nutzen:
Also 0.2 m Genauigkeit sollten es schon sein.
Auf jeden Fall bei den recht häufigen Breiten von weniger als 2,5 Metern.
wieso nicht auf 2m runden, oder auf 1? Irgendwie muss man immer runden, wegen der Messgenauigkeit und der Toleranzen macht das auch Sinn bzw. ist unumgänglich, aber 50cm? 5cm hielte ich für sinnvoller, aber grundsätzlich würde ich es dem Mapper überlassen und wo es kritisch ist (z.B. zwischen 2 Mauern/Gebäuden) ist je genauer um so besser. Stell dir einen Durchgang vor der 76cm breit ist, wenn wir den als 1m angeben wird ein völlig falsches Bild vermittelt und wenn wir zur Sicherheit 0.5 nähmen auch.
Wenn du auf Einhaltung der Empfehlungen für Radverkehrsanlagen prüfen möchtest brauchst du wohl mindestens Dezimetergenauigkeit. Und ich denke, das ist auch für die Anwendungen sinnvoll.
Das wäre auch etwa die Genauigkeit die man aus Luftbildern hinbekommt. Ich würde die
Vor Ort könnte man sicher genauer messen, aber man darf auch nicht vergessen, dass wenn der Weg nicht gerade gepflastert ist auch hier Schwankungen in der Breite von etlichen cm auftreten können.
Als Datennutzer hast du jetzt schon das Problem, dass man gar nicht weiß ob und was da wirklich gemessen worden ist (die befestigte Breite, zwischen den Randmarkierungen, inklusive Randmarkierungen, überwachsene Bereiche … etc?) und dann könnte auch noch maxwidth:physical - Angaben fehlen um solche Gassen korrekt abzubilden bei denen man ja nicht auf dem Rad fahren kann.
Wir haben uns für Leaflet bzw Maplibre entschieden, weil wir das Radwegenetz nach verschiedenen Parametern (Wegetyp, Breite, Oberflächenbelag, -qualität) analysieren und darstellen wollen. Das wäre mit UMaps ein kuterbuntes, unverständlich durcheinander. Wir stellen uns eher eine Webmap mit Togglen vor, durch die die verschiedenen Qualitätsparameter zu und abgewählt werden können.
Dazu kommt, dass wir die Daten auch der Allgemeinheit zugänglich machen wollten. Ob ein Radweg sicher nurtzbar und empfehlenswert ist hängt maßgeblich davon ab, ob die Richtlinien erfüllt werden oder nicht. Um das ganze im Alltag nutzen zu können gibt es auch schon einen von uns überarbeiteten OSMAnd+ Renderingengine, durch den die OSM Daten im Navi Sichtbar wären.
Das stimmt nur in Ausnahmefällen. Zum einen ist es für die Standards egal, ob ein Weg 90 oder 110cm breit ist. Angenommen es ist eine Radvorrangroute, dann ist er nach dem Regelwerk für RVRs (Einrichtungsradweg Regelbreite 2,3m, Mindestmaß 1,5m) auf jeden Fall zu schmal und kann ohne nachgemessen zu werden in die Kategorie “not_met” eingetragen werden. Durch die Zugehörigkeit ergibt sich dann im Rückschluss, dass er neu geplant und umgebaut werden muss.
Dazu kommt, dass es einen veralteten Datensatz vom Verkehrsplanungsamt gibt, in dem bereits erfasst wurde welche Wege den Stadtards entsprechen und welche nicht. Den wollten wir zur Grundlage nehmen und nur die Wege nachmessen welche seit dem erneuert wurden.
Nein, natürlich nicht. Für Radvorrangrouten ist die ERA egal, hier zählt nur der Standard für RVRs. Bei allen anderen Radwegen wäre es dann die ERA.
Den Qualitätsanspruch hätte ich auch, von allem anderen können keine belastbaren Aussagen abgeleitet werden. Allerdings müssten wir durch die Kategorien für Radvorrangrouten zB nur in den Fällen die um die 1,5 oder 2,3m liegen nachmessen, alles andere könnten wir uns sparen. Dadurch wäre das ganze trotz qualitätsanspruch vom Aufwand her machbar.
Meinem Verständnis nach müssen die Daten nicht gepflegt werden, weil sich die Vorschriften in den Regelwerken über die Jahre nicht verändern (deswegen hätte ich die Jahreszahlen der Regelwerke in die Tags mit aufgenommen). Der gesetzte Tag wäre somit solange gültig bis der Radweg baulich erneuert wird. Und dem Fall werden hoffentlich sowieso alle Tags neu gesetzt.
Das ist was @Langlaeufer meint. Wer macht das? OSM wird größtenteils von freiwilligen Mitwirkenden gemacht, die keine Fachkenntnisse besitzen. Eine Breite kann jede:r messen.
Der Radweg wird über die Zeit verändert werden, dann muss es jemand geben, der erkennt ob die bestehenden Tags noch gültig sind. Das halte ich für schwierig, wenn da auf Normen und Empfehlungen verwiesen wird die Otto-Normal-Mapper eben nicht im Kopf hat.
Gegenfrage: Wer trägt denn jetzt die Breite ein? In Nürnberg jedenfalls nur eine Minderheit. Während “surface” und “smoothness” gut gepflegt sind wird bei der “width” meistens nichts eingetragen (liegt das vielleicht auch daran, dass die Breite nicht in StreetComplete angefragt wird? 
).
Das ist ja das Problem das wir beseitigen wollten, bis wir schnell gemerkt haben, dass “width” sich nicht in Dezimeter-Präzision eintragen lässt, aus den genannten Gründen.
Nach dem Stand der Diskussion hätte ich gesagt: “width” nur eintragen bei “vor Ort Messung” und wenn sich die Breite in dem Segment nicht um mehr als 20cm ändert. In allen anderen Fällen (Luftbild, schwankende Breite) “est_width”.
Doch, SC kann die Breite abfragen. Der Quest muss aber ggf. manuell aktiviert werden. Es gibt sogar eine eigene AR-Mess-App.
Warum machen das wenige? Weil es sehr aufwendig ist die Breiten genau zu messen. Das macht man nicht mal so eben bei im Vorbeigehen/fahren sondern man muss stehenbleiben, ggf mehrmals messen …
Von daher verstehe ich schon deinen Wunsch Breitenklassen zu erfassen. Vermultich wäre es besser, statt era_jahr Breitenklassen anhand der Grenzwerte zu benennen.
sowas in dieser Art: width:class= <1.6 | >=1.6 | >=2.3 etc
Wenn das dokumentiert wird, dann kann das jeder verwenden. Und man kann es ohne Kenntnis der prüfen.
.
ahh ok, ja das macht Sinn. Ich denke mit dem Vorschlag könnten wir gut leben.
Ich schlag das den anderen mal vor und wir überlegen uns ein sinnvolles uns verständliches Schema
Die Vorteile deines Vorschlags sind:
- Man muss nicht ERA & Co kennen um die Werte zu verstehen
- Man hat gewissen Toleranzen beim Eintragen der Werte
- Die Intervalle sind flexibler als bei meinem “auf halbe Meter runden” Vorschlag
Kann dann bei einem Weg-Abschnitt nur ein “ab” bzw. ein “bis” Wert stehen?
width:class= >=1.6
Oder kann man auch Bereiche angeben, irgendwie so?
width:class= >=1.6;<2.2
Im ersten Fall wäre ein massiver Nachteil, dass die Klassen in Stein gemeißelt werden müssten und nie wieder geändert werden können. Wenn ein Weg z.B. 1.9m breit ist und jemand deswegen width:class= >=1.6 eingetragen hat, dann kann man nicht später eine Klasse >=1.8 einführen.
Solche Breitenklassen zu erfassen (insbesondere mit “Unter- und Obergrenze”) erscheint mir letztendlich aber auch nicht einfacher, schneller oder effektiver als “einfach” eine est_width zu taggen, wo es euch nicht präziser möglich ist.
Also wenn ich beispielsweise erkennen kann, dass ein Radweg breiter als 1,6 m und schmaler als 2,3 m ist, dann würde ich einfach est_width=2 taggen. (Alternativ könntet ihr für euch ja auch festlegen, dass est_width=2 für eure Erhebung der Breitenklasse “1,6 bis 2,3 m” entspricht.)
Ja, persönlich bin ich der gleichen Meinung. Wenn man eine Breite misst, warum dann nicht diese Breite eintragen, anstatt durch die Zuordnung zu einer Klasse Informationen zu vernichten? Und wenn eine neue Klasse dazu kommt dann alles nochmal messen zu müssen?
Es sollte halt bloß klar sein, wie genau die eingetragene Breite ist.
Also im einfachsten Fall in dem man width oder est_width verwendet.
Oder (ich hab mich gerade mit Copilot darüber unterhalten) durch zusätzliche Tags.
Um Ungenauigkeiten durch die Messemethode zu erfassen
source:width (wird in Nürnberg schon verwendet) und source:width:accuracy
Z.B. :
source:width=orthophoto
source:width:accuracy=0.2
Wenn jemandem meine Luftbild-Breiten zu ungenau sind, dann soll er sie halt ignorieren. Oder selber mit dem Zollstock hinfahren und genau messen.
Um die Tatsache zu berücksichtigen, dass die Breite des Weges innerhalb des Abschnitts schwankt
width:min, width:max und width:variable
Z.B. :
width:min=1.80
width:max=2.50
width:variable=yes
Was hilft die maximale Breite, wenn du nicht weißt wie lang das stück ist auf der sie gilt?
Wenn dann min und mean.
Oder bloß “min”, weil wie ermittelt man “mean”? Mit dem “min” ist zumindest klar, dass der Mapper die minimale Breite meint, bei einem reinen “width” ist das nicht so klar. Nicht dass ein anderer kommt und den Wert korrigiert weil er sich denkt “was hat HaraldBk hier denn für einen Mist gemessen?”.
Ich denk der einzige Weg die hier geäußerten Genauigkeitsanforderungen zu erfüllen wäre die Breite bei den einzelnen Wegpunkten einzutragen (siehe Supaplex030 vor gefühlten drei Wochen). Das würde auch das Problem lösen vor dem jemand steht, der den Weg teilen will und dann damit rechnen muss, dass bei einem der beiden neuen Weg width:min falsch ist.
Das ist durchgängig vom Aufwand her aber nicht machbar und ich frage mich, ob jemand der die Daten auswertet damit rechnet, dass die Breite nicht beim “way” steht.
Nach knapp drei Wochen Diskussion würde ich in Schritt 1 (wenn sich die Gelegenheit ergibt) jetzt eintragen:
width:min
source:width= ARCore | aerial_imagery | imagery | survey
source:width:accuracy=0.2
“aerial_imagery” scheint im Wiki der üblichere Begriff für “Luftbild” zu sein. “imagery” wäre ein (Mapillary-)Bild aus dem sich (mit welchen Techniken auch immer) die Breite erkennen lässt.
“survey” eine Messung vor Ort.
Das ist nicht perfekt, aber ich denke es wäre ein Fortschritt. Gibt es noch Einwände der Art “auf keinen Fall!”? Muss das irgendein Komitee genehmigen? Kann/darf ich das dokumentieren?
Nur zur Info: Der ADFC Landhut plant gerade ähnliches - die Dimensionen bei dort sind halt andere :-)
Ob das Projekt letztendlich gemacht wird, ist noch unklar. Ich hatte dazu folgende Ideen, wie man es mit OSM unterstützen könnte:
-
Eine ausgedruckte Karte, auf der die zu untersuchenden Streckenabschnitte markiert sind. Die erfassten Daten werden dann wieder in OSM eingetragen. (Hier könnte es schwierig sein, die Notizen in der Papierkarte eintragen. Das wird man sehen). Ein entsprechendes Experiment mit qgis habe ich gerade gemacht, suche aber noch Vorarbeiten auf die ich aufsetzen kann, siehe auch qgis/QML Stile für Radwegedetails?. Die Karte, die ich aktuell habe, hat schon einige Lücken in den Daten aufgezeigt.
-
Ein App für das Smartphone, in dem ähnlich wie bei Streetcomplete die offenen Punkte beantwortet werden können. Siehe Angepasstes StreetComplete mit eigenen Quests?
Danke für die Info, sag Bescheid wenn sich die von dir angedachten Methoden in der Praxis bewähren. Viel Erfolg!
Ich bin noch dabei Breiten einzutragen, allerdings ist das mehr ein Privatprojekt von mir geworden als ein ADFC-Projekt, die Unterstützung der ADFC-Kollegen hält sich bisher in Grenzen. Bei mir ist es auf die von dieterdreist/Supaplex030 vorgeschlagenen Methoden rausgelaufen, d.h. JOSM + Luftbilder oder Mapillary + Pflastersteine zählen. In 90% der Fälle geht das ganz gut, weil sich in der Praxis rausgestellt hat, dass meistens nicht die Messgenauigkeit das Problem ist, sondern die schwankende Breite der Wege. Ich dachte erst ein Alkoholverbot für Bauarbeiter würde da vielleicht helfen, aber ein ADFC-Kollege hat mir erklärt, dass das Methode hat: Der Rad-/Gehweg wird gern als Pufferzone verwendet, damit die richtigen Verkehrsteilnehmer eine schön gleichmäßig breite Straße haben.
Manchmal nehme ich die Bilder des Bayernatlases zur Hilfe, da ist zwar die Qualität der Bilder oft besser, aber das Messtool ist für so kleine Abstände nicht gut geeignet.
Daran einen Maßstab bei Mapillary einzublenden bin ich gescheitert.
Ich kann nicht genau begründen warum, aber nach Messungen mit einem Geodreieck hatte ich auch das Gefühl, dass durch das sich öfter mal neigende Fahrrad und die perspektive Verzerrung sich damit auch keine wesentlich bessere Genauigkeit als bei Luftbildern erreichen lässt. Deswegen hab ich da nicht zu viel Zeit reingesteckt.
Wäre halt bei asphaltierten Wegen praktisch, bei denen die Sicht von oben durch Bäume versperrt ist.
Noch nicht ganz tot ist die Idee mit den Breitenklassen, deren Nutzen hauptsächlich darin bestehen würde, dass die Stadt Nürnberg selbst teilweise schon Breitenmessungen gemacht und veröffentlicht hat. Anscheinend hatten die auch das Problem mit den schwankenden Breiten und haben deshalb nur “von … bis” Klassen veröffentlicht.
Außerdem hat ein Kollege mit einer 360° Kamera experimentiert, die er nach unten gerichtet hat. Damit lassen sich die Breiten ganz gut messen. Leider fallen dabei Gigatonnen an Daten an und ich selbst habe keine derartige Kamera, so dass ich die Methode noch nicht in der Praxis eingesetzt habe.