StreetComplete - Finden von Stellen an denen highway=crossing fehlt

Wir müssen mal grundsätzlich klären, was highway=crossing bedeutet:

  1. Bedeutet es “hier ist extra was dafür angelegt, dass Fußgänger sicher über die Straße kommen” (also ein Fußgängerüberweg) oder
  2. bedeutet es “hier kann ein Fußgänger die Straße überqueren” (im Sinne von es ist weder unmöglich noch verboten)?

Ich persönlich kreuze 1 an, die Mehrheit hier ebenso (soweit ich sehe) und auch das Wiki (so wie ich die Seite verstehe).
Dieser SC-Vorschlag zielt aber auf Bedeutung 2 ab (oder die Frage ist falsch formuliert).

Das funktioniert nicht. einen Zebrastreifen tagge ich auch nach Luftbild als highway=crossing, das heißt also nicht, dass jemand vor Ort war.
Dafür gibt es check_date.

@FraukeLeo - wenn ich westnordost richtig verstehe, dann geht es eben darum, Kriterien zu finden, damit die Frage nur dann gestellt wird, wenn 1) aufgrund der OSM Daten eine gewisse Wahrscheinlichkeit zukommt. Dann ist die Frage nicht mehr so daneben. Zumindest wenn die Daten stimmen. Die Gehwege im post von @jengelh sind so ein Fall für inkorrekte Daten. Das betrifft nicht nur SC, man spart ein paar Knoten, eine gesprochene Navigation redet dann Blödsinn.

Ich hab aber auch ein Problem mit StreetComplete: Leicht off-topic - Es wird geantwortet, selbst wenn die OSM Daten falsch sind!

Beispiel 1: Auf ein “unclassified” kommt, “kein Radweg”, weil die Geschwindigkeitsbegrenzung nicht erfasst worden ist.

Beispiel 2: Die Zufahrt zu einer Tankstelle bekommt “kein Radweg”, weil sie als “primary_link” getaggt ist. Richtig wäre vielmehr, “das ist gar kein “primary_link” hier!”

Da würde es einen logischen Problemlöser brauchen, der mehrere Quests in Abhängigkeit voneinenander in der richtigen Reihenfolge anbieten würde. Gewöhnlich sitzt der/die vor dem Bildschirm, aber man weiß ja nie

Ich würde ja sagen Nr. 1 stimmt.
Was dem allerdings widerspricht, wäre dann crossing=unmarked, oder? Was ist crossing=unmarked überhaupt genau? Sind Überwege mit Insel aber ohne sonst etwas dann schon unmarked, weil es keine Straßenmarkierungen gibt? Check da das Wiki irgendwie nicht so ganz.

EDIT: Achso, hat’s gecheckt, crossing=unmarked ist tatsächlich für Überwege, die als Überweg erkennbar sind, aber keine Markierungen auf der Straße haben (also z. B. diese Inselüberwege).

Auch das Wiki sieht meinem Verständnis nach hinter crossing eine bauliche Einrichtung, die explizit für das Überqueren des zu kreuzenden Weges errichtet worden ist. Dies ist aber nicht immer gegeben. Von daher dürfte auf eine positive Antwort auf die Frage Kann hier ein Fußgänger die Straße überqueren? nicht automatisch zu einem highway=crossing führen. Bei negativer Antwort ist ein crossing=no denke ich durchaus angebracht.

Genau.

Eventuell könnte man die Quest irgendwie in zwei Fragen aufteilen?

Zunächst die Frage Kann hier ein Fußgänger die Straße überqueren?

Falls das mit “ja” (also zumindest nicht mit einem eindeutigen “nein”) beantwortet wird, wird erstmal nix gesetzt.

Dann käme noch eine zweite Frage:
Gibt es hier für Fußgänger eine besondere bauliche Einrichtung (z. B. Querungshilfe) oder Straßenmarkierungen, um das Überqueren zu erleichtern?

Falls das grundsätzlich mit “ja” beantwortet wird, wäre das ein Hinweis auf ein zu setzendes highway=crossing. Dann müsste noch die Art des Überwegs bestimmt werden.

Die Frage ist nur mal wieder, was macht man mit diesen Zwischen-Dingern. Also wo man die Straße schon überqueren kann, nur einen bauliche Einrichtung gibt es halt nicht.

Es müsste noch ein drittes Tag, so etwas wie highway:crossing=no geben. Also dort, wo sich zwei “weggehende” Fußwege treffen, und man kann die Straße überqueren, aber es gibt keine bauliche Einrichtung.

Das ist etwas anderes als crossing=no. crossing=no heißt ja, Überqueren ist entweder überhaupt nicht möglich und/oder aber nicht erlaubt an dieser Stelle.

Das beträfe dann genau diese Fälle, die Westnordost erwähnt hat. Dieses “es war jemand da und hat geprüft, dass da kein baulich eingerichteter Überweg ist”.

Ich finde aber auch, dass man es manchmal wie hier: https://www.openstreetmap.org/node/188810235/ machen muss (bitte meinen neuesten Edit beachten). Die beiden Gehwege treffen sich nicht 100%ig an ein und derselben Stelle. Ich habe die beiden aber an dem Überweg zusammengeführt. Ich meine, wenn schon einer da ist. Es ist ja jetzt nicht so, als würde der eine Weg erst hunderte Meter in OSM an der Straße entlang “mitlaufen”. Ich glaube, zumindest bei einigen dieser fraglichen Fälle könnte eventuell just so eine Art der Einpflegung fehlen.

Wie sähe denn eine bauliche Einrichtung aus die keine Markierungen hat? Die typische Querung dieser Art stelle ich mir vor als eine mit Verkehrsinsel. Aber ob Verkehrsinsel vorhanden ist, ist ja ein separater tag - crossing:island=yes/no bzw. veraltet crossing=island.

Betreffend baulicher Einrichtung gibt es auch getrennte tags für…

  1. abgesenkter Bordstein oder nicht: kerb=*

  2. taktile Pflasterung für Sehbehinderte oder nicht: tactile_paving=*

  3. verengung der Fahrbahn / andere Verkehrsberuhigung oder nicht: traffic_calming=*

  4. Ampelanlage vorhanden / Markierungen vorhanden: crossing=*

  5. Verkehrsinsel vorhanden oder nicht: crossing:island=*

Insbesondere ist für mich die offene Frage, inwiefern sich ein highway=crossing + crossing=unmarked ohne jegliche der o.g. Features dann von einer informellen Querung unterscheidet, also “hier sind kreuzende Fußgänger zu erwarten, weil ein Weg die Straße hier kreuzt, aber es gibt keine dedizierte Querung”.

Sollte highway=crossing + crossing=unmarked bedeuten dass mindestens einer der o.g. Features vorhanden ist, dann wäre der Tag crossing=unmarked ja quasi sinnlos, weil er Information dupliziert.
Aus meiner Sicht ist die Definition crossing=unmarked als “hat mindestens eine bauliche Einrichtung” nicht sinnvoll, da diese Information anhand anderer Tags erfasst wird. Die Information “hat irgendeine bauliche Einrichtung” (aber unklar welche) alleine ist auch keine Information mit der man viel anfangen kann.

Edit:

Auf taginfo gibt es crossing=informal, aber wenig genutzt und nicht dokumentiert:
unmarked - 842883 Nutzungen
informal - 184 Nutzungen

Na ja, ich weiß nicht…
Also das/die Wiki meint ja glaube ich, dass crossing=unmarked dort verwendet werden soll, wo zwar baulich irgendwas ist, aber nichts davon auf die Straße gemalt ist. Also weder eine gestrichelte Linie (kreuzende Radwege, Ampelüberwege…) noch ein Zebrastreifen.

Das heißt, crossing=unmarked wäre a) ein Überweg an einer Wohnstraße, wo “nur” der Bordstein abgesenkt ist und b) Inselüberwege (ohne “Sonstiges” weiteres).

Natürlich werden crossing:island=yes und kerb=lowered separat erfasst, klar. Aber beide Dinge können auch z. B. bei einem Zebrastreifen vorkommen. crossing soll(te) ursprünglich einfach den “Typ” des Überwegs festlegen…

Auch wenn das dann noch durch crossing_ref irgendwie “erweitert” wurde.

crossing=unmarked heißt halt, Überweg, bei dem nix auf die Straße gepinselt ist, wo aber trotzdem irgendwie ein Überweg erkennbar ist. Zugegeben könnte crossing=unmarked dann z. T. auch entfallen. Ach ich weiß es nicht. crossing=* ist halt der Unterkey von highway=crossing und gibt den Typ an. Also Markierung auf der Fahrbahn da: ja, Markierung auf der Fahrbahn da: nein und “Ampelüberweg” als dritter Typ.

Ich hätte eine informelle Querungsmöglichkeit bisher nicht als ausreichenden Anlass gesehen, ein highway=crossing zu setzen. Ich würde selbst für crossing=unmarked zumindest z.B. zwei einander gegenüber liegende Absenkungen im Bordstein erwarten – irgendein Indiz dafür, dass hier ein Übergang vorgesehen wurde.

Es ist natürlich eine berechtigte Frage, ob das so auch die beste mögliche Definition ist. Aber ich finde eine Mindestvoraussetzung für highway=crossing, die über die informelle Möglichkeit zur Querung der Straße hinausgeht, eigentlich schon irgendwo eine sinnvolle Abgrenzung, weil es entlang einer typischen Wohngebietsstraße sonst quasi ein kontinuierliches highway=crossing gäbe: Man könnte dann theoretisch alle paar cm mit gleicher Berechtigung so einen Node setzen.

Ist klar, dass StreetComplete diese Unterscheidung braucht, aber so etwas gibt es aktuell nicht für alle Features. Definitiv nicht für Geometrien (wir mappen ja z.B. Flächen ohne Gebäude nicht mit einem nobuilding=yes-Polygon, damit man feststellen kann, ob die Gebäude vollständig sind), aber auch für etliche Attribute gibt es entweder kein etabliertes Tagging für die Abwesenheit davon oder das explizite Setzen von Defaults ist zumindest kontrovers. Hast du mal überlegt, ob du in solchen Fällen nicht check_date bzw. Subtags davon verwenden könntest? Nutzt du ja bei wiederkehrenden Quests eh schon beim 2. bis n. Mal, um die Quest zu deaktivieren – warum nicht schon beim 1. Mal?

Damit könnte StreetComplete in der OSM-Datenbank vermerken, dass hier schon mal ein User das Nichtvorhandensein einer Querungshilfe bestätigt hat. Besser wäre es allerdings, wenn SC diese Information extern oder zumindest in SC-spezifischen Tags ablegen würde. Sonst endet das irgendwann noch damit, dass die Landschaft mit building=no, tree=no, usw. zugepflastert ist, weil die Frage “Steht hier ein Gebäude/Baum/…” mit “Nein” beantwortet wurde.

+1. Oder jeder highway=unclassified bekommt zusätzlich noch ein motorcar=yes, weil SC gefragt hatte, ob da Autos fahren können, und die Beantwortung der Frage ja irgendwie abgelegt werden muss :slight_smile: :slight_smile:

Dieses Tagging, um zusätzlich zum Vorhandenen auch noch eine Vor-Ort-Überprüfung zu dokumentieren, geht IMHO in eine komplett falsche Richtung. Ein Tag bildet einen nachprüfbar vorhandenen Sachverhalt in der Datenbank ab, aus welcher Quelle auch immer, und nicht, ob jemand das überprüft hat oder nicht. Wenn ein hw=footway mit einem shared node eine Straße überquert, dann ist IMHO damit schon ausreichend abgebildet, dass Fußgänger da rüber können. Da noch ein hw=crossing + crossing=unmarked dranzutaggen bietet keinen Informationsgewinn.

+1

Zudem ist das auch nicht zukunftssicher. Was ist denn, wenn da etwas umgebaut wird? Wird SC das irgendwann “merken”? Oder kommt dann “Ist da immer noch ein irgendwas?” und das wird wieder irgendwie gespeichert? Besser wäre ein tagging a la check_date:crossing=*". Persönlich finde ich das ganze allerdings insgesamt überflüssig…
Nebenbei: Die Pseudovervollständigung mitsamt den vielen “Fehlermeldungen” beginnt auch immer mehr zu nerven…

In der Tat ist die derzeitige Entwicklung schwierig. Es geht immer um die Abgrenzung, wo irgendein Sachverhalt zumindest mit einem -gewissen- Prozentsatz wahrscheinlich sein könnte (also z. B es könnte ein Radweg da sein, genauso gut könnte aber auch keiner da sein).

Und für diese Fälle “eventuell könnte hier dies und dies sein, das kann mal einer überprüfen” werden jetzt immer mehr Beispiele gesucht. Also was könnte da noch an Tags dran, was könnte hier noch an Tags dran…

Wenn es um die Ausstattung irgendwelcher Dinge geht (Ampelaussattung etc.) oder darum, die Existenz von Sachen zu überprüfen, dann hat die App da auf jeden Fall ihre Stärken.

Aber ich weiß nicht, ob das Hinzufügen von Sachen auch in deren Kernkompetenzbereich fällt. In Editoren, und selbst sei es Vespucci etc., hat man oft den besseren Überblick über Sachen drumherum. Also Luftbilder vergleichen, ggf. Nodes verschieben etc.

Gerade bei Überwegen erlebe ich es oft, dass Wegübergänge nicht ganz lagegenau sind. Ich möchte niemanden schlechtreden, aber vielleicht gibt es irgendwo auch mal Grenzen.

Nur mit OSM ist es ja generell so mit dieser “Nie-genug-bekommen”-Entwicklung. Das ist ja vom Grundsatz her auch etwas sehr, sehr Menschliches, was wir wahrscheinlich alle von uns irgendwie kennen. Nur dann wird’s halt irgendwann schwierig.

Bitte keine Übertreibungen und kein Strawman, das bringt niemandem weiter und ist der Diskussion nicht zuträglich.

Das macht StreetComplete ganz bewusst nicht, denn diese Art von Information ist eben nicht SC-spezifisch, sondern dient grundsätzlich jedem Surveyor. Außerdem ist es oft nicht klar trennbar, welche Informationen quasi für Datennutzer keinen Mehrwert bieten sondern nur für Mapper und welche Informationen trotzdem auch für andere Datennutzer einen Mehrwert bieten. Interessiert es beispielsweise nur andere Mapper, wo eine Straße **nicht ** (lit=no) beleuchtet ist? Eher nicht! Interessiert es nur andere Mapper, wo Öffnungszeiten nicht öffentlich aushängen (opening_hours:signed=no)? Wahrscheinlich schon - aber man kann nie wissen! Interessiert es nur andere Mapper, dass ein Überweg keine baulichen Einrichtungen hat bzw. nicht markiert ist? Mir würde schon ein Anwendungsfall dafür einfallen - errechnen eines Walkability-scores z.B., oder wie auch cycleway=no, finden von Lücken in Fahrrad- und Fußgängerarchitektur für mögliche Maßnahmen.

Du sagtest ja glaube ich, Wohnstraßen würdest du ausklammern wollen, oder? Weil ich denke auch, die meisten Überwege “ohne alles” kommen dort vor, wenn man die dann Überwege nennen kann, weil in d. R. kann man da ja dann halt überall queren.

Interessant wäre mal zu wissen, was genau denn vielleicht diese Fälle wären, wo SC mit der Qiest ansetzen würde. Also welche Nodes “befragt” werden würden. Vielleicht kann da jemand eine Overpass-Query für basteln? Eventuell könnte man sich das dann mal in so einer Stichprobe oder so mal angucken und dann schauen, ob man da irgendeine Art von weiterführendem Ergebnis sage ich mal herausbekommt. Also sprich, wo hätte vielleicht wirklich ein Überweg in OSM gefehlt usw.

Ich würde sagen, es gibt genug Übergänge, an denen der Bordstein nicht abgesenkt ist. Eventuell nicht so viele in Deutschland, aber anderswo.

Betreffend “alle paar cm setzen”: Ich möchte ja nicht an jeder Node setzen, sondern an der Node, an der es eine gewisse Wahrscheinlichkeit gibt, dass genau hier Fußgänger die Straße überqueren wollen. Also an Stellen, an denen Router-Software Fußgänger entlangrouten möchte. Nämlich dort, wo ein Fußweg eine Straße kreuzt.
Wenn man sagt, “gut, diese Information ist aber im Wohngebiet irrelevant, weil man eigentlich überall außer in seltensten Einzelfälen die Straße queren kann”, dann könnte man ja explizit Wohngebietsstraßen davon ausklammern.

Ja, das war ein Vorschlag. Zzt liegt das Feature aber sowieso auf Eis, bis die Taggingfragen, also speziell die Definition von crossing=unmarked geklärt ist.

Ich fürchte, daraus dass hier einige Leute sagen was sie darunter verstehen, ist auch nicht allzu hilfreich hier eine abschließende Antwort zu finden. Man müsste mal stichprobenartig nachprüfen, wie der tag in der Realität verwendet wird. Das wird einigermaßen aufwändig sein.

Vielleicht alle highway=residential ausklammern, außer jene, die ein maxspeed>30 oder ein lanes>2 haben. Und vielleicht zusätzlich noch alle Straßen mit lanes=1 zusammen mit maxspeed kleiner gleich 30 ausklammern?

Eventuell wäre das ja was…

Aber mit crossing=unmarked das stimmt schon, da muss man irgendwie “aufpassen”…

Hier in der Stadt gibt es zweimal “crossing=no” - einmal die beschriebene Situation, wo ein getrennt erfasster Radweg auf als Attribut erfasste Radwege trifft - Es stimmt sogar! Einmal an einer reinen Autoampel. Sinnlos?

Es gibt 19 “crossing=unmarked” - Vor allem wo getrennt erfasste Gehwege eine Straße, manchmal auch eine Parkplatzeinfahrt, meistens queren, manchmal aber auch nur tangieren. Sehr bunt das, wahrscheinlich oft einfach gesetzt, weil als notwendig empfunden? Ein einziges Mal nur ein nackter Punkt an der Straße, dort wo eine Insel ist, aber kein Schutzweg.

Fragenkatalog Idee (deontische Logik :))

  1. Darf man hier die Straße überqueren?
  • Nein, crossing=no
  • Ja, weiter
  1. Kann man die Straße hier an einem Übergang queren?
  • Nein, fertig - check_date:crossing
  • Ja, weiter
  1. Welche Art von Übergang ist es?