Vor- und Nachteile des indirekten Kartierens mittels cycleway=track

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.

Hallo Dieter, du hast *"wenn der Mapper fürs Mappen wenig Zeit hat" ins Wiki als Kriterium fürs Getrennt-Mapping geschrieben.

Das Anlegen eines einfachen separaten Radwegs im ID mit zwei Knoten braucht 6 Klicks.

Das Anlegen eines Radwegs als Attribut an eine bestehende Straßenkante braucht 4 Klicks. Wenn man erst die Vorlage “Fahrradstreifen” sucht braucht es 6 Klicks und ein “F” in der Vorlagensuche. Die Klicks für das Eingeben der Geometrie fallen komplett weg.

Weitere Attribute muss man immer eingeben, egal ob separat oder zusammen. Vorlagen können bei Beiden gleichermaßen helfen.

Fazit: Die Unterschiede sind nicht relevant, wenn, dann müsste das als Pro auf der anderen Seite stehen.

da hast du dich verlesen, das wenig Zeit haben Argument habe ich für das Gemischtmappen ergänzt, nicht für das getrennt Mappen

In Josm kannst du mit alt+a einen neuen tag hinzufügen, das Eintragen von Geometrie dauert immer länger, erst recht wenn man es sorgfältig macht

Oh, ich hab es in der Änderungsansicht gelesen und falsch einsortiert und mich echt gewundert, sorry! Als sonderlich relevant emfinde ich es trodtzem nicht. Wenn ich keine Zeit habe kann ich auch schnell Linien zeichnen, dann bin ich halt ungenauer. Besser grob als gar nicht kartiert. Aber ja, wenn man es sorgfältig macht ist das Linienmappen aufwendiger.

Wenn ich hier so mitlese scheint mir, den SOTM Vortrag von cylcestreets hat keiner angeschaut. Zur Erinnerung https://www.cyclestreets.org/news/2019/09/22/sotm2019/ - ganz besonders für die Radschienenleger, aber nicht nur, und ausgenommen freilich, wenn wir die Farbe der Pflasterung mappen, aber selbst dann?

vor allem weil ja eine Linie nicht reicht, man muss die dann auch an den Einfahrten und sonstigen Querungen verbinden, und diese ways muss man dann auch alle taggen. Und diese Details hat man sonst in der Regel auch einfach nicht, wenn man es über Attribute des highways macht, weil wenn man das alles mappen würde, dann würde man einen separaten Radweg auch mit einem eigenen way mappen :wink:

Genau. Im Prinzip kann ich dann “meine” (eingegebenen Daten) nur noch nutzen, weil andere sie mir vor-verarbeiten oder das Produkt zur Verfügung stellen. Und wenn ich darauf angewiesen bin, dass sie mir jemand vorbereitet, wo ist dann der Sinn, sie erst komplex einzugeben.

Das ist das nächste Problem.

Nur wenn Du überall auf der Welt Daten eingibst und Karten von überall und allem produzieren willst, dann schon, ansonsten kannst Du das für “Dein Gebiet” vermutlich auch allein leisten. Ist beim Routing und Rendering ja auch nicht anders, das könntest Du alles auch alleine machen, aber ist sehr viel Arbeit, und daher wird man normalerweise den Dienst von irgendjemandem nutzen, der diese Arbeit schon gemacht hat und dir das Ergebnis zur Verfügung stellt.

Es geht ja nicht ums “komplexe” Eingeben, sondern um das einfache Eingeben ohne Sonderregeln (eigener Weg mit eigener Fahrbahn als eigener way), das halte ich für weniger komplex als abstrakte cyclway:right:width=2 Angaben auf einer in der Nähe liegenden Straße verbunden mit der Erwartung, dass deswegen der Fahrradweg nicht mehr als way gemappt wird. Was komplexer wird ist die Zuordnung der Straße zum Fahrradweg, es ist aber nicht so, dass die überhaupt für alle Datennutzer relevant wäre.

Hallo Hungerburg,

jetzt hast du nahezu den gesamten Abschnitt ohne Ankündigung gelöscht. Nach dieser Disskussion hier empfinde ich das als unangebracht. Wir hatten hier darüber diskutiert, ob die Auflistung der Vor-/Nachteile dort reingehört da die sehr groß ist. Da bin ich auch dafür, es bei einem Verweis zu lassen. Aber von Alles-Löschen hat bislang Keiner gesprochen.

Hier haben sich schon Viele einen Kopf über diesen Text gemacht, das wäre nun alles weg. In einem solchen Fall sprech deine Ansichten bitte hier erst an, es kann ja duchaus sinnvoll sein. Statt Alles zu Löschen dann auch eher das Relevante (die Handlungsempfehlung?) an eine bessere Stelle schieben.

Ich habe ihn mir angeschaut nur noch keine Zeit dazu, hier zu antworten.

Einige Probleme des Getrennmappings hat er echt gut dargestellt. Es ist Wasser auf meine Mühlen, dass weder die eine noch die andere Mappingart in allen Fällen die bessere ist. Das sollten sich z. B. die hoffentlich Mitlesenden der Berliner Verkehrswende-Mapper anschauen, deren Wiki-Formulierungen schon nach “Verfechten” des einen Schemas klingen.

Allerdings bin ich aus dem Vortrag nicht schlauer geworden. Er sagt zwar, dass er im Flächenmapping den Ausweg sieht. Er erklärt aber nicht, wie das funktionieren soll. Wie bekommt er z. B. die Zuodnung der Flächen zu den Linien hin, wenn die Attribute an den Linien stehen, die Linien aber innerhalb einer Fläche geteilt sind und dort die Attribute wechseln?

Ich hatte ja gedacht, wenn der Router etwas abstrakter routen will, nimmt er die Linien der Fahrbahn statt die der mikro-gemappten Seitenbereiche. Ihn verstehe ich aber so, dass er fürs gehweg-Routen über Gehweg-Flächen routen will (bzw. Radweg). Da frage ich mich, wie er auf einer wabernden Fläche mit ständig ändernden Breiten erkennen will, ob die Fläche einen abbiegenden Gehsteig darstellt oder nur einen etwas unförmigen Gehsteig. Ist doch auch wieder nur “Raten nach Formen”.

Hallo Jochen, das gehört dort einfach nicht hin, nicht in dieser Ausführlichkeit. Ein eh schon langer Hinweis ist ja dort geblieben. Die viele Mühe, die es gemacht hat, das zusammenzustellen muss nicht umsonst gewesen sein. In einem Mediawiki geht nichts verloren - an der Stelle “In Abhängigkeit der” beginnend steht hier der Copy Paste freundliche Quelltext https://wiki.openstreetmap.org/w/index.php?title=DE:Tag:cycleway%3Dtrack&action=edit&oldid=2240251 um ihn an einem geeigneteren Ort neu zu platzieren. Vielleicht als ein Abschnitt von https://wiki.openstreetmap.org/wiki/DE:Bicycle/Radverkehrsanlagen_kartieren ? Es müsste aber selbst dort irgendwie erklärt werden, warum gerade cycleway=track so ausführlich diskutiert wird, wo es sich ja um einen Tag auf dem absteigenden Ast handelt, vgl. https://taginfo.openstreetmap.org/tags/?key=cycleway&value=track#chronology - Es muss da noch etwas Größeres dahinter stecken, das auszusprechen aber scheints nicht nur mir die Worte fehlen.