You are not logged in.

Announcement

*** NOTICE: By 30th of September 2022 the forum.openstreetmap.org will be retired, please request a category for your community in the new ones as soon as possible using this process, which will allow you to propose your community moderators. We expect the migration of data will be finished by that date, you can follow its progress here.***

#76 2022-01-02 23:28:56

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

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

JochenB wrote:

wozu genau braucht man die Flächen?

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

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

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.

skyper wrote:

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.

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.

aighes wrote:

in typischen Makro-Routing kannst du nur an Kreuzungen oder anderweitig definierten Übergängen die Straßenseite kreuzen.

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.

Offline

#77 2022-01-03 08:59:28

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

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

JochenB wrote:

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.

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.


Viele Grüße
Henning

Offline

#78 2022-01-04 12:17:38

dieterdreist
Member
From: Roma, Italia
Registered: 2010-09-22
Posts: 4,217
Website

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

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.

Last edited by dieterdreist (2022-01-04 12:18:59)

Offline

#79 2022-01-04 13:04:02

Mammi71
Member
Registered: 2018-06-25
Posts: 2,599

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

dieterdreist wrote:

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

cool

Machst Du das propsal? Ich stimme dafür!

Offline

#80 2022-01-04 13:26:51

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

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

dieterdreist wrote:

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.

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.

dieterdreist wrote:

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.

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


Viele Grüße
Henning

Offline

#81 2022-01-04 23:56:54

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

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

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.

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?

Offline

#82 2022-01-05 00:42:05

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

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

dieterdreist wrote:

... 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).

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.
Übertragen von Radweg-Eigenschaften an Straßenlinien

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.

dieterdreist wrote:

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.

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.

dieterdreist wrote:

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.

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.

Offline

#83 2022-01-05 00:49:57

dieterdreist
Member
From: Roma, Italia
Registered: 2010-09-22
Posts: 4,217
Website

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

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.

Offline

#84 2022-01-05 01:09:23

dieterdreist
Member
From: Roma, Italia
Registered: 2010-09-22
Posts: 4,217
Website

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

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.

Last edited by dieterdreist (2022-01-05 01:23:17)

Offline

#85 2022-01-05 01:15:54

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

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

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.

Offline

#86 2022-01-05 01:24:44

dieterdreist
Member
From: Roma, Italia
Registered: 2010-09-22
Posts: 4,217
Website

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

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

Last edited by dieterdreist (2022-01-05 01:26:53)

Offline

#87 2022-01-05 19:38:53

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

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

dieterdreist wrote:

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

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.

Offline

#88 2022-01-05 23:09:22

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

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

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?

Offline

#89 2022-01-05 23:20:43

dieterdreist
Member
From: Roma, Italia
Registered: 2010-09-22
Posts: 4,217
Website

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

JochenB wrote:

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.

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

Offline

#90 2022-01-06 11:58:21

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

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

dieterdreist wrote:

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.

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.

dieterdreist wrote:

Es ist auch mit „Heimhardware“ möglich, die Daten aufwendig vorzubereiten, eher wird es an Entwicklerzeit als an der Hardware scheitern.

Das ist das nächste Problem.


Viele Grüße
Henning

Offline

#91 2022-01-06 13:05:15

dieterdreist
Member
From: Roma, Italia
Registered: 2010-09-22
Posts: 4,217
Website

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

aighes wrote:

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.

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.

Offline

#92 2022-01-08 01:09:44

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

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

Hallo Hungerburg,

jetzt hast du <edit>nahezu</edit> 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.

Hungerburg wrote:

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?

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".

Last edited by JochenB (2022-01-08 01:31:11)

Offline

#93 2022-01-08 22:08:40

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

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

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. … id=2240251 um ihn an einem geeigneteren Ort neu zu platzieren. Vielleicht als ein Abschnitt von https://wiki.openstreetmap.org/wiki/DE: … _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/ … chronology - Es muss da noch etwas Größeres dahinter stecken, das auszusprechen aber scheints nicht nur mir die Worte fehlen.

Offline

#94 2022-01-08 23:17:47

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

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

JochenB wrote:

Allerdings bin ich aus dem Vortrag nicht schlauer geworden.

Bin diesbezüglich in keiner besseren Situation. Das erste das auffällt ist der reißerische Titel Is the OSM data model creaking? Der Anfang ist aber gleich gut: Wir modellieren flows. Das ist schon einmal eine Ansage: Wie soll ein flow OTG wahr sein? Aber eh, aus der Sicht von jemandem, der seit über einem Jahrzehnt an einem Router arbeitet, da kann es schon so aussehen. Und recht überlegt, so falsch ist es womöglich gar nicht. Denn es macht die Daten für Zwecke der Navigation brauchbar, einfach und gut. Ich kann mir vorstellen, dass Grundlagen für Navigation schaffen das Hauptmotiv von sehr vielen Edits an den Daten ist.

Weil, Neulinge bekommen das ja auf der Willkommensseite nach dem Anmelden so vorgesetzt, openstreetmap ist dazu da, Dinge in der Welt, an denen man ein Interesse hat, mit ihren Geokoordinaten in die Datenbank zu stellen. Bekannte von mir haben schon vor fünf Jahren das Interesse verloren, weil eh schon alles drin ist. Und es ist wirklich viel drin. Auch viel Unnützes, aber wer soll das entscheiden, und Platz ist Ende nie.

Der Vortrag kommt dann über ein paar Umwege zu dem Schluss, dass das Mappen von immer mehr flows, die sich ja ausgezeichnet als Linien darstellen lassen: Hier gehen die Leute, da fahren die Räder, dort fahren die Autos, die Mädchen nach links, die Knaben nach rechts; einen Haufen neue Informationen bringt, die sich für Navigationszwecke verwenden lassen, aber das Ende der Fahnenstange auch nicht ist. Nicht zuletzt, weil die Abbildung sich nicht in sinnvolle, verständliche turn-by-turn Anleitungen übersetzen lässt.

Richtig paradox wird es dann, wenn ich so Zeug lese, wie hier im Thread, "man könnte ja auch den "highway" als Attribut vom "cycleway" mappen, ganz so, als würde "highway" für Fahrbahn stehen. Highway steht für Straße, und da gehört mehr dazu als die Fahrbahn. So weit ist das Separieren scheints schon, dass Leute vor lauter flows separieren die Lebenswelt nicht mehr kennen. Das betont und damit endet ja auch der Vortrag, dass es ein Manko ist, dass es kein Konzept für so etwas alltägliches wie eine Straße gibt, das aber ein gravierendes ist, in einer openstreetmap nicht zuletzt, und dem abgeholfen werden muss. Von daher wohl der Titel des Vortrags.

Das mit den Flächen, als eine Art Relation, für die keine Linien gesplittet werden müssen, die diverse Inhalte erfassen kann, ohne dass dafür eine neue Rolle erfunden werden müsste usw. Das wäre ein Hit. Als ein Platzhirsch hat cyclestreets.net ja Ressourcen. Flächenrouter sind nicht trivial zu machen. Fußrouting das das nicht kann, das hat den Namen nicht verdient. Radrouting gehts wohl ebenso. Sogar Autorouter kämpfen ein Einzelfällen. Nur Bahnrouter nicht wink

Offline

#95 2022-01-08 23:44:52

dieterdreist
Member
From: Roma, Italia
Registered: 2010-09-22
Posts: 4,217
Website

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

damit Flächenrouting für Fußgänger überhaupt funktionieren könnte bräuchte man vollständige Daten was relevante Hindernisse angeht, jeder Zaun und jede Mauer und Böschung, jedes Cliff und jeder Graben, etc. lückenlos und detailliert, vielleicht gibt es das in Deutschland in manchen Gegenden, aber die Idee die existierenden Wege als Linien vorzugeben macht das ganze auch schon sinnvoll nutzbar lange bevor es „komplett“ ist.

Offline

#96 2022-01-09 00:11:51

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

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

Hungerburg wrote:

Hallo Jochen, das gehört dort einfach nicht hin, nicht in dieser Ausführlichkeit. Ein eh schon langer Hinweis ist ja dort geblieben.

Ich bin ja garnicht dagegen. Nur finde ich es merkwürdig, dass wir hier über den Rext reden und du ohne zu reden ihn einfach raus nimmst.

Schwamm drüber!

Hungerburg wrote:

Vielleicht als ein Abschnitt von wiki/DE:Bicycle/Radverkehrsanlagen_kartieren?

Ja, dort passt es gut.

Hungerburg wrote:

Es müsste aber selbst dort irgendwie erklärt werden, warum gerade cycleway=track so ausführlich diskutiert wird

Meines Erachtens gehört die Ausführlichkeit der Vor- und Nachteile auch dort nicht hin, da bin ich deiner Meinung. Dazu habe ich ja die Vor und Nachteile in einer eigenen Gegenüberstellung zusammengesammelt.

Eine Entscheidungshilfe passt da aber sehrwohl. Unter "Hinweise" gibt es bereits eine Überschrift "Entscheidungshilfe zwischen footway, cycleway und path". Davor oder danach könnte es als "Entscheidungshilfe zum Erfassen des Radwegs als eigenständige Linie oder an der Straßen-Linie" .

Die übergeordnete Überschrift sollte m. E. aber nicht "Kontroversen und Mehrdeutigkeiten" heißen, wenn dort Entscheidungshilfen enthalten sind. Im Text wird ja bereits darauf hingewiesen, dass die Alternativen häufig diskutiert werden. Was mit "Mehrdeutigkeit" gemeint ist, erschließt sich mir auch nicht.

Allerdings frage ich mich, ob einige der Kontroversen nicht bereits von der Praxis beantwortet wurden:

  • Gemeinsam genutzte Wege mit 'highway=cycleway' taggen oder neuer: 'highway=path'

  • 'access=designated' oder 'access=official' für benutzungspflichtige Wege

  • 'highway=cycleway' sollte 'bicycle=yes' oder/und 'bicycle=designated' implizieren

  • 'highway=footway' sollte 'foot=yes' oder/und 'foot=designated' implizieren

  • 'segregated=*' sollte bei gemeinsam genutzten Wegen immer gesetzt werden oder 'segregated=no' kann weggelassen werden

Ist das noch kontrovers? Beschwert sich z. B. heute noch jemand, wenn man bei einem gemeinsamen Geh-/Radweg mit Zeichen 240  das 'hw=cycleway' durch 'hw=path' ersetzt?

Hungerburg wrote:

Es muss da noch etwas Größeres dahinter stecken, das auszusprechen aber scheints nicht nur mir die Worte fehlen.

Das ist hier im Forum doch recht oft ein Thema. Das zeigt schon, dass es wichtig ist. Auch bedarf es Aufklärung, weil gerade beim Getrennt-Mappen viel falsch gemacht wird.

Grundsätzlich finde ich die Anleitungen der Berliner-Verkehrswendegruppe dafür sehr gut. Wenn man das Zusammenführen könnte, das wäre schön. Allerdings beschreiben die Berliner nur das Getrennt-Mappen, alles andere wird eher beiläufig erwähnt. Die anderen Taggingschemen sollten in der gleichen Qualität beschrieben werden. Auch deren Empfehlung widerstrebt mir zutiefst, für Gehsteige und Radwege getrennte Linien zu zeichnen.

Noch eine mögliche Baustelle im Wiki ... ich muss erstmal meine offenen Baustellen beenden.

Offline

#97 2022-01-09 00:35:05

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

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

Hungerburg wrote:

Das mit den Flächen, als eine Art Relation, für die keine Linien gesplittet werden müssen, die diverse Inhalte erfassen kann, ohne dass dafür eine neue Rolle erfunden werden müsste usw. Das wäre ein Hit.

Ich hatte auch schonmal überlegt, ob man beim Seperat-Mappen die kontinuierliche Querungsmöglichkeit über eine Fläche abbildet. Nur im Bereich der Querungsmöglichkeit ist die Fläche mit Radweg und Fahrbahn verklebt. Ein entsprechendes neues Attribut sagt aus, dass die Fläche nur eine abstrakte Übergangsmöglichkeit darstellt. Ggf. erhält die Fläche Attribute für Widerstände wie z.B. Bordsteinhöhen.

Es werden also nur die Flächen getaggt, die fürs Routing notwendig sind mit dem Ziel, bestimmte Linien in bestimmten Abschnitten miteinander zu verbinden. Das würde auch für das im Vortrag genannte Beispiel mit fußgängerrouting "nach rechts" helfen.

Das ist etwas Anderes, Abstrakteres, als das Abzeichnen der Fahrbahn und Radwegflächen von den Luftbildern, wie es im Flächentagging mitunter gemacht wird.

Allerdings ist es in OSM untypisch, logische Verknüpfungen zwischen den Linien über Flächen abzubilden. Das machen sonst immer Relationen.  Mit Relationen ist das aber nicht handhabbar. Es wäre eine Flut von Drei-Kanten-Relationen. Dass Radweg und Straße bei Beginn und Ende der kontinuierlichen Querungsmöglichkeit gesplittet werden müssten ist auch blöd.

Offline

#98 2022-01-09 23:22:30

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

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

dieterdreist wrote:

was relevante Hindernisse angeht, jeder Zaun und jede Mauer und Böschung, jedes Cliff und jeder Graben, etc. lückenlos und detailliert

Neukölln, deren "Karte" heut in der review gefeatured wurde, dort gehts in die Richtung. Ich bin immer wieder erstaunt, wofür Leute Interesse aufbringen. In meinen Augen ist die vorgestellte Ausarbeitung keine Karte, sondern ein Plan. Sie geht weit über das hinaus, was man als Stadtplan kennt. Von der Anmutung her ist das so etwas der Art, was Architekten aus den Plänen machen, die sie von den Bauherrn bekommen oder vom Tiefbauamt. Es muss im ArcGIS da einen Knopf dafür geben. Die Neuköllner erzeugen die Flächen aber aus Linien. Das ist trotzdem etwas ganz etwas anderes als eine Karte, wie OSM-Carto.

Hierbei zu tun, als sollte die ganze Welt dem nacheifern, das führt zu hypergemappten Mini-Inseln die an ihren Enden ausfransen, auf sehr sehr lange Zeit. Als lokales Projekt ist es aber recht gut gediehen. Immerhin werden sogar Radwege die als lane Attribut an der Straße erfasst sind als Flächen gerendert, was angeblich viel "post-processing" erfordert. Ich würde meinen, dass nun nicht mehr viel fehlt, mit sidewalks ebenso zu verfahren?

Ob sich die generierten Flächen für Routing weiterverwenden lassen? Selbst wenn eine Programmierstunde so viel kostet wie 100 Mapperstunden könnte sich das auszahlen.

Auch A/B-Street wurde erwähnt, das hat einen guten Fußrouter, aber die Herangehensweise ist eine ganz andere. Bei den einen geht es um ein statisches Abbild, der andere will Verkehr simulieren. Interessanterweise ist A/B Street mit Attributen viel besser bedient als mit separaten Ways. Hat auch ganz einen ganz anderen Begriff der "Straße". In Neukölln könnte ich meinen, die Straße ist der Raum, der zwischen den Landuse=Residential ausgespart ist. In A/B-Street ist die Straße ein multimodaler Verkehrsweg.

JochenB wrote:

Schwamm drüber!

Ich hab die Sammlung der Für und Wider im Detail durchgelesen. Das ist ein Arbeitspapier. Sehr fundiert. Aber mir fällt beim besten Willen nicht ein, wie das in den Radwege-Kartieren Artikel einfügen, obwohl die Angelegenheit dort sogar mehrfach angesprochen wird.

Offline

#99 2022-01-10 09:22:18

SafetyIng
Member
Registered: 2021-01-22
Posts: 463

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

Hungerburg wrote:

Die Neuköllner erzeugen die Flächen aber aus Linien. Das ist trotzdem etwas ganz etwas anderes als eine Karte, wie OSM-Carto.

In diesem Zusammenhang sollte man aber auch bedenken, wie die Neuköllner dort vorgehen: Dieses Rendering basiert nicht nur auf Linien, sondern auch auf Flächen. Hier werden massiv landuse=residential für den Renderer effektiv missbraucht. https://www.openstreetmap.org/#map=19/52.47845/13.43894
Diese werden genutzt um die Grenzen des Gehweges nachzuzeichnen....

Offline

#100 2022-01-10 09:43:28

streckenkundler
Member
From: Lübben (Spreewald)
Registered: 2012-08-09
Posts: 5,131
Website

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

Straßenraumkarte Neukölln...

Interessant...: https://supaplexosm.github.io/strassenr … 5/13.43815

Sven

Offline

Board footer

Powered by FluxBB