Fahrspuren mit Richtungspfeilen erfassen; Wochenaufgabe in KW 47/48

Ich halte da eine Extra-abfrage für sinnvoller. Die Pipe-geschichte ist ja, wenn ich das richtig überblicke kein richtiger Fehler. (Edit: Die Pipe-geschichte is ja auch in aller Regel recht stumpfsinnig zu lösen (Sat-kucken; is ok; none dran) wenn da jetzt “richtige” Fehler hinzukommen, kommt man ausm schönen Trott ;))

Ok, aber Values mit beginnendem oder abschließendem | erschlagen ja das gleiche. Die sollten da noch mit rein.

Warum eigentlich dieses Aufhebens? Im Wiki wird ein leerer Wert sogar ausdrücklich empfohlen (wenn auch an anderer Stelle von “should use … ‘none’”) die Rede ist. In DE:lanes steht nämlich:

Und warum dass nun für maxspeed gelten soll, für turn:lanes hingegen nicht verstehe ich nicht. Natürlich ist das mit ‘none’ lesbarer und weniger fehleranfällig, aber jetzt unbedingt alles “aufräumen” zu müssen, das sehe ich nicht.

Warum ist 'turn:lanes=right" falsch? Ja, das ‘:lanes’ kann man weglassen. Aber schaden tut es auch keineswegs - die Aussage ist exakt dieselbe. Also: Einfach als Variante akzeptieren, beim neu mappen kann das ja jeder machen wie es im lieber ist.

Für mich: Viel Lärm um nichts. Widmen wir uns lieber echten Problemen und fehlenden Informationen.

Das halte ich für genauso falsch. Doch dort hat sich bisher niemand dran gestört. turn:lanes wurde laut taginfo bisher 83.000 mal getaggt, maxspeed:lanes nur 1.115 mal. Frei gelassenes Felder in maxspeed:lanes habe ich jetzt 60 gezählt. Bisher für niemand Grund gewesen, sich dort an Unübersichtlichkeit zu stören.

Als ich heute ein paar Eintragungen geändert habe, sind mir - wenn auch wenige - Fehler aufgefallen. Wohl daher rührend, dass man bei mehreren Strichen hintereinander durcheinander kommen kann.

Das turn Tag beschreibt eine einspurige Straße. turn:lanes bezieht sich auf mehrspurige Straßen. Bei turn kommt der | nie vor, bei turn:lanes immer. Alles andere ist falsch. Und den Fehler als Variante akzeptieren? Nein. Lieber gradeziehen und am Besten dafür sorgen, dass nicht mehr soviele Fehler neu auftreten können.

Bitte nicht! Wo kämen wir denn dahin? Zu OSM? :wink:
Das tagging muss im Wiki so festgezurrt werden, dass es nichts dran zu deuten gibt. Für jede Situation darf es keine 2 Meinungen geben.
Wir können doch nicht immer zu den Nutzern sagen: Hier habt ihr unser ungenaues tagging, jetzt seht mal zu, wie ihr damit arbeitet.

Um das ganze mal zu relativieren: Dass es hier gerade um diese beiden Values geht, ist eher Zufall, weil bei beiden ganz gut nachvollziehbar ist, was gemeint ist. Aber wenn du mal bei taginfo durchblätterst, steht dort richtig viel Schrott drin. Richtiger Schrott. ‘turn’ habe ich schon weitesgehend aufgeräumt, dort sah es ähnlich aus.
Soll der Router, wenn er ‘through’ sucht, auch ‘straight’ auswerten, weil einige das halt so eintragen?

Genau darum gings hier. Dank der Wochenaufgabe sind viele neue Eintragungen dazu gekommen, aber leider auch neue Fehler. Und ich sehe es als selbstverständlich an, nach getaner Arbeit aufzuräumen.

und die Erkenntnis

Da kommt man automatisch auch zum Schluß daß Mehrdeutigkeiten nicht gut sind. Sauber definierte und verwendete Tags sind extrem viel wert.

für mich haben wir das gerade mit der Wochenaufgabe getan… Die Nachbereitung zeigt nun die verbliebenen Arbeiten auf.

mein positives Fazit aus der Wochenaufgabe…

Sven

PS: .Ok… Ok… eigentlich war die Erkenntnis doch vorher schon da…

Das ist falsch. turn beschreibt einen Wert, der für alle Spuren einer Straße gleich ist. turn:lanes beschreibt einen Wert, der pro Spur unterschiedlich sein kann.

Wenn ich eine Software schreibe, die turn und turn:lanes auswertet, dann ist die automatisch in der Lage turn:lanes bei egal wievielen Spuren zu interpretieren. Eine einzelne Spur ist da einfach mit drin. Keine Sonderbehandlung von irgendetwas notwendig. Es ergibt sich automatisch. Deswegen macht ein turn:lanes bei einer einspurigen Straße nirgends ein Problem.
Ich weiß nicht, woher du darauf kommst, dass es ein Fehler sein sollte, turn:lanes bei einer einspurigen Straße zu verwenden. In beiden Fällen absolut eindeutig und absolut einfach auszuwerten.

Das ist etwas völlig anderes. ‘straight’ ist einfach nicht definiert. Es heißt ‘through’ und fertig.

Genau. Aber dort wo Mehrdeutigkeiten ausgeschlossen sind, braucht man nicht mit Gewalt auf ein einziges festes Tagging drängen.

Ack. Man kann trotzdem Dinge schön und konsistent machen. Wenn man grad dabei is. Und wenn man grad nich an fehlenden Infos is kann man die morgen machen.

Ich muss zugeben, dass ich bisher ohne none gemappt habe, einfach deswegen weil ich vergessen hatte, dass es existiert. Ein Problem damit, es zukünftig zu verwenden, habe ich nicht.

Allerdings sehe es auch nicht als Fehler an, das none wegzulassen, denn dann gilt einfach der Defaultwert, nämlich none. Ich finde es auch nicht wirklich eine Verbesserung, jetzt bei ansonsten richtigem Tagging noch “none” dazuzuschreiben – das halte ich für eine reine Geschmackssache, die man m.E. dem Mapper überlassen sollte, der die Straßen erfasst hat. Man sollte im Übrigen bedenken, dass leer lassen bei allen *:lane-Schlüsseln geht, “none” aber ein spezieller Wert von turn:lanes ist. Konsistenz in dem Sinne, dass nirgends doppelte Pipes vorkommen, wird es also schon von daher nicht geben.

Die Sache mit value “none” bei “turn:lanes” ist für mich ein Designfehler, da so unnötig eine Ausnahme von dem Grundprinzip beim lanes-Schema geschaffen wird. Das ist richtig unglücklich gelaufen und sollte geändert werden, auch wenn dies mit Arbeit verbunden ist. Wir machen es aber damit dem Erfasser und dem Auswerter einfacher.
So würde dann für alle :lanes: gelten: “Da wo nix ist, wird auch nix erfasst.”

Auch andersherum könnte man das natürlich allgemeingültig regeln durch: “Da wo nix ist, wird auch ‘none’ erfasst.”
Entscheidend sollte dabei sein, womit beide Seiten - Erfasser und Auswertung - am besten klar kommen.

Prinzip: one fact - one description
edit: Verständlichkeit

Mittlerweile ist die Wochenaufgabe seit fünf Tagen beendet. Die Anzahl der Neuerfassungen geht zurück. Insgesamt betrachte ich die Aktion als Erfolg, weil wir mehr Mapper für das Thema sensibilsieren konnten. Einige Probleme wurden gesehen, besprochen und werden beseitigt.
Ich habe vor, in den nächsten Tagen über die Ergebnisse und Erfahrungen etwas für den Blog zusammen zu fassen. Dabei will ich aber nicht nur meine eigenen Eindrücke verarbeiten, sondern auch eure mit einbringen. Was war gut, wo gab es Probleme und was könnte besser werden? Objektives und Subjektives von Anfängern und alten Hasen ist gefragt.
Damit die Meinungen nicht hier untergehen und zerredet werden, bitte ich euch, mir eure Beiträge per PN zu schicken. Ich würde die dann ungefiltert und anonymisiert verwenden. Allerdings bitte ich um sachliche zitierfähige Sprachwahl.

Alle Ideen, Erfahrungen und Kritiken möchte ich aber auch dahingehend verarbeiten, dass durch eine Überarbeitung des Schemas, eine klarere Wiki oder ein Tool zur einfacheren Erfassung alles wieder ins Projekt zurück fließt.

sorry, hat etwas gedauert aber die Abfrage sollte jetzt auch wege erschlagen, die mit pipe beginnen oder enden.

http://overpass-turbo.eu/s/6qC

ich mach mich dann mal an die arbeit :wink:

edit: sachsen ist sauber

Brandenburg auch… war bloß noch eine Kreuzung der B96 und eine Spur der A13… :slight_smile:

Danke für die Präzisierung der Abfrage…

Sven

wo wir schon im Regex-Wunderland sind: auch die Schlüssel lassen sich so bauen und das Ding wird fast zum Einzeiler (läuft auch etwas schneller :slight_smile: ).
Wir ignorieren auch mal großzügig, dass so auch ein Tag “turn” mit diesem Muster gesucht wird, was es aber lt. taginfo aktuell nicht gibt.

http://overpass-turbo.eu/s/6qG

vielen dank.
ich mach mich inzwischen an bayern zu schaffen. die a8 ist bereits fertig. münchen + etwas kleinkram muss ich noch abarbeiten. allerdings habe ich auch einen punkt gefunden, den ich mangels wissen nicht beheben kann:
http://www.openstreetmap.org/#map=18/47.71178/10.31458

hier sind die radfahrspuren mit als lanes erfasst, was laut wiki falsch ist. im thread wurde bereits darüber diskutiert, ich weiß. könnte mir dennoch bitte jemand erklären, wie hier das mapping korrekt wäre?

edit: hier das gleiche spiel: http://www.openstreetmap.org/#map=19/47.72405/10.33338

( http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension )

Hier ( http://www.openstreetmap.org/way/74393474 ) lanes=3 müsste lanes=2 heißen. Der Rest sollte stimmen. turn:lanes=“none|none|” macht zwar keinen Sinn, ist aber in Ordnung.
Abgesehen davon muss man sich an dieser Stelle sich für eine Variante entscheiden. Dort ist parallel noch ein cycleway eingetragen, den man entfernen müsste - Aufgrund der Lage der Radspur zwischen Hauptfahrbahn und Abbiegespur lässt sich die Situation mit einem eigenen Weg nicht abbilden.
EIn Stück weiter ( http://www.openstreetmap.org/way/268747288 ) stimmt lanes=2 aber nicht sondern muss lanes=3 sein.

An die Abfragen Experten:

Ist es möglich solche Abfragen zu basteln?:

Enthält nur die möglichen gültigen Values, also: reverse,sharp_left,left,slight_left, usw. (um Tippfehler oder anderes ungültiges zu finden.)
Aber da es ja Valueketten sind, wenn man z.B. sowas hat: ‘throught|right’. Wegen dem right würde es ja als gültig rausfallen, aber wegen dem Tippfehler mit ‘throught’, soll es trotzdem gefunden werden?

Klar doch: http://overpass-turbo.eu/s/6qL

ist aber nicht besonders gut getestet…

Hamburg ist auch bearbeitet. Eine Fahrradspur am Bahnhof Barmbek sowie je eine Bus-Spur am Flughafen und in der Amsinckstraße werden in der Overpass-Abfrage noch angezeigt.

Franz

Danke, das ist perfekt!

Was ich jetzt Stichprobenartig durchgesehen habe, sind alles echte Fehler.
Ich hatte mich die Tage mal ein bisschen eingelesen zum Thema overpass Abfrage mit der Erkenntnis, dass ich das nie hinkriegen würde. Schön, dass es so einfach geht :slight_smile:

Wäre auch solch eine Abfrage möglich?: (Ziel könnte ja sein, alles ungültigen Möglichkeiten in einer Abfrage zusammenzufassen als QA-Tool. Aber eines nach dem anderen…)

Also: Anzahl der ‘pipes(|)’ in turn:lanes ist einer weniger als Anzahl in lanes=x. Wobei das mit forward/backward etwas schwierig werden dürfte… Vielleicht erstmal der direktvergleich. Also lanes zu turn:lanes, lanes:forward zu turn:lanes:forward und tun:lanes:backward zu turn:lanes:backward.

Das geht alles leider nicht. Ich kann heute weder die Zahl der Pipes durch Zählen ermitteln noch diesen Wert für einen Vergleich mit lanes=x nutzen.
Höchstens ein Extrahieren von Wegen mit den entsprechenden Tags geht und irgendwas anderes zum nachbearbeiten.