Falls du mich meinst (hast ja nichts zitiert): Nein, das meine ich nicht. Ich habe doch ausdrücklich geschrieben, dass das Tag auch einfach ungesetzt sein kann.
highway=crossing heißt laut Wiki: Hier kommst du zu Fuß besonders gut rüber (Zebrastreifen oder was auch immer) bzw. heißt für den Autoverkehr: Vorsicht, hier kreuzen Fußgänger bevorzugt.
crossing=no heißt laut Wiki: Hier kommst du zu Fuß nicht rüber.
Wo keines von beiden gegeben ist, ist einfach nur der Kreuzungs-Node ohne weitere Tags.
hw=crossing impliziert für mich eine baulich gestaltete Einrichtung, um eine Straße zu überqeueren, also z.B. eine Verkehrsinsel oder einen Zebrastreifen. Alles andere ist einfach nur ein “Hier trifft ein Weg auf einen anderen”.
Muss StreetComplete eigentlich wirklich alles abfragen? Spätestens wenn dann noch ein Tag gesetzt wird, nur damit nicht nochmal gefragt wird, ist das auch für mich
Dazu kommt, dass ich den Eindruck habe, dass bereits jetzt Fragen falsch verstanden werden (können), wie z.B. die Frage nach “kind of building” siehe https://www.openstreetmap.org/note/2712977. Je komplexer StreetComplete hier wird, umso mehr schleichen sich Fehler ein, vor allem wenn User meinen, sie müssen die Frage irgendwie beantworten.
In deinem ersten Beispiel oben im Eingangsposting kreuzt ein hw=footway eine Straße.
Dass dort Fußgänger die Straße überqueren können, geht aus den zwei Ways schon hervor, denn wenn sie es nicht könnten, wäre das schlicht und einfach falsch gemappt, dann dürfte der hw=footway hier nicht durchgängig gemappt sein.
Welchen Mehrwert bietet dann ein highway=crossing auf dem Kreuzungsnode? Wieso “fehlt” das deiner Meinung nach, wenn es nicht getaggt ist? Die Information, dass da ein Fußweg die Straße kreuzt, geht doch aus den Ways schon hervor; das nochmal an den Node zu taggen ist schlicht redundant.
Ich sehe das so (und das Wiki offenbar auch), dass das Tag hw=crossing nicht einfach nur heißt “hier geht ein Fußweg rüber”, sondern “Diese Stelle ist so gebaut, dass Fußgänger bevorzugt und sicher hier die Straße überqueren können”. Also ein Zebrastreifen, eine Mittelinsel, eine Furt oder so was. Also eben nicht einfach nur jede Stelle, wo ein Fußweg über eine Straße geht, sondern eine besondere Ausführung einer solchen Querung.
Dir geht es aber offenbar darum, dass in jedem Fall, wo ein hw=footway eine Straße kreuzt, ein hw=crossing gesetzt werden soll. Das hat zur Folge, dass die Kreuzungen, die baulich speziell für die Überquerung gestaltet wurden, sich taggingmäßig nicht mehr von “einfach so, hier kannste rüber” Kreuzungen abheben. Und das ist in meinen Augen ein Informationsverlust!
Also was verbieter mir (außer der gesunde Menschenverstand vielleicht) hier die Straße zu überqueren?
Ansonsten halte ich es wie die Vorredner: hw=crossing sollte besonderen Fällen von Straßenquerung vorbehalten sein. Sonst können wir bald alle Straßen(-T-)kreuzungen mit einem gesonderten Tag verseehen, oder wie…?
Wenn ein separat gemappter Fußweg auf eine Straße trifft, an welcher die begleitenden Fußwege mit sidewalk=* an der Straße gemappt sind, muss der Fußweg mit der Straße verbunden werden. Ob man an dieser Stelle die Strasse zu Fuß überqueren kann/darf ist damit nicht gesagt.
Trotzdem ist es nicht sinnvoll, hw=crossing an Kreuzungspunkten zu setzen, an denen es keinerlei besondere Markierung oder Einrichtung gibt. Ob eine Straße überall oder nur an dafür vorgesehenen Stellen überquert werden darf, ist eine Eigenschaft der Straße. Wenn die Straße überall gequert werden darf, dann auch an einem Verbindungspunkt mit einem separat gemappten Fußweg, ohne dass das explizit angegeben wird. Wenn die Straße nur an dafür vorgesehenen, markierten bzw. mit Querungshilfen versehenen Stellen überquert werden darf, dann braucht das Fehlen solch einer Markierung/Einrichtung an einem Verbindungspunkt nicht explizit gemappt zu werden. Es sei denn als Merker für das Tool
Wie man erkennt, ob eine Straße von Fußgängern an jeder beliebigen Stelle überquert werden darf oder nicht und wie man das mappt, ist eine andere Frage. An jeden Punkt einer Straße ein crossing=yes/no zu setzen ist jedenfalls der falsche Ansatz.
Um solche Fälle geht es hier auch nicht, siehe letztes Beispiel im Eingangsposting. Das soll ausdrücklich ausgenommen werden. Dennoch finde ich es nicht sinnvoll, jede Kreuzung einer Straße mit einem (nicht straßenbegleitenden) Fußweg als hw=crossing zu taggen. Aber das schreibst du ja auch so.
+1 für crossing, wenn auch kerb dazukommt. Ohne kerb finde ich crossing nur in Ausnahmefällen sinnvoll, z.B. Zebrastreifen.
Für kerb=flush o.ä. setze ich auch crossing=unmarked, wo man gut mit Rolli / Kinderwagen rüberkommt. Natürlich nicht alle 5m, aber wenn sowieso schon ein Node liegt, oder bei Bushaltestellen…
Dein Standard-Wohngebiet (1).
Wenn die Eingänge gegenüber liegen (oder annähernd so), kann man ohne viel Inkorrektheit sich den Extra-Way sparen und durchbinden: (2).
(way 239474042).
Die würde SC jetzt wohl alle flaggen.
Irgendwann flaggt SC so viele vermutliche Dinge und wird qua der schieren Menge an “hier könnte …” nutzlos. So’n bisschen wie keepright.at, das auch etliche False Positives zeigt.
Hui, highway=crossing bei Garageneinfahrten, das ist schon hart das zu verargumentieren. Wie in dem Ticket schon angemerkt wurde, sind Einfahrten ja in der Regel auf dem selben Kantsteinlevel wie der Bürgersteig selbst. Naja, ich würde sagen, StreetComplete sollte sämtliche highway=service ausklammern, selbst wenn vielleicht bei einigen (Einfahrten zu großen Firmen, Parkplätzen,…) ein Zebra-Streifen oder sowas zu erwarten wäre.
Diese “fehlenden Übergänge” (footway kreuzt Straße und wird zu service) zu finden ist technisch natürlich möglich, jedoch wenn ich mir das Feedback bisher hier im Forum anschaue vermutlich unerwünscht. Zumal viele highway=service ja private Einfahrten sind, auch wenn das entsprechende Tagging oft fehlt.
Übrigens, Hungerburg, ich war dann auf dem Hafelekar and dem Tag als es das Gewitter mit Hagel gab… schnell noch vor dem Gewitter hier runter https://www.openstreetmap.org/way/121523168 zur Seegrube und hing dann dort eine Weile fest weil sie aus Sicherheitsgründen die Seilbahn abgeschaltet hatten. War aber sehr cool, sehr abenteuerlich
An alle diejenigen die die Meinung vertreten, für bestimmte Überwege sollte garnichts getaggt werden wenn weder ein “bevorzugter Überweg” vorhanden ist, noch “Übergang nicht möglich”. Oder mit anderen Worten: “Man braucht keinen Tag setzen, wenn dort nichts ist”, also “lit=no”, “oneway=no”, “sidewalk=no”, “cycleway=no” usw usf sei unsinnig.
Der Grund soetwas zu taggen ist eben, um zu markieren, dass hier schonmal jemand war und dies überprüft hat. Also die Unterscheidung zwischen “hier nicht vorhanden” und “noch nicht gemappt”. Das ist nicht nur wichtig “für das Tool”, sondern für alle Vor-Ort-Mapper denen daran gelegen ist die Informationen vollständig flächendeckend zu erfassen. Siehe auch https://wiki.openstreetmap.org/wiki/StreetComplete/FAQ#Why_does_StreetComplete_often_tag_the_absence_of_features.3F
Ich weiß noch, vor ein paar Jahren gab es noch Leute hier im Forum, die die Meinung vertraten, man solle surface=asphalt nicht taggen, weil das ja “der default und ja klar sei”.
So, das soll natürlich nicht heißen, dass StreetComplete an jede Straße ein oneway=* klatscht oder in diesem Fall an jede Kreuzung zwischen Fußweg und Straße ein crossing=no oder highway=crossing. Auch wenn es nicht schadet, ist es In vielen Fällen eine Information ohne Wert.
Wir haben schon ein Beispiel wo dies explizit nicht passieren soll:
Gibt es noch Orte oder Konfigurationen, an denen aus den Tags der beteiligten Element klar ist, dass ein Fußweg der eine Straße kreuzt, keine Information über crossing ja / nein benötigt?
Ich spiele nach dem Feedback hier im Forum zum Beispiel mit dem Gedanken, für Fußwege die highway=residential wie auch highway=service kreuzen auch nicht zu fragen, da wie von mehreren schon erwähnt, Wohngebietsstraßen in der Regel so überschaubar sind, dass man sie überall überqueren kann bzw. es normalerweise keiner Infrastruktur für dedizierte Füßgängerüberwege bedarf. Andererseits, wir sind zwar hier im deutschen Forum, aber ich als Tool-Entwickler muss auch die internationale Perspektive im Blick haben. “Jaywalking” z.B. “is a thing” in den USA.
Ich glaube, viele Tags sind gesetzt, weil der Editor es zulässt und der unbedarfte User meint, er müsse das setzen, z.B. alle möglichen access-Werte bei einem einfachen hw=footway.
Warum möchtest du denn mit allen Mitteln etwas in die Datenbank schreiben, obwohl da nichts ist? Nur damit SC nicht nochmal fragt? Wenn das jede App machen würde…
Wir müssen mal grundsätzlich klären, was highway=crossing bedeutet:
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
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.
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…
abgesenkter Bordstein oder nicht: kerb=*
taktile Pflasterung für Sehbehinderte oder nicht: tactile_paving=*
verengung der Fahrbahn / andere Verkehrsberuhigung oder nicht: traffic_calming=*
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.
