es geht um diese Brücke (rechte Seite): OpenStreetMap. Ich hatte vor geraumer Zeit die darunterliegenden Straßen am Brückenumriss (“man_made=bridge”) aufgeteilt, um die Straßenstücke mit “maxheight” zu taggen. Was nicht direkt erkennbar ist: Auf dem Brückenumriss liegt im Norden und Süden jeweils noch ein Weg mit “barrier=fence”. Geländer und auch Brückenumriss haben natürlich “layer=1”. Brückenumriss, Straßen und Geländer teilen sich Nodes, d.h. der Node, an dem die Straße geteilt wurde ist auch Teil des Umrisses und Teil des Geländers. Alles kein Problem: kein Validator (in meinem Fall: JOSM) hat sich beschwert, das Routing funktioniert.
Nun hat ein StreetComplete-Nutzer offenbar eine Frage zu einem der geteilten Nodes bekommen, konnte diese nicht beantworten und hat einen Hinweis erstellt: Note: 4178908 | OpenStreetMap.
Frage in die Runde: Ist die durchgeführte Behebung des Hinweises so korrekt oder ist das eigentlich ein Problem von SC? Der geteilte Node an sich ist ja keine Barriere, nur eine der Linien zu der er gehört. Und die ist korrekt mit “layer=1” getaggt.
Ich sehe das wie wies: wenn zwei OSM-Objekte sich einen gemeinsamen node teilen, impliziert dies, dass sie es auch in der Realität tun. Bei sich kreuzenden ways mit verschiedenen layer ist das realistisch schwer vorstellbar (ausgenommen ein Aufzug). Kreuzen sich Straße und ein Geländer, bedeutet das, das Geländer steht quer auf der Straße. Bei einem gemeinsam geteilten Punkt weiß dann auch keiner, von welchem. way der layer zu übernehmen ist. Ich finde die Fragestellung von SC richtig! Wenn vorher kein Validator rumgemeckert hat, liegt dort der Fehler.
Ketzerisch formuliert: wenn jahrelang postuliert wird, dass JOSM alles richtig macht und SC (und iD) nur Murks produzieren, kommt das dabei raus. Auch JOSM-Programmierer übersehen etwas oder machen Fehler.
Eine nicht implementierte Prüfung würde ich nicht als Fehler sehen, aber ganz sicher mach JOSM genauso wenig alles richtig wie irgendeine andere hinreichend komplexe Software.
Ob eine Prüfung implementiert wird hängt von vielen Dingen ab, z.B.
ist es schon mal einen Entwickler untergekommen (z.B. als Ticket)?
zumindest das “Huntestraße” Beispiel ist ziemlich sicher eine Brücke, das Wehr liegt darunter (vermute ich, soweit in propriertären Bildern erkennbar). Wenn es keine Brücke gibt, wäre es ein “ford”, was ich aber für unwahrscheinlich halte, weil bei einem Wehr normalerweise signifikante Strömung herrscht, so dass eine etwas hinter dem Wehr liegende Furt mehr Sinn machen dürfte.
genau, so würde ich es sehen, die Brücke ist kein Teil des Wehrs bzw. vielleicht schon, aber das ist nicht relevant, für uns ist es einfach eine Brücke, was darunter liegt oder davon erschlossen wird spielt dabei keine Rolle. Es gibt Wehre auch ohne Brücken, ein Wehr ist einfach eine Anstauung wo das Wasser über die Staustruktur fließt
Zurück zum eigentlichen Thema:
Das Brückenumrisse nicht mit Objekten auf anderen Ebenen verbunden werden sollten wurde schon richtig gestellt, aber dieser CS:
hat jetzt die kurzen Straßenstücke unter der Brücke mit den angrenzenden Straßenstücken zu einem Objekt vereinigt. Persönlich finde ich das nicht gut, da maxheight ja nur für den Teil unter der Brücke gilt. Zusätzlich setze ich bei den Stücken unter der Brücke auch noch covered=yes, da der Zusammenhang mit der Überdachung durch die Brücke sonst fehlt. Dies hat den schönen Effekt, dass es auf OSM-Carto auch besser dargestellt wird.
Mag sein, dass es bei Einbahnstraßen und maxheight=default nicht so relevant ist, aber maxheight wurde komplett entfernt und sobald es keine Einbahnstraße ist, wie z.B. Way: Forckenbeckstraße (28211730) | OpenStreetMap macht es ein Unterschied.
Wie gesagt, bei Einbahnstraßen nicht so relevant. Bei Verkehr in beide Richtung macht das aber schon einen Unterschied und einen Rückwärtsgang haben auch 40-Tonner.
