StreetComplete - Finden von Stellen an denen highway=crossing fehlt

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?

Wurde vermutlich gesetzt weil es weiter unten auf https://wiki.openstreetmap.org/wiki/Key:crossing so definiert ist. Zitat

Wie schon eingangs erwähnt, ist die Definition des Tags ist etwas widersprüchlich/vaage. Einerseits heißt es “nur da wo nicht möglich / verboten”, andererseits werden als Beispiele reine Autoampeln gezeigt (und dort ist es ja wohl trotzdem möglich, als Fußgänger die Straße zu überqueren).

Ich denke der kleinste gemeinsame Nenner wäre dann tatsächlich für “crossing=no” “either not allowed or not possible or not suitable for safe pedestrian crossing”. Edit: Mit anderen Worten, heißt soviel wie “lieber Router, hier sollen Fußgänger nicht drübergeleitet werden”.

Jetzt polemisierst du aber :slight_smile: Ein Strawman wäre es gewesen, wenn ich dir diese Absicht konkret unterstellt hatte. Das habe ich nicht. Es war eine satirische Übertreibung, die verdeutlichen sollte, wohin es führen kann, wenn man reduntante physische Tags setzt, nur um zu dokumentieren, dass jemand vor Ort war und ein paar vorformulierte Fragen beantwortet hat. Dazu sind physische Tags nicht da, weder motorcar=yes noch highway=crossing. Dafür gibt es check_date, wie ich hier schon mal erwähnt habe.

Das klingt doch mal sinnvoll und entspricht vor allem der Bedeutung von highway=crossing.

Ich habe mir angewöhnt, alle Straßenüberquerungen, die als solche angelegt sind, als Fußgängerüberquerungen zu kennzeichnen. Als solche angelegt, kann sein:

crossing=marked: Zebrastreifen oder gestrichelte Linien rechts und links vom Übergang.

crossing=traffic_signals: Fußgängerüberweg mit Ampelregelung

crossing=unmarked: auf beiden Straßenseiten gegenüberliegend abgesenkter Bordstein, der darauf schließen lässt, dass hier Fußgängern erleichtert werden soll, die Straße zu überqueren, auf der Straße aber keine Markierung. Das findet man sehr oft im Kreuzungsbereich von Wohngebietsstraßen. Oder eine Verkehrsinsel als Querungshilfe in der Straßenmitte, aber auf den Fahrspuren keine Markierung und auch keine Ampel.

Beides sind für mich für Fußgänger vorgesehene Übergänge. Diese werden von mir als Linie mit den Eigenschaften
highway=footway + footway=crossing + crossing=unmarked/crossing=marked/traffic_signals eingezeichnet. Zusatzattribute wie crossing:island=yes können dies jeweils noch ergänzen.

Diese ganzen Zusatz-Attribute werden interessanterweise vom iD-Editor auch abgefragt, wenn man einen Übergang als Linie einnzeichnet, obwohl sie im OSM-Wiki nur im Zusammenhang mit dem punktuellen highway=crossing dokumentiert sind. Ich habe dann auch oft darauf verzichet, den Kreuzungspunkt mit highway=crossing zu versehen, weil sich ja im Grund alle Eigenschaften schon aus dem kreuzenden “way” (highway=footway + footway=crossing) ergeben. Ich sehe aber, dass in dem OSM-Wiki-Eintrag footway=crossing empfohlen wird, den Kreuzungspunkt auch einzutragen.

Da das Überqueren der Straße aber auch abseits solcher vorgesehenen Übergänge oft zulässig ist, erfordert Fußgängerrouting beim seperate Mapping von Gehwegen auch das Eintragen von virtuellen Verbindungen beider Straßenseiten. Diese zusätzlichen Querungsmöglichkeiten ergeben sich teilweise schon von allein, wenn man Grundstückszufahren einzeichnet. Grundstücckszufahrten sind auch noch aus einem anderen Grunde prädestiniert, die Fahrbahn an dieser Stelle zu queren: An dieser Stelle ist in der Regel ein abgesenkter Bordstein. Gibt es genügend, einander einigermaßen gegenüberliegende Grundstückszufahrten, verzichte ich auf das Einzeichnen von zusätzlichen virtuellen Querungsmöglichkeiten. Wo es diese nicht gibt, trage ich eine solche virtuelle Querungsmöglichkeiten nicht als linie mit footway=crossing und auch keinen Kreuzungspunkt mit highway=crossing sondern einen unspezifischen highway=path ein, der den Gehsteig auf der einen Straßenseite mit dem Gehsteig auf der anderen Straßenseite verbindet. Auch die Verbindung zwischen einem endenden Gehsteig und der Fahrbahn trage ich entsprechend ein. Das sind aus meiner Sicht nämlich keine Fußgängerübergänge im eigentlichen Sinne. In diesem Sinne finde ich Hungeburgs Vorschlag durchaus stimmig.

Allerdings frage ich mich:

Hm. Bei welchen eine Straße kreuzenden Fußwegen trifft das zu? Wenn es sich um einen reinen Radwegübergang handelte, wäre es ja kein Fußweg sondern ein Radwege. Wenn es sich um eine breite Straße handelt, bei der es in der Mitte eine bauliche Trennung gibt und nur eben zufällig an der gleichen Stelle die Gehsteige rechts und links enden und daher mit der Fahrbahnlinie verbunden werden müssen, dann wäre die bauliche Trennung für mich ein Grund, die Straße in zwei Linien (für jede Richtung eine) aufzutrennen.

Aber auch wenn ich mir gerade keine sinnvolle Antwort “=no” vorstellen kann, bereitet diese Frage die Beantwortung der zweiten Frage vor. Wenn man geantwortet hat, dass man an dieser Stelle die Straße überqueren darf versteht man auch wahrscheinlich, was damit gemeint ist:

Es ist ja die Frage, ob man die Straße hier einfach nur so überqueren darf oder ob es irgendeine bauliche Einrichtung (abgesenkter Bordstein, Farbmarkierung, …) gibt, der erkennen lässt, dass hier das Überqueren nicht nur erlaubt sondern speziell an dieser Stelle vorgesehen ist. Denn ich möchte nicht von meiner Routing-App als Autofahrer an jeder Stelle, an der das Überqueren der Straße zulässig ist, eine Ansage erhalten “Achtung Fußgängerübergang”. Diese Ansage macht aber durchaus Sinn an “echten” Fußgängerüberwegen, gleich welcher Art diese sind (marked, unmarked, traffic_signals).

Ob dann check_date:crossing der passende Eintrag dafür ist, zu dokumentieren, dass man hier die Straße zwar überqueren darf, es sich aber nicht um einen angelegten Übergang handelt, da bin ich mir noch unsicher.