Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

Communities Deutschland (Germany)
21

Ok, dass geht fürs Fahrrad. Nicht optimal, trotzdem danke. Bei “zu Fuß” sieht das anders aus, dafür haben wir keine Beschränkungen.

Sowohl als auch. Zu Fuß, habe ich die Schnewlinstraße schon an fast allen Stellen gekreuzt, auch z.B. direkt auf der Brücke, wo es eine “Insel” gibt. Je nach Tageszeit, Verkehrslage und Ampelschaltung ist das möglich. Von einem Router für Fahrrad oder zu Fuß würde ich das aber nie erwarten.

Was das Fahrradrouten angeht wird hier glatt am Ende die Einbahnstraße in falsche Richtung benutzt. Ja ich weiß, es gibt besser Fahrradrouter, aber die grundlegendsten Regel sollte schon alle können.

Die Schnewlinstraße ist an der Stelle noch ein weiteres gutes Beispiel, da westlich davon der parallele Zufahrtsweg auch nur über einen Bordstein getrennt ist. Wenn ich mir die Situation jetzt nochmal anschaue, spricht an der Stelle wohl einiges eher für getrenntes Mappen. Und weiterhin bin ich der Meinung, wir brauchen die Barrieren inklusive Bordstein(-höhe) und Übergängen plus Verbindungen an allen Stellen, wo Bordsteine abgesenkt sind. Am schwierigsten finde ich die Kreuzungen an denen zum Kreuzen auf dem Trottoir der Bordstein (auf beiden Seiten) nicht abgesenkt ist, aber das ist hier OT.

22

…was passiert, wenn man sklavisch cycleway=track einsetzt, kann man sich z.B. hier anschauen: Steindamm in Senftenberg; https://bb-viewer.geobasis-bb.de/?projection=EPSG:25833&center=430908.13091058,5707771.191770395&zoom=13&bglayer=4&layers=25

Mapillary dazu: https://www.openstreetmap.org/#map=19/51.51641/14.00520

Im übrigen waren da mal die Wege separat: https://overpass-turbo.eu/s/1ehs

In meinen Augen ist hier nun die Wegeführung unlogisch und geht bei der Situation vor Ort an der Realität vorbei.

Sven

23

Die Diskussion wiederholt sich immer wieder. Wirklich Neues kommt kaum hinzu.

Ich hatte schonmal eine solche Gegenüberstellung von Vor- und Nachteilen aus bisherigen Diskussionen erstellt: wiki/User:JochenB/VorundNachteileGetrenntmapping

Die Tag-Seiten sollen vor allem Handlungsemopfehlungen geben. Ich finde eine Auflistung von Vor- und Nachteilen eines Taggingsschemas da nicht so passend. Besser sagen, wann welches Taggingschema seine Vorteile auspielen kann.

Wenn du alle Vor und Nachteile volständig darstellen willst, wird der Abschnitt überproportional groß. Vielleicht besser einfach sagen dass beide Taggingvarianten Vor- und Nachteile haben und meine Gegenüberstellung verlinken. Falls da noch etwas fehlt oder falsch ist, dannn nehmen wir es mit auf / ändern es.

Vielleicht auch das nur das Fazit der Gegenüberstellung übernehmen, wenn das Konsens ist. Das hänge ich unten nochmal dran. Ich finde es besser und neutraler, von beiden Vorgehensweisen die Vorteile zu nennen. Das geht auch eher in Richtung Handlungsempfehlung.

Den Satz "… es aber einige Verfechter gibt, die ein Tagging an der Straße bevorzugen. " empfinde ich als nicht neutral.

Je nach Vorlieben und je nach betrachteten Anwendungsfall wichtet man Vor- und Nachteile anders und kommt zu anderen Ergebnissen. Am wenigsten Konflikte gibt es, wenn immer dann getrennt gemappt wird, wenn der Weg nicht direkt neben der Fahrbahn verläuft. Eine stures Verfechten “immer getrennt” oder “immer zusammen” wird irgendwann zu Diskussionen führen, da war ich auch mal anders drauf. Hier sollte es also nicht um das “Verfechten” der einen oder anderen Variante gehen, sondern um eine für den konkreten Fall angemessene Lösung.

Was “indirektes Kartieren” ist, erschließt sich mir nicht auf Anhieb. Enweder man kartiert es direkt an der Straßenkante oder als seperate Linie.

Hier nochmal die Zusammenfassung aus der Gegenüberstellung als Vorschlag:

24

Inhaltlich zur fehlenden Verbindung zur Straße beim Getrenntmappung: Dafür gibt es bis heute keine brauchbare Lösung. Das ist der eine Grund, warum ich bei einfachen Verhältnissen weiter für ein Taggen an der Fahrbahn bin, vor allem bei Gehwegen.

Der andere Grund ist, dass es bis heute kein Renderer gibt, der es schafft, getrennt gemappte Geh- und Radwege immer an die Seite der Straße darzustellen. Scheinbar verlangen wir mit unserer Datenstruktur von den Maschinen etwas ab, das sie nicht leisten können. Wir sollten uns nicht für einzelne Renderer verbiegen (Tagging für die Renderer), aber wir sollten die Datenauswerter im Blick haben, wenn wir Entscheidungsspielräume haben.

Inhaltlich zum “Lastenradproblem”: Man könnte beim Taggen des Radwegs an der Fahrbahn problemlos auch die Bordsteinhöhe mittaggen und einen Standardwert festlegen, wenn die nicht getaggt ist (Bordstein=hoch). Insofern liegt der Nachteil nicht strukturell in dem Taggingschema des Zusammen-Mappings, sondern darin, dass das bisher keiner macht.

Einziges strukturelles Problem ist, wenn eine Absenkung am Knoten getaggt wird und diese nicht beidseitig ist. Angaben von “right” und ‘left’ am Knoten werden immer dann uneindeutig, wenn die abgehenden Kanten unterschiedliche Richtungen haben oder mehr als 2 Kanten abgehen. Hier müsste man die Höhe des Bordsteins an die Kante schreiben und die Kante ggf. splitten.

So kurze Kanten sind freilich nicht schön, weil unsere Editoren da keine komfortable Möglichkeit bieten, einen ganzen Straßenabschnitt mit allen zugehörigen Kanten auszuwählen, so dass auch kurze Kanten mit ausgewählt werden.

Alles hat so seine Vor- und Nachteile.

25

Gähn …
s.
https://wiki.openstreetmap.org/wiki/Proposed_features/Key:is_sidepath#Extension

26

Hä?!?
Das verstehe ich weder syntaktisch noch semantisch. Was willst du wie an welcher Seite darstellen?

27

Hilft leider nicht. Damit kann man nicht sagen, welche Gehwegkante zu welcher Straßenkante gehört, somit kann das auch kein Datenauswerter berücksichtigen. Üblicherweise ist mindestens eine von beiden Kanten irgendwo geteilt, oft nicht an der gleichen Stelle. Auch ist oft der Radweg nicht auf der gesamten Länge der Straße vorhanden.

Eine eindeutige Referenz zwischen zusammengehöriger Radweg- und Fahrbahnkante wäre theorethisch über Relationen möglich. Dann muss man aber Radweg und Straße immer an den gleichen Stellen schneiden und für die jeweiligen zusammengehörigen Abschnitte je eine Relation anlegen. Heidenaufwand und fehleranfällig.

Sorry, ich dachte das ist bekannt. Dieterdreist formulierte es im Wiki so:

Je nach Zoomstoofe und Karte sind die getrennt gemappten Geh- oder Radwege von der Straße verdeckt, sind sie mitten auf der Straße oder weit weg von der Straße obwohl sie in Wirklichkeit direkt daneben verlaufen. Ich bin vor langem zu OSM gekommen, weil ich für unsere Stadt und den hiesigen Fahrradverein einen Fahrradstadtplan in den Druck geben wollte. Haben wir bis heute nicht gemacht, genau deswegen.

Heute ist irgendwie nicht der Tag der wertschätzenden Kommunikation, oder habe ich irgendwas falsch gemacht?

28

Ich verstehe irgendwie nicht das Problem… Für was brauchst du denn diese Info einer genauen Kante-zu-Kante-Zuordnung. Mir würde adhoc keine vernünftige Datenauswertung, die nicht mit “gehört zu einem anderen Weg” (als Fußweg/Radweg) und der Zuordnung mittels Namen/Ref ausreichend arbeiten könnte. Vielleicht habe ich auch Scheuklappen auf?

Vielleicht setzt du dich mit den Machern der “Fahrradkarte” in Verbindung. Die haben das Meiner Meinung nach relativ gut gelöst…?

29

Warum reduzierst Du nicht einfach die Expansion der Straßenways beim Rendering,
und bei einem Fahrradstadtplan sollten die Radwege logischerweise immer über die Straßenways gerendert werden,
dann werden getrennt gemappten Geh- oder Radwege auch nicht von der Straße verdeckt.

30

Ist in Radweg oder Gehweg eine eigene Fahrbahn? Meines Erachtens nicht.

Die Grundregel sollten wir verlinken, wenn das stimmt. Allerdings bezog die sich die tatsächlich auf Geh- oder Radwege? Meines Wissens ging es dort immer um die Fahrbahnen der Straße. Sie auch auf die Seitenräume auszudehnen wäre dann eine Neuinterpretation. Demnach nicht wirklich ein gutes Argument für die Handlungsempfehlung.

Wir haben hunderte Keys, die keiner auswertet. Das liegt aber nicht an den keys, sondern weil es der Bedarf nicht hoch genug ist. Wichtig ist, dass man es auswerten kann, und das kann man in beiden Taggingvarianten.

Halte ich auch für eine persönliche Meinung. Im Editor gibt es ein Feld für Radweg, wo man eintragen kann, was die Straße für einen Radweg hat. Was ist daran schwer verständlich?

Dafür machen weniger erfahrene Mapper gerne den Fehler, die Geh- oder Radwege nicht mit der Straße zu verbinden, dort wo man Seiten wechseln kann. Das ist ein reell vorhandenes Problem. Hier geht der Punkt eher an das Zusammenmapping.

Fazit: Der Text sieht tatsächlich nicht im Ansatz nach Neutral Point Of View aus. Hier gibt es unterschiedliche Ansichten, jetzt wird eine gepusht. Um es neutral zu machen müssten die Argumente für die andere Variante dazu.

In die Wikiseite des Schlüssels sollten aber eher Handlungsempfehlungen oder ggf. ein Hinweis auf verschiedene Lesarten. Dazu dann eine gesonderte Seite, wenn nötig.

31

Z. B. für ein umwegfreies Routen. Das hatten wir mit zahlreichen Beispielen schon recht oft hier im Forum. Wenn ich nach links muss, schickt mich der Router beim Getrenntmapping nach rechts bis zur nächsten gemappten Kreuzungsmöglichkeit um dann auf die andere Seite zu kommen. Auf der anderen Seite geht es dann wieder zurück von wo ich komme und erst dann auf die sinvolle Route. Der Router weiß nicht, dass die Radweg-Kante gegenüber für mich direkt erreichbar ist.

Je nachdem, ob Grundstückseinfahrten zum Wechsel auf die Fahrbahn gemappt sind und wo diese liegen können da einige hundert Meter Umweg zusammenkommen. In echt würde ich einfach queren und nach links fahren, zumindest bei normal breiten Straßen. Das Problem ist hier noch größer als beim Fußgängerrouting, da Radwege meist Einbahnstraßen sind und so korrekterweise eine Querung 50m links von mir nicht in Betracht gezogen wird, auch wenn die nächste Querung rechts erst in 500m ist.

Aber auch für Datenauswertungen kann eine logische Verknüpfung zusammenhängender Objekte sinvoll sein. z. B. wenn ich verkehrspolitisch ausschlachten will, ob / dass die Ebenheit von Radwegen schlechter/besser ist als die der Straße nebenan.

Dort ist das genauso, die Linien der Radwege werden nicht an die Seite der Straßenlinie geschoben, wenn diese schmaler oder breiter dargestellt wird.

Das müsste man ja für jede Straße einzeln machen, da die Straßen ja unterschiedlich breit sind. Dann kann ich den Stadtplan gleich von Hand malen :slight_smile:

Man könnte die Straßenbreite maßstäblich darstellen, aber oft ist die Breite nicht gemappt.

Zudem ist es ja gewollt, dass die Straßen in Karten unmaßstäblich breit sind, das verbessert die Lesbarkeit sehr. Die Kartenverlage unserer Radkarten haben halt die Radwege an die Seite der Straßenlinie gezeichnet, so wie die Renderer das beim Zusammen-tagging auch machen.

Um das mit OSM zu machen bräuchten die Renderer für das Getrennt-Mapping einen Algorithmus, der erkennt, wenn Radwege / Gehwege überdeckt werden oder zu weit weg von der Straße sind. Dann sollten sie die Radwege wie beim Zusammen-tagging darstellen. Das habe ich aber noch nirgendwo gesehen und ich selber kann sowas nicht.

Das machen die Renderer ja so. Dann sind die Radwege aber mitten auf der Straße. Das hat damals im Verein keinen überzeugt. Die Ansprüche sind seit dem eher gestiegen.

32

Dann müsstest Du das aber ebenso für alle Fälle fordern, wo der Radweg gleich weit entfernt ist - aber eine ‘echte’ Trennung durch Grünstreifen, Leitplanke, Geländer etc. besteht …

Heißt:
Für das Problem der Verdrängung müssten die Radwegsinformationen immer am Straßen-highway ‘kleben’.

33

Genau deshalb verwende ich innerorts zu bicycle=use_sidepath (eventuell mit :backward/:forward) und foot=use_sidepath ja auch noch cycleway=separate und sidewalk=separate (eventuell mit :left/:right). :slight_smile:

34

Das Problem ist in diesem Fall nicht so groß. Die eine Häfte des Problems gibt es dort nicht (Es wird ein Abstand zu Straße dargestellt, den es draußen nicht gibt). Einen Abstand zur Straße gibt es ja wirklich.

Die Andere Häfte ist weniger problematisch (Radweg mitten auf der Straße). Abgesetzte Wege sind meist weiter weg sind von der Straßenmitte. Weil sind dann auch in der Darstellung weiter weg sind, treten Überlappungen mit den Straßenlinien erst viel später ein. Für den Ausdruck braucht es ja nur in eine bestimmten Zoomstufe, in der es funktionieren muss.

Das Projekt des ausgedruckten Stadtplans ist über 10 Jahre her, ich bin jetz in einer anderen Stadt, wir haben das damals verworfen. Unschön sind die Darstellungen aber weiterhin.

35

… richtig so,
wenn dies flächendeckend sauber umgesetzt wäre, dann wäre (für den der es will)
alternativ auch ein Rendern/Hervorheben (nur) am Straßenway möglich.
(lediglich Routen-Relatioen können nur einen Verlauf haben)

36

Das Gähn finde ich eher unpassend. Das Tag mag zwar wie eine Lösung aussehen, aber offensichtlich hat kaum ein Mapper verstanden, worum es geht. yes/no hilft nicht wirklich. https://taginfo.openstreetmap.org/keys/?key=is_sidepath#values

37

Nunja, aber den Zusammenhang zwischen den Informationen am seperat gemappten Radweg und der Fahrbahnkante kann man weiter nicht herstellen. Im Fahrradstadtplan sollten z.B. die smoothnes-Werte durch unterschiedliche Strichelung dargestellt werden. Klar kann man alles redundant mappen an Straße und Radweg, aber das führt zwangsläufig zu Inkonsistenzen, wenn einer nicht mitbekommt, dass er das an zwei Stellen pflegen muss. Wenn man irgendwie diesen Zusammenhang herstellen könnte und Renderer das dann auch umsetzen, dann wäre alles super!

Zum Textvorschlag von Dieterdreist: Ich hatte oben das Fazit meiner Gegenüberstellung als Alternative mit NPOV vorgeschlagen. Ist die OK? Man kann freilich auch noch an den einzelnen Formulierungen schrauben.

Ich würde das nebeneinander in zwei Spalten packen, dann wirkt es kompakter.

38

Du musst es doch sowieso “redundant” machen, weil der Radweg andere Eigenschaften haben kann, als die Fahrbahn? Wenn du eine Fahrbahn aus Asphalt hast und (leider) einen Radweg aus Betonverbundpflaster…?

Dann musst du halt alle Straßen komplett mit area:highway=* mappen…

Ich finde die von dieterdreist deutlich besser…

39

Radweg und Fahrbahn sind zwei verschiedene Dinge. Es geht hier aber nur um die Oberfläche des Radwegs. Die kann man an der Straßenkante taggen mit ‘cycleway:surface’ oder an der seperaten Kante mit ‘surface’ oder an beidem. Letzteres wäre redundnant.

Dann fehlt wieder die Verknüpfung zwischen Area und den Linienmodell oder man müsste alles redundant mappen.

Abgesehen davon: Wir sind von einem flächenhaften Erfassen der Städte mittels ‘area:highway=*’ noch sehr sehr weit entfernt. Auch gibt es meines Wissens kein Router, der auf einem Flächenmodell basiert. Das ist in absehbarer Zeit also eher ein Luftschloss denn eine Alternative. In meiner Gegenüberstellung der Vor- und Nachteile ist Flächentagging auch enthalten.

Warum? Ich hatte konkrete Kritikpunkte angebracht.

40

…richtig, eben deswegen hatte ich ausdrücklich auf die 2021 neu hinzugekommene Extension verlinkt.