Talk:Düsseldorf/Stammtisch

Themenvorschläge Oktober 2024

Bürgersteig-Erfassung

Seit vielen Jahren arbeite ich an gutem Fußgängerrouting, idealerweise auch mit Profilen für barrierefreies Routing.

Eines der Schlaglichter und auch Realitätstests ist der Kirchentag in Dortmund 2019 gewesen. Recht schnell haben wir dann am Stammtisch Dortmund abgeschätzt, dass wir uns auf die Innenstadt beschränken müssen, weil der Aufwand für Fußwegerfassung viel höher als erwartet ist. Als wirksame, aber nicht ausreichende Maßnahme haben wir die implizite Erfassung an allen Orten identifziert, an denen es keine Besonderheiten gibt.

Wie sich heraussstellt, sind wir auch davon weit davon entfernt, auch die implizite Erfassung flächendeckend auch nur an Hauptstraßen primary, secondary und tertiary zu haben. Zahlen für Nordrhein-Westfalen, für andere Städte bitte den Ortsnamen in Zeile 1 anpassen:

cnt	lg	label
73495	9403.0396250001	sidewalk
17309	1896.416562	right_left
4858	457.641746	both
8096	1272.359415	foot
104179	19234.545633	nothing
1932	245.68843	broken

Dabei ist für Straßen, die Bürgersteige explizit erfasst haben, die Tag-Familie sidewalk:right/left=separate eingeführt worden. Auf diese Weise lässt sich das Vorhandensein eines explizit gemappten Bürgersteigs nicht nur positiv erfassen, sondern auch angeben, inwiefern Fußgänger hier die Straße an jeder Stelle queren können.

Also habe ich mich für Wuppertal seit Februar drangegeben, die Tauglichkeit zu prüfen, indem ich das `sidewalk`-Tag flächendeckend erfasse. Wie bei einem Praxistest zu erwarten, hat das neue Schwierigkeiten aufgezeigt:

Würdet Ihr die folgenden drei Ways ...

... als Bürgersteig dieser Hauptverkehrsstraße ansehen?

Hintergrund dieser Frage ist das Tag sidewalk=separate. An diesen Orten hat ein ansonsten langjähriger und durchaus antwortender Mapper darauf bestanden, dass das alles drei Bürgersteige seien. Aus meiner Sicht sind das keine, und die Hauptstraße sollte ohne Bürgersteig getaggt werden.

Jetzt kann man natürlich einen Kampf um die Deutungshoheit starten. Oder einfach feststellen, dass das Tag anscheinend so unterschiedlich verwendet wird, dass es effektiv bedeutungslos wird. Die Information, dass irgendwo irgendein Weg im weitesten Sinne in die gleiche Richtung verläuft, ist ja im expliziten Weg samt Eigenschaften schon vermerkt.

Ich würde daher gerne das Tag weiterentwickeln, und möchte daher für die `sidewalk:right/left`-Familie die folgenden Werte neu verwenden:

Typ	als Tag	Way gesondert	Bemerkungen
Bordstein	sidewalk=including_kerb	sidewalk=kerb_separated
Bodenmarkierung	sidewalk=lane	sidewalk=paint_separated	lane ist bereits so in Verwendung.
Grünstreifen	sidewalk=including_verge	sidewalk=lawn_separated	Nur für leicht überquerbare Grünsteifen. Daher lawn.
Kreuzung	n/a	sidewalk=separate_crossing	Falls komplizierter als Zusammentreffen einfacher Straßen
Hindernis	n/a	sidewalk=barrier_separated	Alles, was zu übersteigen mindestens Mühe macht
unspezifisch	sidewalk=both	sidewalk=separate	Bestandswerte
nicht einsehbar	n/a	sidewalk=no	Zählt nicht mehr als Nebenweg

Die Werte gelten für eine beidseitig gleiche Situation. Falls beide Seiten verschieden sind, soll das Key-Paar sidewalk:right= und sidewalk:left=, dann aber stets zusammen und mit no für die andere Seite, falls dort nichts vorliegt.

Damit kann man dann sicher identifizieren, ob sich eine Straße queren lässt. Beim Routing für voll-mobile Fußgänger geht das für Kerb und Grünsteifen (wenn man Matsch und Regen ignoriert). Bei Kinderwagen und Rollator noch bei Kerb. Beim Rollstuhl nur bei Bodenmarkierung.

Für die Routing-Bewertung kann dann auch alles Separate jenseits vom Grünstreifen als sidewalk=no behandelt werden.

Als Systematik weist der Bestandteil _separated im Gegensatz zu including_ darauf hin, dass es einen getrennt erfassten Way gibt bzw. geben sollte. Beim Grünstreifen wird gewollt auf tatsächlich überquerbare Grünstreifen abgestellt, um Böschungen, Straßengräben, Beete und ähnliches sicher auszuschließen.

Die Kreuzung dient zur Klärung von Kreuzungen mit Rechtsabbiegerstreifen, Verkehrsinseln oder ähnlichem. Dort ist heute oft separate auch dann noch getaggt, wenn der tatsächlich Way erst hinter den Ways anderer Fahrbahnteile liegt. In so einer Situation ist ein implizit gemappter Bürgersteig schlicht falsch. In gleicher Weise ist es inhaltlich falsch, eine Way durch Tags abzubilden, wenn der physische Way nicht einmal mehr sichtbar ist.

Ich würde das erst einmal probeweise großflächig in Wuppertal erfassen und den Aufwand beobachten. Wenn sich das als tauglich erweist, würde ich es als Proposal breiter vorstellen.

Hat da einer von Euch Bedenken?

Ein kleiner Hinweis dazu: Das separation-Schema bietet bereits Values, die du verwenden könntest, um den Typ der physischen Trennung des Gehwegs zu spezifizieren (siehe insbesondere Values wie kerb/Bordstein, greenery/Grünstreifen, structure/Hindernis...). An einer separaten Gehweggeometrie würde beispielsweise separation=kerb bzw. separation:left=kerb wohl etwa deinem sidewalk=kerb_separated entsprechen. Selbst wenn man auf sidewalk-Tagging an der highway-Centerline setzen würde (was meiner Meinung nach ein totes Pferd ist, aber das müsst ihr lokal aushandeln :), könntest du das Schema in der Form sidewalk=both/sidewalk:both=yes + sidewalk:both:separation=kerb verwenden.
Beste Grüße aus dem weit entfernten Berlin! Supaplex030 (talk) 14:41, 29 October 2024 (UTC)