+1
Solche Geschichten findet man im ländlichen und kleinstädtischen Bereich zu Hauf… Das macht mich auch zu einem Freund des strengen Separatmappings von solchen straßenbegleitenden Wegen…
Ich gehe auch noch etwas weiter…
Für mich als Nutzer solcher Wege ist die Entscheidung Wege von einer zur anderen Straßenseite zu wechseln nicht die Stelle, an der ich meinen kürzesten Weg generiere, sondern die Stelle, die am komfortabelsten ist. Das sind in der Regel die üblichen Stellen an Kreuzungen und Einmündungen oder sonstige, als Überweg gebaute Stellen.
Gerade wenn z.B. ein Straße auf der einen Seite Parktaschen mit 1-2 Stellplätzen abwechselnd mit Baum/Strauchbestandenen Grünflächen hat, z.T. noch mit Eisen-Ziergeländern und auf der anderen Seite es nur eine Bordsteintrennung gibt, kann es keine allgemeine jederzeit geregelte Straßenquerung geben. Diese geregelte Straßenquerung ergibt sich an den baulich dafür vorgesehen, vor, hinter oder zwischen diesen gestalteten Bereichen. …ja und alles werden wir eh nicht abdecken können…
Für mich ist das zwagsweise Erfassen solcher Eigenschaften am highway und nicht als separaten Vektor weitestgehend Mapping für den Renderer, um ein sauberes Kartenbild zu bekommen, die eigene Arbeit zu minimieren und nicht um die Realität darzustellen. Für mich wird sowas der realen Situation vor Ort oft nicht gerecht.
In meinen vielen Jahren bei OSM gab es keine Disskussion zu diesem Thema, die mich der Notwendigkeit eines anderen Taggings überzeugt hat.
Das einzige Argument dagegen mit Gewicht ist, dass die Zugehörigkeit zur Straße nicht mehr eindeutig ist. Für Router-Ansagen wie “Rechts Abbiegen in die Bahnhofsstraße”.
Die textuelle / akkustische Fußgänger-Navigation auf getrennt gemappten Rad-/Gehwegen ist mitunter unbrauchbar (“in 10m rechts, nach 5m links, nach 10m links, nach 5m rechts” statt “Folgen Sie der Bahnhofstraße auf dem rechten Gehsteig”).
Ich habe noch keinen Renderer gesehen, der getrennt gemappte Rad-/Gehwege auch in großen Maßstäben an den Straßenrand zeichnen kann.
Das Routing erkennt normale Kreuzungsmöglichkeiten zwischendurch nicht, wodurch unnötige Umwege ausgegeben werden.
Sehr viele Getrenntmapper machen sich keine Gedanken um Routingfähigkeit und vergessen wesentliche Verbindungen zur Straße.
Eigenschaften der Straßenlinie lassen sich kaum mit den Eigenschaften der zugehörigen Gehweglinie in Verbindung setzen. Verkehrspolitisch interessante Auswertungen wie z. B. “Wieviel Prozent der Straßen mit ‘smoothness=good’ hat Gehwege mit ‘smoothness=bad’?” sind nicht möglich.
Es ist aufwändiger im Erfassen und verringert die Übersicht im Editor durch zusätzliche Kanten.
Vorteile:
Die Geometrie der Gehsteige lässt sich in hohen Zoomstufensehr gut darstellen.
Gehsteig-spezifische Eigenschaften sind sauberer getrennt. Dadurch müssen die Linien der Straßen seltener gespalten werden.
Genau das ist aber der Grund, auf der Brücke entweder den Radweg an die Linie der Brücke zu taggen, oder eben eine Verbindung zwischen Straße und seperat getrennten Weg herzustellen. Denn wenn ich von einem Feldweg auf der anderen Seite komme, der keine dieser komfortablen Verbindung zum Radweg hat, ist an der Brücke die erste Möglichkeit, auf dem Radweg zu kommen. Auf freien Feld kann die nächste Verbindung sehr weit entfernt sein.
Dass sowohl Zusammen- als auch Getrenntmapping handfeste Nachteile haben, wurde ja schon häufiger herausgearbeitet, das habe ich ja auf der Wikiseite zusammengefasst. Ob die Vor- und Nachteile irgendwen überzeugen, ist freilich eine subjektive Geschichte. Fakt ist, dass sehr viele Getrenntmapper sich nicht um die Routingtauglichkeit kümmern. Drum würde ich das persönlich nicht als Standard empfehlen.
“Mapping für Renderer” wird mitunter als Argument verwendet, wo es nicht taugt. Natürlich sollte unser Ziel sein, die Daten so zu erfassen, dass unsere Datenkonsumenten bestmöglich damit arbeiten können. Sonst könnten wir alle Eigenschaften als Freitext ins note-Tag schreiben.
Wir sollten nur eben nicht aufgrund der Unfähigkeit einzelner Datenkonsumenten ein falsches Tagging anwenden. Weder Getrennt-, noch Seperatmapping sind aber grundsätzlich falsch.
+1
Leute, es geht um Situationen wie hier und im weiteren Verlauf: https://mapillary.com/map/im/592421644995683
Deswegen geht die Diskussion an den realen Gegebenheiten vorbei.
Natürlich kann man hier zwischen den Begrenzungspfosten auf die Straße wechseln. Theoretisch. Macht aber keiner (1), deshalb wächst da auch von ganz allein Gras.
Natürlich gibt es im weiteren Verlauf im Bereich der Brücke Stellen, da gibt es zwischen Straße und Rad-/Gehweg teilweise nur Bordstein. Es gibt aber keinen Grund, auf die Straße zu wechseln, es sei denn man ist suizidal veranlagt. Der einzige Grund für den Bordstein ist Platzmangel für eine bauliche Trennung.
(1) Keine Regel ohne Ausnahme: wenn die Schranken geschlossen sind und die Brücke geöffnet, dann stehen alle Fahrzeuge und die Menschen laufen kreuz und quer um dem besten Platz zum fotografieren zu finden. Dafür braucht es aber weder ein passendes Rendering noch Routing.
Hier ging es also generell um kurze Brücken und nicht den Verlauf danach. Den Text könnte man interpretieren, dass es an kurzen Brücken generell keine Verbindung geben soll. Das möchte ich so nicht stehen lassen und habe ein Gegenbeispiel genannt. (Abgesehen davon, dass ich das “an die Fahrbahn klatschen” als eine unangenehm abwertende Bemerkung empfinde.)
Die Brücke in deinem Beispiel ist eher lang und hat in Teilen einen klassischen Bürgersteig als Radweg. Sowohl das als auch der optische Eidruck unterscheidet sie vom nachfolgendem Abschnitt. In diesen Teilen der Brücke würde ich tatsächlich vom Getrenntmapping auf das Zusammenmapping wechseln, denn es ändert sich auch draußen sehr viel.
Im Abschnitt nach der Brücke würde ich es getrennt mappen aber auch jede Verbindung zur Straße. Das auch dann, wenn es nur ein breiterer Trampelpfad ist.
Das Argument habe ich auch schon genannt. Ist für mich aber kein Grund es nicht (richtig) zu machen.
Ja:
Weitere Vorteile:
Der Straßen-way muss nicht unnötig geteilt werden, nur weil sich der Geh/Radweg ändert (Oberfläche, Beschilderung, Breite, etc.). Das macht das Straßen-Tagging mit ID (und somit dem Großteil der Mapper) uninteressant, da ID nicht fehlerfrei mit Relationen beim Teilen von ways umgehen kann.
Es ist nicht ersichtlich, ob man die Straße tatsächlich an jeder beliebigen Stelle kreuzen kann oder ob es Abschnitte gibt, wo dies nicht möglich ist.
Keine Redundanzen notwendig und somit weniger fehleranfällig: Straßen-Tagging benötigt Redundanzen, wenn es ich um Geh- und Radwege handelt. (surface, width, segregated etc. für sidewalk:… + cycleway:…). Hierbei kann es zu Inkonsistenzen kommen z.B.: unterschiedliche Oberflächenangaben bei gemeinsamen Geh- und Radwegen.
Übersichtlicher/einfacher: Straßen-Tagging kann zu sehr vielen Tags am Straßen-way führen (Geh und Radwege vollständig auf beiden Seiten zu erfassen macht echt keinen Spaß).
Unabhängig von der Richtung des Straßen-ways: Straßentagging bezieht sich auf die Richtung vom Straßenway (right/left). Wechselt die Richtung beim Übergang von einem Abschnitt zum nächsten, muss man aufpassen, dass man right/left auch wechselt. Bei nachträglichen Ändern der Richtung müssen die sidewalk/cycleway-Tags ebenfalls mit geändert werden.
Kleine Anmerkung zu einem Bordstein zwischen Straße und Radweg. Sofern es sich um einen nichtabgesenkten Bordstein handelt, ist das für Radfahrer eine Art bauliche Trennung, die man nicht so einfach überwinden kann. Ich möchte z.B. keine Routingansage haben, die mich über einen solchen 10 bis 20 cm hohen Bordstein - egal ob hinauf oder hinunter - schickt. In dieses Hinsicht finde ich am Getrenntmappen gut, dass es die Möglichkeit bietet, Radweg und Autofahrbahn genau an den Stellen miteinander zu verbinden, wo durch bauliche Gegenheiten (z.B. durch einen abgesenkten Bordstein) die Möglichkeit des Wechsels möglich ist.
Den Ersten hatte ich schon, der Zweite fehlte noch, danke.
Redundanz ist, wenn das Gleiche an zwei Stellen gespeichert wird. Hier geht es aber um zwei verschiedene Oberflächen, die man in den Daten entweder räumlich (an zwei Linien) oder per Namensraum trennt (an einer Linie). Da ist in Summe kein Unterschied.
Das Taggen von unterschiedliche Oberflächen bei Rad- und Gehwegoberflächen ist bei Getrenntmapping genauso, da auch dort i.d.R. beides als eine Linie erfasst wird. Auch bei der Fahrbahn haben mitunter Fahrspuren verschiedene Oberflächen. Dafür gibt es durchdachte Lösungen. Der Unterschied ist nur, ob man die Informationen an einer Stelle nachhält oder an mehreren verteilt.
Dafür gibt es weniger Linien im Editor, das macht es dort einfacher - Geschmackssache. Aber das Argument fehlte bislang auch noch.
Das Erfassen geht mit Vorlagen beim Zusammenmapping sogar schneller, man muss keine zusätzlichen Linien zeichnen und diese überall verbinden, wo man wechseln kann. Man muss nur einmal eine vorhandene Linie auswählen. Die Anzahl der Tags ist in Summe auch geringer. Dass die Namensräume die Keys länger machen, erhöht bei Anwendung von Vorlagen den Arbeitsaufwand nicht.
Ja stimmt. Das fällt aber sofort auf, zumindest wenn man die entsprechenden Kartenstile verwendet, die den Gehsteig- / Radweg darstellen.
Stimmt, macht JOSM allerdings automatisch. Insofern ist es zumindest in diesem Editor kein Problem. Ich nehms aber mit auf.
Wie gesagt, es gibt für beide Mappingmethoden Anwendungsfälle, wo sie ihre Vorteile ausspielen können. Ich halte hier nicht dagegen, weil ich Getrenntmapping grundsätzlich schlecht finde.
Es ist höchste Zeit, dass die Standardkarte straßenbegleitende Gehwege anzeigt, die als Eigenschaft der Straße erfasst sind. Derzeit ist es nämlich so, dass die meisten “separat Mapper” hauptsächlich für den Renderer (Luftbildäquivalenz), aber “attribut Mapper” ausschließlich für den Router (Navigationsgraph) mappen. Das ist eine Ungerechtigkeit - das Verhältnis “Hauptsächlich” zu “Ausschließlich” meine ich damit: Die “Attribut Mapper” sollen auch in den Genuss der grafischen Abbildung ihrer Herzenstätigkeit kommen, zumindest bei adäquatem Zoomlevel, nicht nur dann, wenn sie den JOSM Kartenstil aktiv haben, den es für iD nicht gibt. Die iD Entwickler würden sowieso am Liebsten Fahrspuren getrennt erfassen, dann wäre man die Probleme mit den Straßenbahnkreuzungen auch los (laut github issue tracker); Für den Spurwechsel sollen sich die Router etwas einfallen lassen.
Das einmal gesagt, wenn der Gehsteig (so sagt man hierzulande zu straßenbegleitenden Gehwegen) hinter einem Grünstreifen liegt, von der Fahrbahn aus gesehen, dann finde ich das auch nicht ganz falsch, würde es eventuell sogar selber so machen, je nachdem wie eigenständig ich den Gehweg erachte und wie viel Lust auf Klicks, das Geräusch, ich hab; Wenn jemand den getrennt erfasst, Du meine Güte - Aber bitte an das Routing denken dabei!
Ich trau mich wetten: Wenn der “footway=sidewalk” Schlüssel an einem Gehweg dazu führen würde, dass der in der Standardkarte nicht mehr aufscheint, dann hätten wir sehr viel weniger davon - von den Schlüsseln natürlich, nicht von den Gehwegen
Sehe ich auch so. Wir finden in Städten inzwischen sehr komplexe Straßen-Fußwegsituationen vor, die sich nicht alle adäquat durch Zusatzattribute am Fahrbahn-way wiedergeben lassen.
