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:
1 Like
Also 0.2 m Genauigkeit sollten es schon sein.
3 Likes
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.
2 Likes
Wohl wahr. Ich hab’ in meinen Strava-Aufzeichnungen gesucht:
Hierzu
gab es den Kommentar:
Leider hatte ich es unterlassen, die Breite zu erfassen 
1 Like
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.
2 Likes
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.
2 Likes
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.)
5 Likes
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?