StreetComplete - Finden von Stellen an denen highway=crossing fehlt

+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.

Hmm, ich habe da vorher nicht so darauf geachtet, aber quasi an jeder Kreuzung im Wohngebiet in Hamburg sind die Bürgersteige herabgesenkt.

https://www.google.de/maps/@53.5743853,9.9545519,3a,75y,18.16h,67.19t/data=!3m6!1e1!3m4!1sKoBfLp0-YRVnVoeu5_l2Sg!2e0!7i13312!8i6656

Wenn wir mal annehmen, dass diese Straße mit separat gemappten Bürgersteigen gemappt ist… reicht das nach Ansicht derer, die sagen, dass highway=crossing + crossing=unmarked nur gesetzt werden soll wenn dort eine “bauliche Einrichtung” existiert dann schon? Aus dem was ich bisher in diesem Thread las, hatte ich den Eindruck, dass highway=crossing an jeder Straßenecke im Wohngebiet vermieden werden soll.

naja, es soll Router geben, die werten das tatsächlich aus und geben bei jedem crossing eine Ansage “Achtung, Fußgängerüberweg!” aus. In meiner Gegend nervt mich das jetzt schon an jedem Kreisverkehr mit zwei Ansagen unmittelbar nacheinander, was soll das dann erst an jeder Kreuzung werden?

Moin,

+1
Man kann das quasi als “default” ansehen.
Von daher sollte ein explizites highway=crossing nur da eingesetzt werden, wo für beide Seiten ein quasi “unerwarteter” Übergang vorhanden ist.
Ein Zebrastreifen (mit Vorrang für Fußgänger) kann dann nochmals über das Subtag “verschärft” Fahrbahnnutzer zur Vorsicht mahnen.

Andererseits: Kann man dem Fußgänger(-router) mitteilen, dass dort ein abgesenkter Bordstein vorhanden ist (ist ja leider immer noch nicht überall der Fall) ohne einen highway=crossing zu setzen? So dass ein Router dass sinnvoll auswerten kann.

Grüße
georg

Bei abgesenktem Bordstein finde ich ein crossing völlig angemessen und für Fußgänger sehr nützlich. Wenn das zu ungewünschten Warnungen im Fahrzeug-Router führt, ist das ein Problem, das der Router lösen muss (vielleicht nicht mehr warnen vor crossing=unmarked?). Richtig taggen sollten wir trotzdem.

Ich finde ein “highway=crossing” + “crossing=unmarked” Quatsch. Ein “crossing” existiert für mich nur, wenn da irgendeine bauliche Einrichtung oder Markierung ist, die klar darauf hindeutet, dass hier eine Straßenüberquerung durch Fußgänger vorgesehen ist. Und dan ist das eben nicht “unmarked”.

Ein reiner abgesenkter Bordstein ist für mich noch kein Indikator einer “crossing”. Wenn jemand das unbedingt taggen will, soll er die Tatsache taggen, dass da ein abgesenkter Bordstein ist, aber nicht “raten”, dass dies vermutlich einen Fußgängerüberweg bedeuten soll.

Ja gut, crossing=unmarked existiert nunmal und wird auch en mass genutzt.

Laut OSM-Wiki wird die typische als Querungshilfe gebaute Verkehrsinsel dann als crossing=unmarked bezeichnet, wenn auf der Fahrbahn selber keinerlei Markierungen vorhanden sind. Das jetzt zu diskutieren wäre müßig, da es das Ergebnis eines längeren Diskussionsprozesses zu sein schein.

vgl.:

highway=crossing
https://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dcrossing
bzw. https://wiki.openstreetmap.org/wiki/Tag:highway%3Dcrossing

crossing=marked
https://wiki.openstreetmap.org/wiki/DE:Tag:crossing%3Dmarked
bzw. https://wiki.openstreetmap.org/wiki/Tag:crossing%3Dmarked
(hier scheint es allerdings im Umgang mit Zebrastreifen Uneinheitlichkeit zu geben: crossing=zebra, crossing=marked oder crossing=uncontrolled)

crossing=unmarked
https://wiki.openstreetmap.org/wiki/DE:Tag:crossing%3Dunmarked
bzw. https://wiki.openstreetmap.org/wiki/Tag:crossing%3Dunmarked

Auch das Einzeichnen eines Fußgängerüberwegs als Linie mit Zusatzattributen ist dokumentiert.
footway=crossing
https://wiki.openstreetmap.org/wiki/Tag:footway%3Dcrossing