You are not logged in.

#51 2021-12-29 13:36:18

JochenB
Member
Registered: 2012-01-24
Posts: 483

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

aighes wrote:
GerdP wrote:

Statt "Details von Querungen (Grundstückszufahrten) können nicht dargestellt werden." könnte man auch sagen "Details von Querungen (Grundstückszufahrten) müssen nicht dargestellt werden." wink

Hier in China, wo es sehr viele 4-6 spurige Straßen gibt mit einem sehr breiten separaten Radweg (meist baulich getrennt durch Grünstreifen, Geländer) ...

Wegen der Geländer und Grünstreifen würde ich das tendentiell eher getrennt mappen.

aighes wrote:

... ist es häufig der Fall, dass kleine Nebenstraßen/Dorfzufahrten nur zum Radweg führen. Du musst dich also rechtzeitig quasi richtig "einordnen" (auch mit KfZ) um in das Dorf zu gelangen.

Das verstehe ich nicht ganz. Vom Dorf kommt man (mit dem KfZ?) nur auf den Radweg, muss den Radweg lang fahren um dann an anderer Stelle auf die breite Straße zu gelangen?

Wo muss man sich einordnen, wenn man von der Straße auf den "Radweg" wechseln muss oder auf dem Radweg zur Straße?

Hast du ein Beispiel mit Luftbild oder Ähnlichem?

Offline

#52 2021-12-29 14:42:17

JochenB
Member
Registered: 2012-01-24
Posts: 483

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

Jo Cassel wrote:
aighes wrote:
GerdP wrote:

Ein (noch fehlender) Vorteil ist, dass ein Router viel leichter erkennen kann, dass der Radfahrer hier direkt neben einer Strasse unterwegs ist. Wenn diese eine hw=secondary oder "schlimmer" ist, dann ist das für mich ein guter Grund, den Radweg zu meiden.
Leider haben wir kein Tag, dass bei einem getrennt gemappten Weg diesen Umstand darstellt. Berechnen lässt sich das auch nicht mal eben so, zumindest kenn ich keine gute Methode.

Das ist leider auch das große Problem beim getrennt mappen. Ebenso die dann nicht sinnvolle Routenanweisung ala: "Fahre auf Radweg" anstatt "Fahre auf Radweg entlang der A-Straße".
[...].

Auch für Dich nochmals der Hinweis auf die 2021 hinzugefügte Extension
https://wiki.openstreetmap.org/wiki/Pro … #Extension
die sich genau mit diesen Problematiken beschäftigt.

Man müsste halt einfach mal anfangen mit diesem Konzept die Probleme gemeinsam anzugehen, statt sie weiterhin nur zu beklagen...

Theorethisch gibt es drei Möglichkeiten:

  1. Getrennt-Mappen, zugehörige Linien der Fahrbahn und der benachbarten Radwege über Relationen ein-eindeutig verknüpfen (Abbildung von Querungsmöglichkeiten + gegenseitige Verlinkung der Attribute)

  2. Zusammen-Mappen Fahrbahn und Radwege an einer Linie

  3. Getrennt-Mappen, Attribute redundant an beiden Linien schreiben, kontinuierliche Querungsmöglichkeit über Hilfslösungen.

Für mich in dieser Reihenfolge. Nr 1 wäre für viele Fälle ideal.

Nur gibt es Nr 1 praktisch nicht. Es fehlt die handhabbare Möglichlichkeit der ein-eindeutigen Verknüpfung von Radweglinie mit zugehöriger, benachbarten Straßenlinie. Wenn hier von Getrennt-Mapping gesprochen wird ist es immer Varante 3. Das Umweg-Problem ist ein systematischer Fehler der Variante 3.

Der Vorschlag 'is_sidepath:of=tertiary' ist im Prinzip Nr 3, denn das ist Redundanz zum Tag an der Straßenlinie. Bei Nr. 3 stehen die Attribute der Straße auch am Radweg zur Verfügung. Problem ist einerseits die Redundanz, denn da kommt es schnell zu Widersprüchen aufgrund nichtvollständigen Pflegens.

Nr. 3 ist für mich die beste Wahl wenn Nr. 2 aufgrund ihrer Nachteile nicht passt oder wenn es keine kontinuierliche Querungsmöglichkeit gibt.

Offline

#53 2021-12-29 16:01:06

Jo Cassel
Member
Registered: 2015-12-02
Posts: 1,361

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

JochenB wrote:

[...]
Der Vorschlag 'is_sidepath:of=tertiary' ist im Prinzip Nr 3, denn das ist Redundanz zum Tag an der Straßenlinie. Bei Nr. 3 stehen die Attribute der Straße auch am Radweg zur Verfügung. Problem ist einerseits die Redundanz, denn da kommt es schnell zu Widersprüchen aufgrund nichtvollständigen Pflegens.
[...]

Ja, unwidersprochen, eine gewisse Redundanz ist dem Design nunmal immanent.
Ganz grundsätzlich halte ich die Formulierung von pro-contra-Listen für Zeitvergeudung (noch dazu an einem von mehreren betroffenen Tags/Keys),
langfristig sinnvoller ist es imho den Mappern ein vernünftig ausgearbeitetes How-to anzubieten wie es hier versucht wird
https://wiki.openstreetmap.org/wiki/Ber … de/Gehwege

Offline

#54 2021-12-29 18:43:59

JochenB
Member
Registered: 2012-01-24
Posts: 483

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

edit: zu früh gespeichert, kommt gleich

Last edited by JochenB (2021-12-29 18:51:37)

Offline

#55 2021-12-29 19:32:24

JochenB
Member
Registered: 2012-01-24
Posts: 483

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

Jo Cassel wrote:
JochenB wrote:

[...]
Der Vorschlag 'is_sidepath:of=tertiary' ist im Prinzip Nr 3, denn das ist Redundanz zum Tag an der Straßenlinie. Bei Nr. 3 stehen die Attribute der Straße auch am Radweg zur Verfügung. Problem ist einerseits die Redundanz, denn da kommt es schnell zu Widersprüchen aufgrund nichtvollständigen Pflegens.
[...]

Ja, unwidersprochen, eine gewisse Redundanz ist dem Design nunmal immanent.

Ich denke damit kann man leben, schlimmer ist das Umweg-Problem. Das besteht aber nur bei Radwegen & Gehsteigen, die direkt an der Fahrbahn liegen. Daher ist dort halt das Zusammen-Taggen oft die bessere Lösung, bei gefühlt 90% der Geh- und Radwege treten die Nachteile des Zusammen-Taggens nicht auf.

Jo Cassel wrote:

Ganz grundsätzlich halte ich die Formulierung von pro-contra-Listen für Zeitvergeudung (noch dazu an einem von mehreren betroffenen Tags/Keys),

+1

Jo Cassel wrote:

langfristig sinnvoller ist es imho den Mappern ein vernünftig ausgearbeitetes How-to anzubieten wie es hier versucht wird
https://wiki.openstreetmap.org/wiki/Ber … de/Gehwege

Sehr gut gemacht! Allerdings wird ausschließlich Methode 3 beschrieben (Getrennt-Mapping), der Rest fehlt. Wenn es dafür auch eine Anleitung gibt, dann wäre es m. E. OK.

Bevor wir ausschließlich das Getrennt-Mapping empfehlen sollten Lösungen für die Probleme dieser Methode gefunden werden. Gut, dass sie sich dem Umweg-Problem annehmen, die Lösung ist das m. E. aber noch nicht. Sie schlagen vor:

Grundsätzlich sollten überall dort querende Verbindungen in OSM geschaffen werden, wo es bauliche Hinweise auf Querungsmöglichkeiten gibt.

Und weiter oben

Füge weitere baulich vorhandene oder logische Verbindungen und Anschlussmöglichkeiten zwischen Straße und straßenbegleitenden Wegen ein – z.B. an sonstigen Querungsmöglichkeiten wie Gehwegvorstreckungen ... oder im Bereich gegenüberliegender Einmündungen/T-Kreuzungen

Die meisten Stadtstraßen sind Nebenstraßen und dort kann man nahezu überall problemlos queren, ganz ohne "bauliche Hinweise"

Daher wäre es wirklich gut, eine logische Verknüpfung zwischen Gehsteig/Radweg und Straße herzustellen. Dafür gibt es meines Wissens noch keine praktikable Lösung. Wir können doch nicht vor jeder Haustür eine Verbindung zwischen Geh-/Radweg mappen. Einerseits sehr aufwendig, andererseits würde da etwas gemappt, dass es draußen so nicht gibt. Vielleicht ist aber genau das der Kompromiss. Ich weiß nicht.

Was mir noch auffällt: an Kreuzung wie der folgenden wird jeder Fußgänger-Router "Bitte links abbiegen" sagen, obwohl man der Straße geradeaus folgt
375px-Junction_residential_unmarked_cycleway.png
(Quelle)

Wie kann man den Routern beibringen, da zu sagen "Bitte geradeaus der Straße folgen"?

Zudem aus meiner Sicht fragwürdig: Hier wird empfohlen, Gehwege und Radwege als voneionander getrennte Linien darzustellen, selbst wenn es - wie in Berlin üblich - keine bauliche Trennung dazwischen gibt. Warum im Seitenbereich eigene Linien, auf der Fahrbahn aber alle Spuren in einer Linie? Das empfinde ich als inkonsequent und verstehe auch nicht warum.

edit: war zu früh gespeichert

Offline

#56 2021-12-30 06:01:04

aighes
Member
From: Shanghai
Registered: 2009-03-29
Posts: 5,346
Website

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

JochenB wrote:
aighes wrote:

... ist es häufig der Fall, dass kleine Nebenstraßen/Dorfzufahrten nur zum Radweg führen. Du musst dich also rechtzeitig quasi richtig "einordnen" (auch mit KfZ) um in das Dorf zu gelangen.

Das verstehe ich nicht ganz. Vom Dorf kommt man (mit dem KfZ?) nur auf den Radweg, muss den Radweg lang fahren um dann an anderer Stelle auf die breite Straße zu gelangen?

Wo muss man sich einordnen, wenn man von der Straße auf den "Radweg" wechseln muss oder auf dem Radweg zur Straße?

Hast du ein Beispiel mit Luftbild oder Ähnlichem?

Bspw.: https://www.google.com/maps/@31.2482522 … a=!3m1!1e3

Wenn du zu dem "Hof" willst, musst du ein paar Meter vorher von der Straße auf den "Radweg" wechseln und kannst dann in den "Hof" einfahren.

Oder hier: https://www.google.com/maps/@31.2661106 … a=!3m1!1e3

Ich setze Radweg mal in "" weil man sich evtl. doch von der Vorstellung eines deutschen Radwegs lösen muss. Radweg ist hier idR.  2-3m breit, sodass er auch ohne Probleme von einem Auto befahren werden kann.


Viele Grüße
Henning, developer of RadReiseKarte

Offline

#57 2021-12-30 06:20:25

aighes
Member
From: Shanghai
Registered: 2009-03-29
Posts: 5,346
Website

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

JochenB wrote:

Was mir noch auffällt: an Kreuzung wie der folgenden wird jeder Fußgänger-Router "Bitte links abbiegen" sagen, obwohl man der Straße geradeaus folgt
https://wiki.openstreetmap.org/w/images … cleway.png
(Quelle)

Wie kann man den Routern beibringen, da zu sagen "Bitte geradeaus der Straße folgen"?

Zudem aus meiner Sicht fragwürdig: Hier wird empfohlen, Gehwege und Radwege als voneionander getrennte Linien darzustellen, selbst wenn es - wie in Berlin üblich - keine bauliche Trennung dazwischen gibt. Warum im Seitenbereich eigene Linien, auf der Fahrbahn aber alle Spuren in einer Linie? Das empfinde ich als inkonsequent und verstehe auch nicht warum.

Dieses Beispiel sehe ich ganz klar die Variante Radweg und Gehweg sind einfach nur eine weitere Spur der Straße und das halte ich dann auch am sinnvollsten und einfachsten zu warten. Wie bereits gesagt, es braucht nur eine Unterstützung im Editor, dass es jeder sich zusammen klicken kann. Da gibt es ja schon was in jOSM, nur scheinbar nur für Abbiegespuren.

Auch eine bauliche Trennung könnte man im Spuren-Schema darstellen, scheint aber noch nicht zu existieren. Aber bspw. statt | könnte man \ oder / nehmen. Nur so als Idee. Das Problem ist aber, dass Radweg und Fußweg ein anderes Schema haben und aktuell nicht als Spur angesehen werden. Das macht es schwer Relationen der Spuren dar zu stellen.

Bsp. zu deinem Bild:
horizontal

lanes:type:forward=highway\cycleway|footway
lanes:type:backward=highway\cycleway|footway

vertikal

lanes:type:forward=highway\footway
lanes:type:backward=highway\footway

Anhand der Daten können Router/Renderer dann ihr Datenmodel aufbauen.

Getrennt mappen wäre aus meiner Sicht nur sinnvoll, wenn es fürs Routing wichtig ist, siehe mein Beitrag zuvor. Da fällt mir nix ein, wie man es per Taggs darstellen könnte.

Edit: Beispiel ergänzt

Last edited by aighes (2021-12-30 06:32:28)


Viele Grüße
Henning, developer of RadReiseKarte

Offline

#58 2021-12-30 13:32:29

Hungerburg
Member
Registered: 2020-12-11
Posts: 418

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

OT: Auf den Luftbildern aus China seh ich zu erst einmal, dass das Kartenoverlay bis zu 400m versetzt liegt! Sind die Bilder so sehr falsch oder die google-maps?

½OT: Dass so ein "Radweg" separat eingetragen wird, das dürfte vermutlich bei niemandem auf Widerstand treffen, auch bei hardcore - sogenannten - Verfechtern nicht. Fälle wie diesen gibt es nicht nur in China. In Österreich könnte es sich aus rechtlicher Sicht um eine "Nebenfahrbahn" der Hauptfahrbahn (in der StVO § 2 definiert) handeln oder um einen "Begleitweg" (rechtlich nicht definiert, aber gerne für eigenständige Straßen verwendet, die "zufällig" parallel zu einer anderen, größeren Straße verlaufen). Der Unterschied liegt darin, dass eine Nebenfahrbahn mit dem Auto nur zum Erreichen von Zielen durchfahren werden darf, die anders nicht erreichbar sind.

Offline

#59 2021-12-30 13:55:04

Hungerburg
Member
Registered: 2020-12-11
Posts: 418

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

Zurück zum Anlass, zur Veranschaulichung, das Bild aus der Dokumentation: Die Situation ist auch vor Ort nicht ganz ohne Probleme: Das blaue Schild steht höchstwahrscheinlich im Widerspruch mit anwendbaren Richtlinien. Der Gehweg, ich nehm an, das ist die hell gepflasterte Fläche, ist zu schmal um als eigenständig gelten zu dürfen. Da wäre das Schild mit Rad und Frau mit Kind übereinander sicher eher angebracht. So eins steht wahrscheinlich eh auf der anderen Straßenseite, die zum Großteil rot gepflastert ist, und auch das Wegstück vor dem Schild trägt wohl so eines, man sieht da nur den Gehweg schwinden. Richtig tragisch ist das aber nicht, das Schild steht sowieso nur da, um das Radfahren am Gehweg zu erlauben und in einem Aufwaschen die Räder von der Fahrbahn weg zu bringen.

Z241GetrennterRadUndGehweg.png

Man kann hier zwischen ein und sechs Wege kartieren:
1 Weg : 1 mit 6 Spuren (Fahrbahn, Rad- und Gehweg links und rechts)
3 Wege: 1 mit 2 Spuren (Fahrbahn) + 2 (je ein kombinierter Geh/Radweg links/rechts)
5 Wege: 1 mit 2 Spuren (Fahrbahn) + 4 (je ein Radweg + je ein Gehweg links/rechts)
6 Wege: 2 Fahrbahnspuren + 4 …

Der letzte Fall, sogenanntes Spurmapping, steht in schlechtem Ruf, hat aber auch Befürworter. Nicht irgendwer, sondern der vorletzte iD Maintainer hat gemeint, dass nur so die exakte Topologie in allen Fällen korrekt abgebildet werden kann, anhand eines Falls, wo es darum ging, ob Rechts- oder Linksabbieger Straßenbahnschienen überfahren müssen, im Verständnis des iD-Validators also eine Kreuzung queren.

Die Präferenz meiner Wenigkeit liegt beim Fall wie im Bild klar bei Variante 1. Den Sachverhalt seh ich hinreichend erklärt. Auf die Möglichkeit, den Kanaldeckel auf einem getrennt erfassten Weg korrekt als darauf liegend abzubilden kann die Welt meiner Auffassung nach locker verzichten. Von daher hat Jochens Änderung an der Dokumentation mein Plazet: Es braucht nicht für jedes Detail einen eigenen Punkt, es genügt zu erwähnen, dass mehr Details gemappt werden können. Wem die Editor Darstellung zu abstrakt ist, der kann die Stilvorlage "Fahrspur und Straßenattribute" in JOSM einblenden. Für iD gibt es dergleichen leider nicht. Der neue Maintainer hat erwähnt, das Bearbeiten von lanes zu verbessern, man wird sehen.

Die Berliner Verkehrswende scheint mir Variante 5 zu favorisieren, verfechten wär mir fast herausgerutscht. Wenn ich mich recht erinnere werden da auch noch zwischen Fahrbahn und Radweg je Linien mit abwechselnd kerb=flush|lowered|raised fällig, um zu kennzeichnen, wo man barrierefrei auf die Fahrbahn wechseln kann. Das wäre dann Variante 7.

Ich gebe zu Bedenken, dass das für manche in OSM-Carto nett anzusehen sein mag und dass Router so zwar exakte Geometrien haben, aber damit in vielen Fällen nichts sinnvolles anfangen können, ja dass das sogar kontraproduktiv zu vernünftigem Routing wird, solange nicht eine Fläche gemappt wird, die eindeutig klar macht, dass es sich bei den einzelnen Wegen um nicht viel mehr als Spuren einer Straße handelt. Relationen reichen da übrigens nicht, die helfen nur turn-by-turn Anweisungen netter zu gestalten, es müssen schon Flächen sein. (Laut opencyclemap Entwickler)

Getrennt-Mapping ohne Flächen ist nur die halbe Miete. Kann das als Nachteil in die Gegenüberstellung aufgenommen werden?

Was dann noch fehlt ist die Möglichkeit, abzubilden dass Autos halb auf Gehweg und Fahrbahn parken beziehungsweise halten. Ob der Wagen im Bild dort unerlaubterweise steht oder nicht, das spielt in openstreetmap wohl keine Rolle, denn ground-truth und Vorschrift müssen sich nicht decken. Oder ist das Haarspalterei?

Offline

#60 2021-12-30 14:29:58

aighes
Member
From: Shanghai
Registered: 2009-03-29
Posts: 5,346
Website

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

Hungerburg wrote:

Ich gebe zu Bedenken, dass das für manche in OSM-Carto nett anzusehen sein mag und dass Router so zwar exakte Geometrien haben, aber damit in vielen Fällen nichts sinnvolles anfangen können, ja dass das sogar kontraproduktiv zu vernünftigem Routing wird, ...[..]

Das Problem ligt aber vorallem beim Renderer, der aus den Spurinformationen nichts sinnvolles ableitet fürs Kartenbild. Bei

lanes:type:forward=highway\cycleway|footway
lanes:type:backward=highway\cycleway|footway

Könnte er ja eine blau-rote parallele Linie links und rechts zum highway zeichnen. Tut aber kaum einer und dann führt es dazu, dass alles separat eingetragen wird, weil sonst das Fußgänger-Routing Mist aussieht im Vergleich zu Google & co.


Viele Grüße
Henning, developer of RadReiseKarte

Offline

#61 2021-12-30 20:05:19

skyper
Member
Registered: 2020-06-08
Posts: 592

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

aighes wrote:
JochenB wrote:

Was mir noch auffällt: an Kreuzung wie der folgenden wird jeder Fußgänger-Router "Bitte links abbiegen" sagen, obwohl man der Straße geradeaus folgt
https://wiki.openstreetmap.org/w/images … cleway.png
(Quelle)

Wie kann man den Routern beibringen, da zu sagen "Bitte geradeaus der Straße folgen"?

Zudem aus meiner Sicht fragwürdig: Hier wird empfohlen, Gehwege und Radwege als voneionander getrennte Linien darzustellen, selbst wenn es - wie in Berlin üblich - keine bauliche Trennung dazwischen gibt. Warum im Seitenbereich eigene Linien, auf der Fahrbahn aber alle Spuren in einer Linie? Das empfinde ich als inkonsequent und verstehe auch nicht warum.

Dieses Beispiel sehe ich ganz klar die Variante Radweg und Gehweg sind einfach nur eine weitere Spur der Straße und das halte ich dann auch am sinnvollsten und einfachsten zu warten.

Ich nehme mal an, die gelben Knoten haben noch ein `kerb=*`.

aighes wrote:

Wie bereits gesagt, es braucht nur eine Unterstützung im Editor, dass es jeder sich zusammen klicken kann. Da gibt es ja schon was in jOSM, nur scheinbar nur für Abbiegespuren.

Was meinst Du? In JOSM gibt unabhängige Vorlagen, Erweiterungen und Kartenstile.

aighes wrote:

Auch eine bauliche Trennung könnte man im Spuren-Schema darstellen, scheint aber noch nicht zu existieren. Aber bspw. statt | könnte man \ oder / nehmen. Nur so als Idee. Das Problem ist aber, dass Radweg und Fußweg ein anderes Schema haben und aktuell nicht als Spur angesehen werden. Das macht es schwer Relationen der Spuren dar zu stellen.

Bsp. zu deinem Bild:
horizontal

lanes:type:forward=highway\cycleway|footway
lanes:type:backward=highway\cycleway|footway

vertikal

lanes:type:forward=highway\footway
lanes:type:backward=highway\footway

Anhand der Daten können Router/Renderer dann ihr Datenmodel aufbauen.

Getrennt mappen wäre aus meiner Sicht nur sinnvoll, wenn es fürs Routing wichtig ist, siehe mein Beitrag zuvor. Da fällt mir nix ein, wie man es per Tags darstellen könnte.

Das große Problem sehe ich ja in den vielen Tags. Allein Spurtagging für Fahrbahnflächen + Radstreifen ist nicht ohne und jetzt das ganze auch noch für die Barrieren und Seitenflächen wie Parkplätze und Rad- + Fußwege.
Auch ist es eher möglich etwas zusammenzubauen als etwas auseinander zu klamüsern. Aber ich gebe Dir Recht und habe es auch schon selber geschrieben, dass getrenntes Mappen eigentlich nur mit `area:highway=*`-Flachen und `landuse=highway` plus möglichst allen Barrieren bis zum Bordstein wirklich gut funktioniert. Allerdings funktioniert es zusammen an einer Linie eben auch nicht wirklich.

Offline

#62 2021-12-31 00:04:18

skyper
Member
Registered: 2020-06-08
Posts: 592

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

Hungerburg wrote:

Zurück zum Anlass, zur Veranschaulichung, das Bild aus der Dokumentation: Die Situation ist auch vor Ort nicht ganz ohne Probleme: Das blaue Schild steht höchstwahrscheinlich im Widerspruch mit anwendbaren Richtlinien. Der Gehweg, ich nehm an, das ist die hell gepflasterte Fläche, ist zu schmal um als eigenständig gelten zu dürfen. Da wäre das Schild mit Rad und Frau mit Kind übereinander sicher eher angebracht. So eins steht wahrscheinlich eh auf der anderen Straßenseite, die zum Großteil rot gepflastert ist, und auch das Wegstück vor dem Schild trägt wohl so eines, man sieht da nur den Gehweg schwinden. Richtig tragisch ist das aber nicht, das Schild steht sowieso nur da, um das Radfahren am Gehweg zu erlauben und in einem Aufwaschen die Räder von der Fahrbahn weg zu bringen.

Super, damit fördert die Verwaltung nur aggressives Verhalten gegenüber Radfahrenden, die hier legalerweise die Straße benutzen.

Hungerburg wrote:

https://wiki.openstreetmap.org/w/images … Gehweg.png

Man kann hier zwischen ein und sechs Wege kartieren:
1 Weg : 1 mit 6 Spuren (Fahrbahn, Rad- und Gehweg links und rechts)
3 Wege: 1 mit 2 Spuren (Fahrbahn) + 2 (je ein kombinierter Geh/Radweg links/rechts)
5 Wege: 1 mit 2 Spuren (Fahrbahn) + 4 (je ein Radweg + je ein Gehweg links/rechts)
6 Wege: 2 Fahrbahnspuren + 4 …

Der letzte Fall, sogenanntes Spurmapping, steht in schlechtem Ruf, hat aber auch Befürworter. Nicht irgendwer, sondern der vorletzte iD Maintainer hat gemeint, dass nur so die exakte Topologie in allen Fällen korrekt abgebildet werden kann, anhand eines Falls, wo es darum ging, ob Rechts- oder Linksabbieger Straßenbahnschienen überfahren müssen, im Verständnis des iD-Validators also eine Kreuzung queren.

"Spurmapping" halte ich für missverständlich, das könnte auch `*:lanes[:*]=*` sein. Hier geht es ja um individuelles Fahrspurmapping. Das ist so weit ich mich erinnere schon vor zehn Jahren abgelehnt worden. Ein großes Problem dabei sind Spurwechsel. Finde heute noch verstreut Abfahrten, welche am Beginn der Abbiegespur abzweigen und als separate Linie eingetragen ist. sad

Hungerburg wrote:

Die Präferenz meiner Wenigkeit liegt beim Fall wie im Bild klar bei Variante 1. Den Sachverhalt seh ich hinreichend erklärt. Auf die Möglichkeit, den Kanaldeckel auf einem getrennt erfassten Weg korrekt als darauf liegend abzubilden kann die Welt meiner Auffassung nach locker verzichten. Von daher hat Jochens Änderung an der Dokumentation mein Plazet: Es braucht nicht für jedes Detail einen eigenen Punkt, es genügt zu erwähnen, dass mehr Details gemappt werden können. Wem die Editor Darstellung zu abstrakt ist, der kann die Stilvorlage "Fahrspur und Straßenattribute" in JOSM einblenden. Für iD gibt es dergleichen leider nicht. Der neue Maintainer hat erwähnt, das Bearbeiten von lanes zu verbessern, man wird sehen.

Mmh, weshalb die vielen abgesenkten Bordsteine, sind das alles Zufahrten?
Selbst als eine Person, die gewöhnt daran ist mit dem Fahrrad aus Straßenbahnschienen und über Bächle zu springen, ist ein Bordstein und ein Bächle erst Mal eine Barriere. Ich würde mir wünschen, wenn mein Fahrradrouter mich spätestens 50m vorm Linksabbiegen auf die Straße lotst oder im Profil ohne Anhänger und Gepäck mir wenigstens mitteilt, dass ich springen sollte.
Von Personen mit Einschränkungen und Mobilen die schon bei ein paar Zentimeter Höhenunterschied Probleme bekommen reden wir hier ja gar nicht.

Hungerburg wrote:

Die Berliner Verkehrswende scheint mir Variante 5 zu favorisieren, verfechten wär mir fast herausgerutscht. Wenn ich mich recht erinnere werden da auch noch zwischen Fahrbahn und Radweg je Linien mit abwechselnd kerb=flush|lowered|raised fällig, um zu kennzeichnen, wo man barrierefrei auf die Fahrbahn wechseln kann. Das wäre dann Variante 7.

Von 5 halte ich nichts, solange da keine bauliche Trennung existiert. Eine Laterne oder ein Verkehrszeichen kann auch mittig im Weg platziert werden.
Gegen die Barrieren als eigene Objekte spricht nichts. Ich bin da dann bei Variante 3+2 (1 mit 2 Spuren (Fahrbahn) + 2 (je ein kombinierter Geh/Radweg links/rechts) + 2 (Barrier/Bordstein)

Hungerburg wrote:

Ich gebe zu Bedenken, dass das für manche in OSM-Carto nett anzusehen sein mag und dass Router so zwar exakte Geometrien haben, aber damit in vielen Fällen nichts sinnvolles anfangen können, ja dass das sogar kontraproduktiv zu vernünftigem Routing wird, solange nicht eine Fläche gemappt wird, die eindeutig klar macht, dass es sich bei den einzelnen Wegen um nicht viel mehr als Spuren einer Straße handelt. Relationen reichen da übrigens nicht, die helfen nur turn-by-turn Anweisungen netter zu gestalten, es müssen schon Flächen sein. (Laut opencyclemap Entwickler)

Getrennt-Mapping ohne Flächen ist nur die halbe Miete. Kann das als Nachteil in die Gegenüberstellung aufgenommen werden?

Wie ich oben geschrieben habe ist das korrekte Routing sehr situations- und in diesem Detail auch sehr von den eigenen Vorstellungen und Voraussetzungen abhängig. Ja, die Barrieren wären wichtig und die Flächen schön, ab gibt es denn einen Router der `is_sidepath` plus Untertags verwendet und mit `use_sidepath` sauber umgeht? Der könnte ja auch die ersten und letzten Paar Meter Luftlinie berechnen, wie es bei fehlenden Verbindungen z.B. zur Haustüre auch gemacht wird. Ob ich mich dann entscheide über Grünstreifen und Bordsteine zu springen oder mir selbst den geeigneten Übergang suche bleibt mir ja immer selbst überlassen. Andere wollen aber eben den Übergang mit genügend Breite und auf beiden Seiten zumindest abgesenkter Bordstein.

Hungerburg wrote:

Was dann noch fehlt ist die Möglichkeit, abzubilden dass Autos halb auf Gehweg und Fahrbahn parken beziehungsweise halten. Ob der Wagen im Bild dort unerlaubterweise steht oder nicht, das spielt in openstreetmap wohl keine Rolle, denn ground-truth und Vorschrift müssen sich nicht decken. Oder ist das Haarspalterei?

Das ist doch schon in `parking:lane` enthalten. Oder geht es Dir um ein eigenes Objekt für die Parkfläche?

Offline

#63 2022-01-01 06:50:45

aighes
Member
From: Shanghai
Registered: 2009-03-29
Posts: 5,346
Website

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

skyper wrote:

Ich nehme mal an, die gelben Knoten haben noch ein `kerb=*`.

Ja, an sich schon. Man könnte aber auch per Abbiege-Relation ausdrücken, dass bpsw. ein Fußgänger oder ein wheelchair nicht gerade aus gehen/rollen kann an der Kreuzung.

skyper wrote:
aighes wrote:

Wie bereits gesagt, es braucht nur eine Unterstützung im Editor, dass es jeder sich zusammen klicken kann. Da gibt es ja schon was in jOSM, nur scheinbar nur für Abbiegespuren.

Was meinst Du? In JOSM gibt unabhängige Vorlagen, Erweiterungen und Kartenstile.

Ich meinte das grafische Turn-Lanes-Tagging Tool. Wo man ohne Kenntnisse des Schemas sich zusammen klickt, wie es vor Ort ist. Die müsste dann ein wenig erweitert werden wink


skyper wrote:

Das große Problem sehe ich ja in den vielen Tags. Allein Spurtagging für Fahrbahnflächen + Radstreifen ist nicht ohne und jetzt das ganze auch noch für die Barrieren und Seitenflächen wie Parkplätze und Rad- + Fußwege.
Auch ist es eher möglich etwas zusammenzubauen als etwas auseinander zu klamüsern.

Ich kann mir gut vorstellen, dass das komplexer ist als aktuell, keine Frage. Aber es ist eine lösbare Sache, die auf der einen Seite gutes Routing und auf der anderen Seite eine gute Kartendarstellung ermöglicht, ohne den Mappingaufwand extreme zu erhöhen.


Viele Grüße
Henning, developer of RadReiseKarte

Offline

#64 2022-01-01 06:58:47

aighes
Member
From: Shanghai
Registered: 2009-03-29
Posts: 5,346
Website

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

skyper wrote:

Selbst als eine Person, die gewöhnt daran ist mit dem Fahrrad aus Straßenbahnschienen und über Bächle zu springen, ist ein Bordstein und ein Bächle erst Mal eine Barriere. Ich würde mir wünschen, wenn mein Fahrradrouter mich spätestens 50m vorm Linksabbiegen auf die Straße lotst oder im Profil ohne Anhänger und Gepäck mir wenigstens mitteilt, dass ich springen sollte.
Von Personen mit Einschränkungen und Mobilen die schon bei ein paar Zentimeter Höhenunterschied Probleme bekommen reden wir hier ja gar nicht.

Ich denke da sind deine Ansprüche zu hoch. Der Router soll dir einen guten und nutzbaren Weg von A nach B geben. Aber du musst schon noch selber auf die Straße schauen und die Situation einschätzen. Vorallem im Nahbereich. Oder soll der Router auch noch wissen, dass der abgesenkte Bordstein in 50m von einem haltenden Auto belegt ist (oder es eine tiefe Pfütze hat) und du besser schon 100m vorher auf die Straße wechselst wink

Wünschen würde ich mir sowas aus, aber realistisch ist es in meinen Augen nicht. Zumindest nicht aktuell.


Viele Grüße
Henning, developer of RadReiseKarte

Offline

#65 2022-01-01 20:03:52

Hungerburg
Member
Registered: 2020-12-11
Posts: 418

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

aighes wrote:

Ich meinte das grafische Turn-Lanes-Tagging Tool. Wo man ohne Kenntnisse des Schemas sich zusammen klickt, wie es vor Ort ist.

Guter Tipp, mit dieser Erweiterung für JOSM konnte ich ein paar Sachen ins Reine bringen, die mir Osmose seit Längerem schon aufgehalst hatte - Lanes tagging ist ohne nämlich zum Haareraufen, aber so, das könnte zum Hobby werden smile

Offline

#66 2022-01-01 21:19:50

JochenB
Member
Registered: 2012-01-24
Posts: 483

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

aighes wrote:
JochenB wrote:
aighes wrote:

... ist es häufig der Fall, dass kleine Nebenstraßen/Dorfzufahrten nur zum Radweg führen. Du musst dich also rechtzeitig quasi richtig "einordnen" (auch mit KfZ) um in das Dorf zu gelangen.

Das verstehe ich nicht ganz. ... Hast du ein Beispiel mit Luftbild oder Ähnlichem?

Bspw.: https://www.google.com/maps/@31.2482522 … a=!3m1!1e3

Wenn du zu dem "Hof" willst, musst du ein paar Meter vorher von der Straße auf den "Radweg" wechseln und kannst dann in den "Hof" einfahren.

Oder hier: https://www.google.com/maps/@31.2661106 … a=!3m1!1e3

Ich setze Radweg mal in "" weil man sich evtl. doch von der Vorstellung eines deutschen Radwegs lösen muss. Radweg ist hier idR.  2-3m breit, sodass er auch ohne Probleme von einem Auto befahren werden kann.

Ich schließe mich da Hungerburg an, das würde ich nicht über lanes machen sondern als eigenen Weg. Grundsätzlich sollte das aber auch über lanes gehen, es braucht - wie du schon schriebst - nur eine Angabe, zwischen welchen Spuren man wechseln kann.

Offline

#67 2022-01-01 21:44:45

JochenB
Member
Registered: 2012-01-24
Posts: 483

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

aighes wrote:

Auch eine bauliche Trennung könnte man im Spuren-Schema darstellen, scheint aber noch nicht zu existieren. Aber bspw. statt | könnte man \ oder / nehmen. Nur so als Idee. Das Problem ist aber, dass Radweg und Fußweg ein anderes Schema haben und aktuell nicht als Spur angesehen werden. Das macht es schwer Relationen der Spuren dar zu stellen.

Bsp. zu deinem Bild:
horizontal

lanes:type:forward=highway\cycleway|footway
lanes:type:backward=highway\cycleway|footway

vertikal

lanes:type:forward=highway\footway
lanes:type:backward=highway\footway

Das über ein alternatives Symbol zu '|' zu machen finde ich spannend. Die Raute '#' wäre da meines Erachtens noch besser geeignet als '\', die sieht aus wie etwas Durchgestrichenes. Man braucht dann aber auch ein Symbol für "Spurwechsel erlaubt" denn der klassische Strich '|' trägt keinerlei dieser Informationern in sich. Vielleicht ein '+'?

Ich musste kürzlich auch lernen, dass 'type' kein guter Schlüsselname ist, weil man aus 'type' nicht erkennen kann, wass für ein Wert dort erwartet wird. Statt 'type' müsste dort Stehen 'main_user' oder so ähnlich. Aber: Bisher haben wir die Widmung der Spuren über die access-Tags abgebildet, hier als Beispiel für eine zweispurige Fahrbahn mit Radstreifen und Benutzungspflicht in Geradeaus-Richtung. Das müsste doch reichen, oder?:

vehicle:forward=yes|yes|no
bicycle:forward=yes|no|designated
turn:lanes:forward=left|through|none

Hier könnte man nun z. B. das turn:lanes verwenden, um die Querungsmöglichkeiten zu eruieren, z.B.

turn:lanes:forward=left+through#none

Also durchgezogene Linie zwischen Radstreifen und Geradaus-Spur, gestrichelte zwischen Geradeaus- und Lonksabbiege-Spur.

Aber wenn du so etwas viorschlagen wilsst, solltest du eine neue Diskussion beginnen.

Hinweis: vor Kurzem hatten wir ein ähnliches Thema diskutiert. Dort ging es um den Übergang von Spuren beim, Wechsel einem way auf den nächsten.

Für das Beispielbild der Verkehrswende Berlin-Mapper mit den parallelen Rad- und Gewegen würde beim Zusammentaggen aber Folgendes reichen:

cycleway:kerb=yes

Wobei ich das als Standardwert ansehen würde, wenn kein anderers 'kerb' getaggt wurde.

Offline

#68 2022-01-01 22:22:25

JochenB
Member
Registered: 2012-01-24
Posts: 483

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

skyper wrote:

Selbst als eine Person, die gewöhnt daran ist mit dem Fahrrad aus Straßenbahnschienen und über Bächle zu springen, ist ein Bordstein und ein Bächle erst Mal eine Barriere. Ich würde mir wünschen, wenn mein Fahrradrouter mich spätestens 50m vorm Linksabbiegen auf die Straße lotst oder im Profil ohne Anhänger und Gepäck mir wenigstens mitteilt, dass ich springen sollte.
Von Personen mit Einschränkungen und Mobilen die schon bei ein paar Zentimeter Höhenunterschied Probleme bekommen reden wir hier ja gar nicht.

Das ist beim Zusammen-Mappen doch datenmäßig problemlos möglich. Programmiere den Router so, dass er nur dort den Radweg verlässt, wo

  • am Weg 'cycleway:kerb=no/lowered/flush/rolled' oder 'cycleway:kerb:height<=3cm' getaggt wurde

  • eine Grundstückseinfahrt oder Straße von rechts kommt

  • am Knoten 'highway=crossing' mit dem Tag 'kerb=no/lowered/flush/rolled' oder 'kerb:height<=3cm' getaggt wurde

oder habe ich da etwas nicht bedacht?

aighes wrote:

Ich denke da sind deine Ansprüche zu hoch. Der Router soll dir einen guten und nutzbaren Weg von A nach B geben. Aber du musst schon noch selber auf die Straße schauen und die Situation einschätzen. Vorallem im Nahbereich. Oder soll der Router auch noch wissen, dass der abgesenkte Bordstein in 50m von einem haltenden Auto belegt ist (oder es eine tiefe Pfütze hat) und du besser schon 100m vorher auf die Straße wechselst wink

Wünschen würde ich mir sowas aus, aber realistisch ist es in meinen Augen nicht. Zumindest nicht aktuell.

Routing ist nicht gleich Routing. Hier wird sich ein Mikro-Routing gewünscht. Auch für barrierefreies Routen für z. B. Rollstuhlfahrer  oder eine genaue Abbildung in der Kartendarstellungen der Navigationsgeräte erscheint Mikro-Routing hilfreich.

Wer zügig mit dem Fahrrad oder gar Auto unterwegs ist, braucht dagegen Abstraktion, also Makro-Routing. Da kann man nicht alle 10m mit neuen Hinweisen überfordert werden.

Auch hier gibt es kein Gut und Böse. Mikro-Routing geht mit dem Getrennt-Mapping besser, das andere mit dem Zusammen-Mapping.

Und auch hier: Wenn man beim Getrennt-Mapping die ein-eindeutige Zuordnung zwischen Radweg/Gehsteig und Fahrbahn hinbekommen würde, so könnte man auch mit Getrennt-Mapping ein abstrakteres Routen machen. Der Router muss nur vorher die Eigenschaften der Radwege/Gehsteige an die Fahrbahnkante übertragen um dann die Radweg-/Gehweglinien auszublenden. Aber leider gibt für diese ein-eindeutige Zuordnung noch kein Datenmodell. Daher ist dafür bislang das Zusammen-Mappen die bessere Alternative.

Offline

#69 2022-01-02 00:35:14

Hungerburg
Member
Registered: 2020-12-11
Posts: 418

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

JochenB wrote:

Auch hier gibt es kein Gut und Böse. Mikro-Routing geht mit dem Getrennt-Mapping besser, das andere mit dem Zusammen-Mapping.

Das klingt versöhnlich, nicht sicher ob ich dem uneingeschränkt zustimmen mag. Z.B. auf eine Straße mit Gehweg nur auf einer Seite:

- Die Makro-Routing Ansage würde mich, an der Stelle, an der mein Ziel auf der anderen Straßenseite liegt auffordern hier die Straße zu queren, egal ob dort ein Übergang kartiert ist oder nicht.
- Die Mikro-Routing Ansage würde mich bei der nächstgelegenen kartierten Garageneinfahrt auffordern, vom Gehweg auf die Straße zu wechseln, weil nur dort ein Übergang kartiert ist.

Was hier Makro oder Mikro ist? Frei nach Henning: das sieht man dann, wenn man dort ist, oder nah dran genug.

JochenB wrote:

Daher ist dafür bislang das Zusammen-Mappen die bessere Alternative.

Es geht hier ja um Radwege, und nicht um Gehwege; Aber selbst Leute mit vermindertem Sehvermögen, die man selten Radeln sieht, auch mit Lastenfahrrad nicht, die stimmen da wie dort zu, wozu auf die Straße wechseln, wenn es nicht sein muss, im Fall der straßenbegleitenden Gehwege, nicht einmal sein darf?

Offline

#70 2022-01-02 09:14:38

aighes
Member
From: Shanghai
Registered: 2009-03-29
Posts: 5,346
Website

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

Hungerburg wrote:

Das klingt versöhnlich, nicht sicher ob ich dem uneingeschränkt zustimmen mag. Z.B. auf eine Straße mit Gehweg nur auf einer Seite:

- Die Makro-Routing Ansage würde mich, an der Stelle, an der mein Ziel auf der anderen Straßenseite liegt auffordern hier die Straße zu queren, egal ob dort ein Übergang kartiert ist oder nicht.

Nein, in typischen Makro-Routing kannst du nur an Kreuzungen oder anderweitig definierten Übergängen die Straßenseite kreuzen. Du würdest also min. eine Kreuzung eher auf die richtige Seite gelotst. Du bekommst aber auch keinen Stromschlag, wenn du es nicht machst. Nichts-desto-trotz sollte die Route "funktional" sein. Bspw. wenn eine Kreuzung vorher keine abgesenkte Bordsteinkante vorhanden ist, würdest du beim Rollstuhlrouting evtl. eine Kreuzung weiter geroutet und dann ein paar Meter auf der anderen Seite zurück. Es obliegt dann deiner Einschätzung vor Ort, die Straße auch schon eher zu überqueren, wenn du kannst. Auch hier gibts keinen Stromschlag vom Navi.

Hungerburg wrote:

- Die Mikro-Routing Ansage würde mich bei der nächstgelegenen kartierten Garageneinfahrt auffordern, vom Gehweg auf die Straße zu wechseln, weil nur dort ein Übergang kartiert ist.

Ja, wobei ich hier kaum Vorteile sehe. Nicht ohne Grund setzten auch alle "autonomen" Fahrzeuge im Detail auf eigene Umgebungserfassung und nicht auf Kartendaten. Was hilft es dir im Micro-gemappten Datensatz, wenn die Rabauken gestern Bierflaschen zerkloppt haben und du mit dem Rollstuhl nicht mehr die Abgesenkte Bordsteinkante nutzen kannst. Dass du selber nachdenken musst, wirst du nie micro-gemappt bekommen.


Viele Grüße
Henning, developer of RadReiseKarte

Offline

#71 2022-01-02 09:29:42

aighes
Member
From: Shanghai
Registered: 2009-03-29
Posts: 5,346
Website

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

JochenB wrote:

Das über ein alternatives Symbol zu '|' zu machen finde ich spannend. Die Raute '#' wäre da meines Erachtens noch besser geeignet als '\', die sieht aus wie etwas Durchgestrichenes. Man braucht dann aber auch ein Symbol für "Spurwechsel erlaubt" denn der klassische Strich '|' trägt keinerlei dieser Informationern in sich. Vielleicht ein '+'?

Habe da jetzt nicht so wirklich über das perfekte Trennzeichen nachgedacht. Sinnvoll klingt:

| = Spurwechsel möglich
# = kein Spurwechsel
\ = Spurwechsel nur von rechts nach links möglich
/ = Spurwechsel nur von links nach rechts möglich
JochenB wrote:

Ich musste kürzlich auch lernen, dass 'type' kein guter Schlüsselname ist, weil man aus 'type' nicht erkennen kann, wass für ein Wert dort erwartet wird. Statt 'type' müsste dort Stehen 'main_user' oder so ähnlich. Aber: Bisher haben wir die Widmung der Spuren über die access-Tags abgebildet, hier als Beispiel für eine zweispurige Fahrbahn mit Radstreifen und Benutzungspflicht in Geradeaus-Richtung. Das müsste doch reichen, oder?:

vehicle:forward=yes|yes|no
bicycle:forward=yes|no|designated
turn:lanes:forward=left|through|none

Wäre auf der einen Seite eine gute Idee,weil man weniger Neues definieren muss, auf der anderen Seite hättest du mit der Art die Möglichkeit auch spezielle Spuren zu klassifizieren. Sowas wie eine Standspur auf der Autobahn beispielsweise.


Viele Grüße
Henning, developer of RadReiseKarte

Offline

#72 2022-01-02 11:33:40

JochenB
Member
Registered: 2012-01-24
Posts: 483

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

aighes wrote:

Habe da jetzt nicht so wirklich über das perfekte Trennzeichen nachgedacht. Sinnvoll klingt:

| = Spurwechsel möglich

Achtung, damit definierst du dieses Zeichen um. Bisher stand es nur als Spur-Trenner ohne Aussage über das Spur-Wechseln. Mit diesem Vorschlag würde es aussagen, dass ein Spur-Wechsel möglich ist. Mit der Umdeutung weiß niemand mehr, ob die alte oder neue Bedeutung gemeint ist. So etwas sollte vermieden werden.

So war es beim Einführen von 'surface=sett'. Seit dem weiß man bei 'surface=cobblestone' nicht mehr, ob da wirklich das runde Katzenkopfpflaster liegt oder doch gehauenes, ebeneres Pflaster.

Daher sollte '|' für "Keine Angabe zu Spurwechsel" stehen. Für "Spurwechsel möglich" müsste ein anderes Symbol her. Ich dachte an '+' oder besser '-'. Zu prüfen wäre, ob diese beiden Symbole nicht bereits für andere Taggings belegt sind, z. B. in conditional restrictions und ob diese Taggings an dieser Stelle in Frage kommen. Z.B. für eine Spur, die nur Samstag-Sonntag+Feiertags eine Abbiegespur ist.

aighes wrote:
JochenB wrote:

...Das müsste doch reichen, oder?:

vehicle:forward=yes|yes|no
bicycle:forward=yes|no|designated
turn:lanes:forward=left|through|none

Wäre auf der einen Seite eine gute Idee,weil man weniger Neues definieren muss, auf der anderen Seite hättest du mit der Art die Möglichkeit auch spezielle Spuren zu klassifizieren. Sowas wie eine Standspur auf der Autobahn beispielsweise.

Ich habe im Wiki kein OSM-Tagging für Standspuren gefunden. Dein Vorschlag würde dann an einer 2-spurigen Fahrbahn möglicherweise so aussehen:

lanes=2 
emergency_stop=no|no|yes

Aber: Die lanes-Angaben in 'emergency_stop' bilden nur "Fahrspuren" ab, nicht den ruhenden Verkehr. Es müsste sich also eher an dem Tagging vom straßenbegleitenden Parken orientieren, wober das "parking" in meinen Ohren nicht passend ist, denn es ist eher ein Nothalt. Zu vermeiden wären Partplatzsymbole an Nothaltebuchten. Also eher

emergency_stop:lanes=right

Das wird jetz allerdings immermehr off topic. Du solltest einen neue Diskussion dazu starten. Hier geht es ja um Vor-/Nachteile für Zusammenmappen von Radwegen an der Straßenkante.

Offline

#73 2022-01-02 15:10:45

skyper
Member
Registered: 2020-06-08
Posts: 592

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

Sorry, hab gerade nicht viel Zeit, daher nur kurz ein wichtiger Hinweis

aighes wrote:
skyper wrote:
aighes wrote:

Wie bereits gesagt, es braucht nur eine Unterstützung im Editor, dass es jeder sich zusammen klicken kann. Da gibt es ja schon was in jOSM, nur scheinbar nur für Abbiegespuren.

Was meinst Du? In JOSM gibt unabhängige Vorlagen, Erweiterungen und Kartenstile.

Ich meinte das grafische Turn-Lanes-Tagging Tool. Wo man ohne Kenntnisse des Schemas sich zusammen klickt, wie es vor Ort ist. Die müsste dann ein wenig erweitert werden wink

Oh, dass ist aber sehr rudimentär. Wo ist da die Unterstützung für Fahrradstreifen und Busspuren? Sowas wie access tags und `change` wären schon schön.

Habe es gerade zum ersten Mal ausprobiert und gleich einen Bug gefunden, da die Erweiterung `lanes=*` und `lanes:backward/forward` in einigen Situationen falsch berechnet.
Das ist es natürlich nicht gut, dass weder `F1` auf den Tags zu den Wikiseiten führt noch sonst wo ein Link zum Taggingschema vorhanden ist. neutral

Edit: Zitat richtig gestellt.

Last edited by skyper (2022-01-02 15:13:18)

Offline

#74 2022-01-02 17:08:09

JochenB
Member
Registered: 2012-01-24
Posts: 483

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

Hungerburg wrote:
JochenB wrote:

Auch hier gibt es kein Gut und Böse. Mikro-Routing geht mit dem Getrennt-Mapping besser, das andere mit dem Zusammen-Mapping.

Das klingt versöhnlich, nicht sicher ob ich dem uneingeschränkt zustimmen mag. Z.B. auf eine Straße mit Gehweg nur auf einer Seite:

- Die Makro-Routing Ansage würde mich, an der Stelle, an der mein Ziel auf der anderen Straßenseite liegt auffordern hier die Straße zu queren, egal ob dort ein Übergang kartiert ist oder nicht.
- Die Mikro-Routing Ansage würde mich bei der nächstgelegenen kartierten Garageneinfahrt auffordern, vom Gehweg auf die Straße zu wechseln, weil nur dort ein Übergang kartiert ist.

Was hier Makro oder Mikro ist?  ...

JochenB wrote:

Daher ist dafür bislang das Zusammen-Mappen die bessere Alternative.

Es geht hier ja um Radwege, und nicht um Gehwege; Aber selbst Leute mit vermindertem Sehvermögen ..., die stimmen da wie dort zu, wozu auf die Straße wechseln, wenn es nicht sein muss, im Fall der straßenbegleitenden Gehwege, nicht einmal sein darf?

Das ist ja eine Frage, wie man den Router programmiert. Will ich überall Queren/Wechseln wo es nicht ausdrücklich verboten wurde oder nur an ausgewiesenen Querungen? Das kann der Router selber entscheiden.

Auch das muss kein hartes "entwederoder" sein, man kann das direkte Queren mit Maluspunkten versehen, vielleicht sogar abhängig von der Anzahl der Spuren, vom Straßentyp und der Breite ... Hier könnte man durchaus die Profile verwenden, der Eine mag es, der andere nicht. Das betrifft auch den Wunsch von skyper, beim Linksabbiegen vor einer Kreuzung auf die Straße zu wechseln oder lieber doch direkt an der Kreuzung indirekt links abzubiegen.

Hungerburg wrote:

Frei nach Henning: das sieht man dann, wenn man dort ist, oder nah dran genug.

Genau, nur weil man es machen kann heißt das nicht, dass man es machen muss oder ob es überhaupt praktikabel ist.

Wir sollten unabhängig davon versuchen die Daten so zu erfassen, dass man damit so viel wie möglich anstellen kann. Allerdings besteht die Gefahr, dass wir es den Basic-Funktionen schwer machen (z. B. Routing für Normal-Radfahrer) um es Spezialanwendungen leichter zu machen (z. B. Barrierefreies Routen).

Daher plädiere ich dafür sich nicht auf Getrennt- oder Zusammenmappen festzulegen sondern das jeweilig passende Schema zu wählen, in Abhängigkeit davon, wie kompliziert das da draußen ist und wie detailliert gemappt wird.

Offline

#75 2022-01-02 18:38:57

JochenB
Member
Registered: 2012-01-24
Posts: 483

Re: Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

Achso, Folgendes habe ich nicht verstanden:

Hungerburg wrote:

...
5 Wege: 1 mit 2 Spuren (Fahrbahn) + 4 (je ein Radweg + je ein Gehweg links/rechts)
...

Die Berliner Verkehrswende scheint mir Variante 5 zu favorisieren, verfechten wär mir fast herausgerutscht. Wenn ich mich recht erinnere werden da auch noch zwischen Fahrbahn und Radweg je Linien mit abwechselnd kerb=flush|lowered|raised fällig, um zu kennzeichnen, wo man barrierefrei auf die Fahrbahn wechseln kann. Das wäre dann Variante 7.

Ich gebe zu Bedenken, dass das für manche in OSM-Carto nett anzusehen sein mag und dass Router so zwar exakte Geometrien haben, aber damit in vielen Fällen nichts sinnvolles anfangen können, ja dass das sogar kontraproduktiv zu vernünftigem Routing wird, solange nicht eine Fläche gemappt wird, die eindeutig klar macht, dass es sich bei den einzelnen Wegen um nicht viel mehr als Spuren einer Straße handelt. Relationen reichen da übrigens nicht, die helfen nur turn-by-turn Anweisungen netter zu gestalten, es müssen schon Flächen sein. (Laut opencyclemap Entwickler)

Getrennt-Mapping ohne Flächen ist nur die halbe Miete. Kann das als Nachteil in die Gegenüberstellung aufgenommen werden?

Würde ich gerne, aber wozu genau braucht man die Flächen? Als logische Verknüpfung der Spuren im Seitenraum mit den Spuren der Fahrbahn? Ist das die gesuchte ein-eindeutige Verknüpfung zwischen den Linien im Seitenbereicht und Linen der Fahrbahn? Wie genau soll das funktionieren, insbesondere wenn die Linien über mehrere Flächen gehen?

Die fehlende Verknüpfung zwischen Fahrbahn-Linien und Seitenraum-Linien wurde als nachteil des Getrennt-Mapping ja bereits genannt.

Offline

Board footer

Powered by FluxBB