Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

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 :slight_smile:

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.

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.

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?

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.

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.

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?

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.

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.

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

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.

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.

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.

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

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. :expressionless:

Edit: Zitat richtig gestellt.

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.

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.

Achso, Folgendes habe ich nicht verstanden:

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.

Dass du das fragst :wink: Ich hab das hier aufgegriffen, oben #55:

In einem Vortrag beschreibt ein Radrouter Entwickler Ähnliches, gesucht, gefunden - https://www.cyclestreets.org/news/2019/09/22/sotm2019/ - nicht opencyclemap sondern cyclestreets. Die Sache ist ein wenig komplexer, aber generell seh ich das so, dass detaillierteres Mappen die Probleme vermehrt, anstatt sie zu verringern. Und der einzige Ausweg, wenn die “Schienen” einmal gelegt sind, der ist, noch mehr zu machen: Flächen definieren, wo es erlaubt ist, die Schienen zu verlassen. Nicht nur auf den ersten oder letzten 10 Metern.

Auf den letzten Metern ist das sicher bequem, aber mitten auf der Strecke kann so ein “Hupfer” in die Hose gehen. Da helfen nur die erwähnten Flächen. In vielen Fällen würde es auch reichen, nicht separat zu mappen, aber das ist scheints nicht wirklich in.

Ich hätte wohl schreiben sollen “Ein Makro-Router stellt mich einfach an der Straße ab, wo das Ziel am nächsten liegt”, und es bleibt mir überlassen, wie ich mich dann weiter zurechtfinde; ein Router also, der nur die Information hat, dass an der Straße auf einer Seite ein Radweg ist. Die rudimentäre Information über den Radweg ist trotzdem nicht umsonst, sie kann zB eine Route appetitlicher als eine andere machen.

Stimmt, es ging primär zu schauen, was man mit “Zusammen-Mappen” noch erreichen kann und was nicht.

Wenn man es zusammen fasst: Man kommt in speziellen Fällen nicht um ein getrennt mappen herum, aber ein Großteil der begleitenden Wege könnte in einen sinnvollen Näherung per Tag abgedeckt werden. Es fehlt aber hier komplett an Unterstützung der grafischen Auswerter und bedingt an Unterstützung der Mapper beim Eintragen. Es wird der Weg des geringsten Widerstandes genommen, was dann im getrennt-Mappen endet, weil es scheinbar einfach schön anzusehende Karten produziert und scheinbar besseres Routing.

ich habe mich hier mangels Zeit eine ganze Weile lang zurückgehalten, wollte aber anmerken, dass das Getrenntmapping nicht bedeutet, dass es unmöglich ist, daraus die Radwegeigenschaften auf die Straße zu übertragen, auch wenn sie dort nicht explizit gemappt sind. Vielmehr wird das dadurch viel aufwendiger, es ist aber grundsätzlich möglich (durch komplexe Datenbankabfragen). Andererseits ist es nicht möglich, fehlende Geometriedetails aus dem impliziten Mappen von straßenbegleitenden Wegen als tags auf einem geometrisch unabhängigen highway=“straße” irgendwo herzuleiten.

Weiterhin wollte ich fragen, was ihr von dem impliziten Mappen von Straßen an Radwegen haltet? Man könnte ja durchaus alternativ zum hier diskutierten Vorgehen auch nur den highway=cycleway mappen und die Straße daneben weglassen, dafür aber einen tag residential_highway=left oder so an den Radweg ergänzen, der die Straße repräsentiert. Dadurch könnte man noch bessere Fahrradkarten rendern, und würde nicht den Bezug der Straße zum Radweg verlieren. residential_highway:maxspeed=50, residential_highway:lanes=2, etc., man kann so im Prinzip alles abbilden, vor allem wenn die beiden Wege parallel verlaufen und man jederzeit vom Radweg auf die Straße wechseln kann.

+1

:sunglasses:

Machst Du das propsal? Ich stimme dafür!

Dann solltest du dir aber auch die Frage stellen, warum du den flächigen Weg nicht als Fläche einträgst, sondern als Linie und schlussendlich auch an die dritte Dimension denken :wink:

Nein, Spaß bei Seite. Vollkommen richtig, es ist eine Abwägung von Vor- und Nachteilen. Sonst hätten wir diese Diskussion ja nicht. Nicht jede Tool-Chain arbeitet mit Datenbanken. Möglich ist alles, auch Relationen um KfZ-spuren, Radweg und Fußweg zu verbinden wären denkbar. Ebenso kommst du mit diesem Detail-Mapping dann irgendwann in Größenordnungen, wo die Auswertung eben nur noch für sehr wenige (Big-Player) praktikabel ist weil du und ich uns die Hardware nicht mehr leisten können.

Da sitzt du aber dem Irrtum auf, dass Straße nicht gleich Fahrbahn für KfZ ist sondern dass zu einer Straße auch meist 2 Gehsteige (evtl. auch Radwege) dazugehören. :wink:

Volles Einverständnis. Market Consolidation heißt das in der BWL. Embrace and Extend hab ich auch schon gelesen. In der gelobten Konsequenz sicher zielführend, wenn man OSM first-mover-routing untauglich machen will. Das ist eine Sache für die Platzhirschen und solls werden, ah bleiben.

Was soll das schließlich heißen - weniger wäre mehr? Nur Mehr ist Mehr! Also: OSM braucht dringend Flächen, die kennzeichnen, wo man die kartierten Wege verlassen, will heißen, ignorieren darf, und was dort alles erreichbar ist. Es ginge billiger, aber wo bleibt dann das (Wirtschafts-) Wachtsum?

Das wäre schön, aber wie machst du das? Einerseits, wie formuliert man eine solche Datenbankabfrage generisch? Andererseits, wie ordnet man die Radweg-Infos den Straßenlinien zu wenn Radwege und Straßenlinien nicht an den gleichen Stellen geteilt sind? Auch die Zuordnung, welcher Radweg-Teil an welche Straßen-Teil gehört ist nicht immer eindeutig.

Man müsste mit der Datenbankabfrage die Straßenkanten teilen können, sowohl an bestehenden Knoten, als auch zwischen den Knoten.

Bei unterschiedlichen Längen von Radweg und Fahrbahn müsste interpoliert werden.

Zudem braucht es einen Algotithmus, der entscheidet, ob ein Weg als paralleler Radweg durchgeht oder ob es z.B. nur eine Verbindung zwischen Straße und Radweg ist.

Ich habe mal 3 Beispiele gezeichnet. Grün und Blau sind die Linien der separaten Radwege / Gehsteige. Rot bis Lila sind die Straßenlinien. Wo die Farbschattierung wechselt sind die Linien geteilt weil sich Attribute ändern. Die Attribute der blauen und grünen Radweg- / Gesteig-Linien sollen vor dem Routen den Straßen-Linien zugeordnet werden.

Im Beispiel A) sollen die Infos aus den drei Radweglinien 1-2, 2-3 und 3-4 an die Straßenlinien 7-8-9 und 9-10. Dazu müsste die Straßenlinie am Knoten 8 geteilt werden. Ob der Knoten 3 und der Knoten 9 wirklich zusammengehören wäre in der Datenbankabrage zu entscheiden, ggf. muss nahe dem Knoten 9 nochmal geteilt werden.

Im Beispiel B) müssten die Straßenlinie 9-8-9 und die Linie 9-10 geteilt werden.

Im Beispiel C) müssten ebenso Straßenlinen mehrfach geteilt werden. Zudem ist für die Straßenlinie 9-5 zu entscheiden, ob die Linie 4-5 ein paralleler Radweg ist (so wie 3-4) oder nicht. Aus der Datenbankabfrage müsste dabei herauskommen, dass bereits die Linie 4-11 der parallele Radweg ist und 4-5 nur eine Verbindung zwischen Radweg und Fahrbahn.

Ich bin mir nicht sicher, ob das alle Schwierigkeiten sind.

Ich bin kein Datenbankprofi, kann mir aber nicht richtig vorstellen, dass man das in einer Abfrage hinbekommt.

Eher kann ich mir vorstellen, dass man Übertragen der Radweg-Eigenschaften an die Straßenlinien in einem Vor-Prozess unter Nutzung von Routingalgorithmen macht. Man schaut vorab bei jeder Kreuzung, welche alternativen Fahrwege über Radwege es zur nächsten Kreuzung gibt. Die Attribute dieser Wege werden dann zur Wichtung der Straßenlinien genutzt.

Ich vermute das alles ist entweder nicht eindeutig machbar. Vermutlich ist auch der Code dazu so kompliziert oder rechenaufwändig, dass es nicht realistisch umsetzbar ist. Es verbleibt also als einer der großen Nachteile des Getrennt-Mappings, dass das Routing an “mikroskopisch” abgebildeten Kreuzungen teilweise unbrauchbar wird.

Die Info, ob der seperate gemappte Weg nun wirklich seperat ist oder ob ein Wechsel zur / Querung der Fahrbahn möglich ist nicht duch Datenbankabfragen oder Algorithmen generierbar, die muss irgendwie gemappt werden.

Ja, das ist einer der großen Nachteile des Zusammen-Mappings. Es stehen nur ‘width’ oder ‘lanes’ und ‘placement’ zur Verfügung, um die Lage einigermaßen zu verorten. Bei fahrbahnnahen, weitgehend parallelen Radwegen sollte das aber ausreichen.

Da gab es ein DDR-Lied “Sag mir wo du stehst?” Als Radfahrer sind Radwege der Nabel der Welt, Autos sind eh’ Schrott der Geschichte. Als Grundstücksbesitzer sind es aber eher die Grundstücke. Also wenn, dann eher die äußerste Grenze der Straße mappen, also von außen nach innen, oder :wink: ?

Die bisherige Abstraktion durch Linien hätte ich so verstanden, dass die Linie standardmäßig die Mitte der Straße / der Fahrbahn abbildet und die Fahrspuren/Seitenräume von dort aus gezeichnet werden. Das wäre eine Umkehr des Ganzen, hat auch so seine Reize.

Das Problem würde es aber auch nicht lösen. Wenn auf der anderen Seite ein Radweg verläuft haben wir wieder 2 Linien wo sich die Frage stellt, “Wo kommt man von der einen auf die andere Linie?”.

Vielleicht eine andere Möglichkeit: Alle Radwegdetails an die Straße mappen, den geometrischen Verlauf dann separat aber ohne weitere Attribute außer einen Tag das sagt “Attribute stehen an der Straße”. Dann fehlen die Infos allerdings beim mikroskopischen Routing.

zum Thema Bigplayer und Hardwareanforderungen, das kommt auf die Größe an, small players können das dann vielleicht nicht weltweit machen sondern nur in kleineren Gebieten. Oder nur für ein Spezialgebiet und nicht für alle möglichen Features, oder nicht live sondern nur mit monatlichen Updates, etc. Es ist auch mit „Heimhardware“ möglich, die Daten aufwendig vorzubereiten, eher wird es an Entwicklerzeit als an der Hardware scheitern.

ja klar, wenn man die Radwegeigenschaften für das Rendering an der Straße haben will muss man die Straße in diesem Schritt auch weiter aufteilen. Soweit es halt für die Renderregeln notwendig ist, und umgekehrt kann man zusätzlich auch alle Segmente verbinden, die man gleich rendern will.
Der Algorithmus könnte einen Buffer um die Radwege legen und darin alle Straßen suchen, und davon die nächste nehmen. Das für alle nodes des Radwegs machen, ggf. noch prüfen ob die Straßensegmente alle verbunden sind und ggf. fehlende Zwischenstücke suchen (per Routing). Welchen Abstand man dabei setzen will ab dem man es nicht mehr macht, das macht man abhängig von der Ziel-Zoomstufe und der Straßenbreite die man dort rendert.

Nur mal als Fragmente, ich gebe zu dass es da viele schwierige Probleme gibt, vielleicht geht es auch gar nicht zuverlässig, jedenfalls gibt es sicher Stellen wo es nicht gehen würde bzw. Fehler machen würde.

Viel einfacher wäre es dadurch, dass man als Mapper mit einer Relation die Zuordnung Straße - Radweg definiert, dann würde es ausreichen, für die Wege für die es Relationen gibt, die Eigenschaften zu übertragen, das könnte durchaus ein dauerhafter Verarbeitungsschritt sein und müsste nicht jeweils on the fly in einer Datenbankabfrage generiert werden.