Routing / Spurmapping

Fabi2 · 2012-02-18 18:50:52

hurdygurdyman wrote:

Wir können nicht das eine wollen ohne auf das andere zu verzichten. Ich sehe da wenigstens keinen Weg.
Wir brauchen den engagierten Laien zum Erfassen mit einfachen Mitteln. Aber wir brauchen auch eine Datenbank zur professionellen Auswertung. Beides gleichzeitig wird mit dem OSM-Datenmodell immer schwieriger, wenn nicht sogar unmöglich
Ich will noch gar nicht daran denken, was mit meinem Ansatz passiert, wenn Brücken ins Spiel kommen. Bei railway und separated cycleway ist da die renderer-Fraktion schon höchst unzufrieden. Wie wollen wir die Realität darstellen, wenn wir in diesen Fällen viele Brücken statt einer real existierenden zeigen ?

Da habe ich noch den Ansatz eines abgerüsteten Schemas für Anfänger anzubieten, das ist zwar dann nicht semantisch korrekt, aber da kommt dann hoffentlich ein erfahrenerer Mapper vorbei und setzt die passende Relation auf die Einzelobjekte. Gut, eine wirkliche Lösung ist das auch nicht, eher eine Übergangslösung, außerdem entstehen da evtl. widersprüchliche Redundanzen bzw. muß extra Aufwand zur Löschung an den Einzelobjekten betrieben werden.

Das funktioniert dann so, das der Anfänger-Mapper z.B. eine Brücke mit bridge=yes + layer=1 an jedem Weg mappt und dann mal jemand hoffentlich die betroffenen einzelnen Brückenteilwege in eine gemeinsame Relation, für die Darstellung, das das nur eine Brücke ist, packt.

de_muur · 2012-02-20 07:54:26

Da die letzten Abschweifungen in Richtung Spuren-Als-Einzelne-Wege-Erfassen nichts neues zum Thema Routing erbracht haben, moechte ich noch mal die Variante Spuren-Als-Tags-Des-Weges-Erfassen hervorbringen.

Ein Punkt ist dabei, wie man die Verbindung der Spuren ueber eine Kreuzung hinweg am besten erfassen kann. Die meisten der letzten Vorschlaege (auch meiner) sehen vor, dass das ueber Tags geschehen soll aehnlich wie die Spurerfassung selber. Inzwischen bin ich der Meinung, dass dafuer doch Relationen das geeigentere Mittel sind:
- Letztendlich will man diese Informationen ja erfassen, damit ein Router die auch verwenden kann. Und fuer die automatische Auswertung ist es halt deutlich einfacher, wenn direkt in den Daten drin steht, welche Wege betroffen sind, als dass die Auswertung sich das erst ueber irgendwelche Lagedaten selber heraussuchen muesste. (Eine Kreuzung wird eigentlich nur ein mal erfasst, aber die Daten werden dann wieder und wieder ausgewertet.)
- Wirklich komplizierter ist die betreffende Relation ja auch nicht, vom Aufbau her entspricht sie ja einer Turn-Restriction., und da funktioniert es ja auch.
- Wenn man die Verbindungen ueber Relationen erfasst, dann erledigt man an dieser Stelle auch die interpretationsmoeglichkeit, ob die Verbindung in Weg-Richtung oder in Fahrt-Richtung zu erfassen sind.

Die meisten der letzten Vorschlaege sehen fuer die Erfassung eine Listennotation vor, bei der die Spuren mittels eines definierten Trennzeichens aufgezahelt werden. Daneben gab es haeufig auch eine Notation, mit der man auch einzelen Werte nur fuer eine bestimmte Spur setzen konnte. Aufgrund meiner Erfahrung mit den Beispielen auf der Uebersichtseite denke ich nun, dass man dazwischen auch noch teilweise gefuellte Listen zulassen sollte. D.h., wenn man fuer eine Spur keinen entsprechenden Wert setzen will, dann folgt da einfach Trennzeichen auf Trennzeichen. (Dieser Vorschlag ist auch schon von anderen gekommen, nur habe ich das bislang noch nie irgendwo ausformuliert/angewendet gesehen).

Die meisten der letzten Vorschlaege sehen fuer die Listennotation ein einfaches Aufzaehlen der Spuren von links nach rechts vor. Im Moment denke ich, dass es besser waere, wenn man die (logische) Strassenmitte dabei besonders hervorhebt. Bei den allermeisten Strassen trennt diese logische Mitte die Fahrtrichtungen oder wird von einer Spur gebildet die die Fahrt in beide Richtungen erlaubt (z.B. auf einspurigen Strassen). Wenn man diese Mitte besonders betont, erleichtert sich erstens die Erfassung der Fahrtrichtung der einzelnen Spuren (fast alle Faelle sind per Default erledigt). Zum anderen duerfte das die Auswertung erleichtern, wenn man z.B. wissen will, ob eine Strasse einen rechtsseitigen Radweg hat. realisieren liesse sich so eine Betonung, indem man in der Listennotation ein weiteres Trennzeichen einfuehrt und bei der einzelnen Identifikation der Spuren mit Vorzeichen arbeitet: Spuren mit negativem Vorzeichen sind links der Mitte, Spuren mit positiven Vorzeichen sind rechts der Mitte.

Gruss
Torsten

Last edited by de_muur (2012-02-20 07:55:05)

Tordanik · 2012-02-20 19:25:53

de_muur wrote:

Da die letzten Abschweifungen in Richtung Spuren-Als-Einzelne-Wege-Erfassen nichts neues zum Thema Routing erbracht haben, moechte ich noch mal die Variante Spuren-Als-Tags-Des-Weges-Erfassen hervorbringen.

Gut, ich halte diesen Ansatz derzeit mindestens kurz- bis mittelfristig für aussichtsreicher. Dass unter den tag-basierten Ansätzen die Listenvarianten am meisten versprechen, zeichnet sich allmählich auch ab.

Aufgrund meiner Erfahrung mit den Beispielen auf der Uebersichtseite denke ich nun, dass man dazwischen auch noch teilweise gefuellte Listen zulassen sollte. D.h., wenn man fuer eine Spur keinen entsprechenden Wert setzen will, dann folgt da einfach Trennzeichen auf Trennzeichen.

Das ist eine naheliegende und sinnvolle Ergänzung.

Die meisten der letzten Vorschlaege sehen fuer die Listennotation ein einfaches Aufzaehlen der Spuren von links nach rechts vor. Im Moment denke ich, dass es besser waere, wenn man die (logische) Strassenmitte dabei besonders hervorhebt. Bei den allermeisten Strassen trennt diese logische Mitte die Fahrtrichtungen oder wird von einer Spur gebildet die die Fahrt in beide Richtungen erlaubt (z.B. auf einspurigen Strassen). Wenn man diese Mitte besonders betont, erleichtert sich erstens die Erfassung der Fahrtrichtung der einzelnen Spuren (fast alle Faelle sind per Default erledigt). Zum anderen duerfte das die Auswertung erleichtern, wenn man z.B. wissen will, ob eine Strasse einen rechtsseitigen Radweg hat.

Ja, es könnte wirklich vorteilhaft sein, die Straßenmitte gesondert zu betonen. Die Defaults für die Fahrtrichtungen und die bessere Auswertbarkeit für Datennutzer, die z.B. nur an Radwegen interessiert sind, sind sehr gute Argumente.

Ich möchte allerdings auf einen alternativen Vorschlag für die praktische Umsetzung hinweisen. In Mailinglisten-Diskussionen wurde vorgeschlagen, man könnte für die beiden Straßen"hälften" zwei getrennte Listen anlegen (also so etwas wie lanes:direction:right = ... , ... , ...). Dadurch hätte man weiterhin nur eine Art von Trennzeichen und der Bedarf für "Vorzeichen" von Spuren würde ebenfalls wegfallen. Allerdings hat man dann doppelt so viele, wenn auch kürzere, Tags.

Fabi2 · 2012-02-20 21:47:06

Das mit denn Zusatztags wird bestimmt interessant, bei teilweise markierten Radspuren zum Beispiel, wie dem separated=yes-Radweg, der dann als Radspur auf die Straße mündet und an der nächsten Einengung der Straße ganz aufhört...

de_muur · 2012-02-21 07:35:00

Tordanik wrote:

Ich möchte allerdings auf einen alternativen Vorschlag für die praktische Umsetzung hinweisen. In Mailinglisten-Diskussionen wurde vorgeschlagen, man könnte für die beiden Straßen"hälften" zwei getrennte Listen anlegen (also so etwas wie lanes:direction:right = ... , ... , ...). Dadurch hätte man weiterhin nur eine Art von Trennzeichen und der Bedarf für "Vorzeichen" von Spuren würde ebenfalls wegfallen. Allerdings hat man dann doppelt so viele, wenn auch kürzere, Tags.

Da hatte ich auch dran gedacht, auf die Art ist das auch machbar. Im Moment scheint mir das aber die schlechterer Loesung zu sein, da es ja doch genug Faelle gibt, wo die Aufteilung in Rechts und Links alleine nicht ausreichend ist (z.B. alle Strassen mit nur einer Fahrspur). Das koennte man dann allerdings ueber eine dritte Kategorie (wie in etwa lanes:direction:middle=...) erfassen, was aber zu einer noch groessere Zergliederung führt. Ich denke, da wäre eine einzelne Liste uebersichtlicher. Wobei uebersichtlich da allgemein sehr relativ ist, a schoensten ist natuerlich eine graphische Eingabehilfe, so dass der Mapper von den daunter liegenden Datenstrukturen gar nichts mitbekommt.

Fabi2 wrote:

Das mit denn Zusatztags wird bestimmt interessant, bei teilweise markierten Radspuren zum Beispiel, wie dem separated=yes-Radweg, der dann als Radspur auf die Straße mündet und an der nächsten Einengung der Straße ganz aufhört...

Das Thema, wie detailliert man mappen will, hat man immer, unabhaengig vom gewaehlten Tagging-Schema. Oben genanntes Beispiel wird bei kleinlichem Tagging zu einer extremen Zerstueckelung der Strasse fuehren. Aber was waere die Alternative? Wenn man das als einzelne Wege erfassen wuerde, dann muesste man das doch genauso zerstueckeln und dann die Einzelteile jedes Abschnittes jeweils in einer Relation wieder zusammen fassen.

Gruss
Torsten

hurdygurdyman · 2012-02-23 09:20:56

Da Bilder mehr als 1000 Worte sagen habe ich zu meinem Lösungsansatz aus post http://forum.openstreetmap.org/viewtopi … 52#p221552, den ich hier http://wiki.openstreetmap.org/w/images/ … ansatz.pdf als Text beschrieben habe noch eine grafische Darstellung gebastelt:

http://wiki.openstreetmap.org/w/images/ … afisch.pdf

Vielleicht wird zu meinem Ansatz so einiges klarer im Bezug auf die Verwendung/Auswertung zum routen. Ich halte nichts vom Aufzählungen/Listen in values wegen der Intransparenz und Nachbearbeitung. Nach wie vor ist mir nicht klar, wie das ein router verarbeiten soll.

Da der Mensch ein optisch orientiertes Wesen ist, halte ich das mappen einzelner Spuren für die bessere Lösung. Ich habe vesucht, ein Schema zu entwickeln, dass ähnlich arbeitet wie Relationen, aber noch ohne diese auskommt. Das Problem dabei sind die Linienbündel, für die man dann aber den (ungeliebten) Weg über Relationen verwenden könnte :/

Ich bitte um Meinungen zur Verwendbarkeit als Mapper und zum routing. Auch Änderungsvorschläge sind willkommen. Sollte sich herausstellen, dass das schon im Ansatz alles nur Mist ist, werde ich mich wohl von der Idee verabschieden.

SunCobalt · 2012-02-23 09:39:15

wozu sind die lane_restrictions auf Seite 5 in der graphischen Darstellung, wenn Du auf Seite 6 das gleiche mit dem Spinnennetz im Kreuzungsbereich darstellst?

hurdygurdyman · 2012-02-23 09:56:02

SunCobalt wrote:

wozu sind die lane_restrictions auf Seite 5 in der graphischen Darstellung, wenn Du auf Seite 6 das gleiche mit dem Spinnennetz im Kreuzungsbereich darstellst?

Ich weiß, dass ist doppelt gemoppelt. Aber einerseits dient es dem Renderer, um für das entsprechende lane die Richtungspfeile oder das entsprechende Verkehrschild einzublenden, andererseits denke ich, dass es für vorausschauendes routing Sinn macht. Weiterhin könnte eine automatisierte Qualitätskontrolle checken, ob die vom entsprechenden lane ausgehenden lane=junction vollständig und richtig sind. Ich befürchte nämlich, dass von den lane=junction je nach Komplexität schnell mal eins vergessen wird, weil die ja in der Realität nicht sichtbar sind und nur benötigt werden, weil routing über Flächen nicht möglich ist.
Ich hatte auch mal kurz daran gedacht, die lane=junction wegzulassen und dann dem router die Aufgabe zu überlassen, automatisiert die Möglichkeiten der Verbindungen über die lane_junction-Fläche zu generieren, was mapping natürlich vereinfachen würde. Aber dann habe ich mich entschlossen, dem router die Arbeit zu erleichtern.

Last edited by hurdygurdyman (2012-02-23 09:56:40)

SunCobalt · 2012-02-23 10:12:41

ich sag mal so. Das ganze sieht ziemlich unübersichtlich aus, was aber wohl nicht zu vermeiden ist. Daher würde ich es gut finden, wenn alle nur für diesen Zweck benötigten Objekte einen identischen Tag haben. Damit kann man das auf Knopfdruck ausblenden wenns einen stört.

Als Extrembeispiel könntest Du ja das hier nehmen
https://maps.google.de/maps?q=Gro%C3%9F … n&t=k&z=17

Mir gefällt Deine Art, die Dinge zu visualisieren Da kann man sich gleich mehr drunter vorstellen als bei einem ellenlangen Text

hurdygurdyman · 2012-02-23 10:47:33

SunCobalt wrote:

ich sag mal so. Das ganze sieht ziemlich unübersichtlich aus, was aber wohl nicht zu vermeiden ist. Daher würde ich es gut finden, wenn alle nur für diesen Zweck benötigten Objekte einen identischen Tag haben. Damit kann man das auf Knopfdruck ausblenden wenns einen stört.

Deswegen habe ich für alle expliziten ways oder nodes als key "lane" gewählt ( siehe http://wiki.openstreetmap.org/w/images/ … ansatz.pdf , Seite 3). Ausnahme ist lane_junction für die Kreuzungsfläche. Das dürfte aber auch kein Problem geben.

Als Extrembeispiel könntest Du ja das hier nehmen
https://maps.google.de/maps?q=Gro%C3%9F … n&t=k&z=17

Gute Idee. Da lege ich dann aber ein bing-Bild in den Hintergrund. Irgendwo habe ich auch mal eine recht komplexe Kreuzung in Wien gesehen, die sich eignen könnte. Und ein Autobahnkreuz oder so will ich mir auch noch vornehmen, an dem man mit lane_direction probieren könnte.

Mir gefällt Deine Art, die Dinge zu visualisieren Da kann man sich gleich mehr drunter vorstellen als bei einem ellenlangen Text

Danke für das Kompliment. Macht zwar erst mal Arbeit, spart dann aber tausend Erklärungen.

SunCobalt · 2012-02-23 11:02:52

hurdygurdyman wrote:

Als Extrembeispiel könntest Du ja das hier nehmen
https://maps.google.de/maps?q=Gro%C3%9F … n&t=k&z=17
Gute Idee. Da lege ich dann aber ein bing-Bild in den Hintergrund. Irgendwo habe ich auch mal eine recht komplexe Kreuzung in Wien gesehen, die sich eignen könnte.

die hier?
https://maps.google.de/maps?q=Praterste … h&t=k&z=17
bzw bei Bing
http://binged.it/yUyLUy

Da sieht man die Pfeile auf der Straße nicht so gut

hurdygurdyman · 2012-02-23 11:15:33

SunCobalt wrote:

die hier?
https://maps.google.de/maps?q=Praterste … h&t=k&z=17
bzw bei Bing
http://binged.it/yUyLUy
Da sieht man die Pfeile auf der Straße nicht so gut

In Wien dachte ich an :
http://www.bing.com/maps/?v=2&cp=48.212 … ich&obox=1
Da könnte man dann sogar die westlichen Brücken zu einem Rundkurs zusammenflicken. Dein Vorschlag ist auch eher ein Kreisverkehr
Wie gesagt: ich würde das Luftbild hinterlegen, was Arbeit spart, und da ist Google ja wohl außen vor

Jimmy_K · 2012-02-23 11:40:33

Die Lösung sieht einleuchtend aus. Auf die komplizierteren Beispiele bin ich gespannt, ich hoffe "dein" System schafft das.

Der vorgeschlagene Wiener Praterstern, sieht komplizierter aus, als er ist. Sind meistens 3-4 Fahrstreifen und 1-2 gehen davon seitlich ab, glaube ich ist nicht viel komplexer, als der Berliner Vorschlag. Die Frage ist nur, was man mit Busspuren und Bimgleisen macht? Vom System komplett ausnehmen, solange sie nicht parallel zur Straße verlaufen?

Last edited by Jimmy_K (2012-02-23 11:43:19)

hurdygurdyman · 2012-02-23 11:52:57

Das wäre bei unseren britischen Freunden doch schön
http://www.bing.com/maps/?v=2&where1=Br … &encType=1
und nebenan:
http://www.bing.com/maps/?v=2&cp=48.218 … Q1NzI0NQ==

hurdygurdyman · 2012-02-23 12:23:24

Jimmy_K wrote:

Die Lösung sieht einleuchtend aus. Auf die komplizierteren Beispiele bin ich gespannt, ich hoffe "dein" System schafft das.
Der vorgeschlagene Wiener Praterstern, sieht komplizierter aus, als er ist. Sind meistens 3-4 Fahrstreifen und 1-2 gehen davon seitlich ab, glaube ich ist nicht viel komplexer, als der Berliner Vorschlag. Die Frage ist nur, was man mit Busspuren und Bimgleisen macht? Vom System komplett ausnehmen, solange sie nicht parallel zur Straße verlaufen?

Separate Busspuren bekommen lane=psv. Bimgleise (Hochdeutsch=Straßenbahngleise) laufen unter "konkurrierender Verkehr", den ich nicht mit lane=xy taggen will, da dies nichts mit dem ersten Ziel, das spurabhängige routing zu ermöglichen, zu tun hat. Straßenbahnen laufen als railway=tram wie bisher weiter. Wichtig erscheint mir dabei aber, die höhengleichen Kreuzungen auch auf lane=* zu markieren, damit sie als Hindernis ausgewertet werden können.

Last edited by hurdygurdyman (2012-02-23 12:24:41)

Fabi2 · 2012-02-23 23:14:24

hurdygurdyman wrote:

http://wiki.openstreetmap.org/w/images/ … afisch.pdf
Vielleicht wird zu meinem Ansatz so einiges klarer im Bezug auf die Verwendung/Auswertung zum routen. Ich halte nichts vom Aufzählungen/Listen in values wegen der Intransparenz und Nachbearbeitung. Nach wie vor ist mir nicht klar, wie das ein router verarbeiten soll.
Da der Mensch ein optisch orientiertes Wesen ist, halte ich das mappen einzelner Spuren für die bessere Lösung. Ich habe vesucht, ein Schema zu entwickeln, dass ähnlich arbeitet wie Relationen, aber noch ohne diese auskommt. Das Problem dabei sind die Linienbündel, für die man dann aber den (ungeliebten) Weg über Relationen verwenden könnte
Ich bitte um Meinungen zur Verwendbarkeit als Mapper und zum routing. Auch Änderungsvorschläge sind willkommen. Sollte sich herausstellen, dass das schon im Ansatz alles nur Mist ist, werde ich mich wohl von der Idee verabschieden.

Der Ansatz ist absolut nicht Mist, sieht fast aus wie eine unötig komplizierte Version von meiner Grobidee, die ich schon hier und heute noch mal unter http://wiki.openstreetmap.org/wiki/Talk … s_features beschrieben habe.

Weil wenn man an Spuren die wie in deinem Schema mit dem alten Highways verbunden sind und dann z.B. wie folgt getaggt werden:

lane=yes
foot:all=yes
bicycle:all=yes
motor_vehicle:forward=yes
motor_vehicle:backward=no
motor_vehicle:left=yes
motor_vehicle:right=no

...und die Lanes dann nur dort gemeinsame Knotenpunkte haben, wo auch ein Einbiegen auf die andere Spur möglich ist, hat sich das Abbiegebeschränkungsproblem und auch access-Problem dann hoffentlich in den meisten Fällen ganz schnell erledigt.

Dann will der Autorouter ja bestimmt "seine Straße" haben, weshalb ich dann eine Relation für die Lanes machen würde, wo der alte highway=* mit passender Rolle, der Straßentyp entsprechend dem highway=* für die Lanes und die lane=yes-Objekte, die die Fahrbahn bilden, drin sind.

Dann braucht man ja noch die "Straße" für die "der Sidewalk gehört aber mit zur Straße"-Fraktion, wo dann alles drin sein kann, was zur "Straße" (im Sinne der Fahrbahn bzw. des jetzigen highway-Weges) gehört ("straßenbegleitende" Fuß-/Radwege (die auch nur lane=yes-Objekte mit anderem "access"-Tags nach obigem Schema sind), Laternen, Ampeln oder sonstwas...) und wo dann auch der name=* mit rein kommt.

Alte Anwendungen interessieren sich für die lane=yes-Wege und die Relationen dann hoffentlich nicht weiter und benutzen nur den (anfänglich redundanten) alten highway=*, womit das Rückwärtskompatibilitätsproblem gelöst wäre.

Last edited by Fabi2 (2012-02-23 23:48:16)

Fabi2 · 2012-02-23 23:21:59

Noch 'ne Anmerkung: Es ist im Endeffekt doch egal, ob man als Autfahrer nicht nach links fahren kann, weil da eine Sperrlinie oder -fläche ist oder man sich bei einer einspurigen Straße dann im Straßengraben wiederfindet. Dann sollte man für bestimmte Objektypen evtl. noch sillvolle Defasultwerde definieren, damit man nicht so viel taggen muß und fertig!

de_muur · 2012-02-24 10:16:03

hurdygurdyman wrote:

Da Bilder mehr als 1000 Worte sagen

Das ist dein Denkfehler: Dir als Mensch sagen die Bilder mehr, ein Router hat aber kein solches Sehverstaendnis. Fuer ihn sind solche visuellen Darstellungen komplett unbrauchbar. Wenn du nachvollziehen willst, mit welchen Daten ein Router zurechtkommen muss, dann mal deine Beispielkreuzung mal in JOSM auf, speicher die als OSM-Datei ab und schau dir dann diese OSM-Datei im Texteditor an. Du wirst sehen, dass du nichts siehst, und das wird einem Router genauso gehen.

Wenn man entsprechend deinem Vorschlag fleissig einzelne Wege fuer die Spuren eintraegt, und ist das eine reine Beschaeftigungstherapie fuer die Mapper (als ob du zuhause ein Puzzle machst): Du verbringst deine Freizeit damit und kannst es dir angucken und dich freuen, wie viel du geschafft hast. Aber irgendein Nutzen (Routing) wird daraus nicht erwachsen.

Ich halte nichts vom Aufzählungen/Listen in values wegen der Intransparenz und Nachbearbeitung. Nach wie vor ist mir nicht klar, wie das ein router verarbeiten soll.

Solche Listen lassen sich ganz einfach visualisiseren, damit du als Mapper (als Mensch) sie leichter nachvollziehen kannst: Momentan zeichnet ein Mapping-Editor (z.B. JOSM) eine Linien fuer einen Weg und faerbt diese entsprechend der in den Tags enthaltenen Werte ein. Genauso wie das Einfaerben funktioeniert, kann entsprechend irgendwelcher Lane-Listen auch das Aussehen der Linie angepasst werden: Wenn da eine Lane enthalten ist, wird eine einfache Linie gemalt, bei zwei Lanes dann zwei Linien nebeneinender usw.
Aus den Tag-Listen eine Visualisierung zu bauen ist trivial. Aus einer visuellen Darstellung aber umgekehrt eine Tag-Liste zu generieren ist extrem aufwendig, in aller Allgemeinheit praktisch unmoeglich.

Gruss
Torsten

hurdygurdyman · 2012-02-25 08:54:25

de_muur wrote:

hurdygurdyman wrote:
Da Bilder mehr als 1000 Worte sagen
Das ist dein Denkfehler: Dir als Mensch sagen die Bilder mehr, ein Router hat aber kein solches Sehverstaendnis.

Da drehst du meine Aussage um. Die Bilder http://wiki.openstreetmap.org/w/images/ … afisch.pdf dienen dazu, das von mir vorgeschlagene Schema für den Menschen verständlich optisch umzusetzen.

Fuer ihn sind solche visuellen Darstellungen komplett unbrauchbar. Wenn du nachvollziehen willst, mit welchen Daten ein Router zurechtkommen muss, dann mal deine Beispielkreuzung mal in JOSM auf, speicher die als OSM-Datei ab und schau dir dann diese OSM-Datei im Texteditor an. Du wirst sehen, dass du nichts siehst, und das wird einem Router genauso gehen.

Meines Wissens bilden Router gerichtete Graphen über Knoten und Kanten. Diese stellt ihnen mein Vorschlag in den lane=* genau wie ansonsten highway=* zur Verfügung. Wo ist das Problem? Der Router muss doch lediglich eine Regel befolgen, die lane=* priorisiert, wenn als Alternative highway=* besteht.

Solche Listen lassen sich ganz einfach visualisiseren, damit du als Mapper (als Mensch) sie leichter nachvollziehen kannst: Momentan zeichnet ein Mapping-Editor (z.B. JOSM) eine Linien fuer einen Weg und faerbt diese entsprechend der in den Tags enthaltenen Werte ein. Genauso wie das Einfaerben funktioeniert, kann entsprechend irgendwelcher Lane-Listen auch das Aussehen der Linie angepasst werden: Wenn da eine Lane enthalten ist, wird eine einfache Linie gemalt, bei zwei Lanes dann zwei Linien nebeneinender usw.
Aus den Tag-Listen eine Visualisierung zu bauen ist trivial. Aus einer visuellen Darstellung aber umgekehrt eine Tag-Liste zu generieren ist extrem aufwendig, in aller Allgemeinheit praktisch unmoeglich.

Hast du dir die entsprechende mit JOSM erzeugte OSM-Datei auch mal im Texteditor angeschaut

Jimmy_K · 2012-03-06 16:09:33

Da es auf der Mailingliste gerade halbwegs aktiv ist das Thema, hier ein Link:
http://rfmtc.no-ip.org/osm/austrox/?zoo … 4&layers=B

Irgendwie fehlt bei vielen Schemen, wie man es tagged, wenn sich von 3 Spuren die mittlere teilt und dann jeweils 2 Fahrstreifen in eine andere Richtung gehen. (siehe oben)
Ich fürchte, man kommt ohne gezeichnete Lanes auf einer Autobahn und bei größeren Kreuzungen nicht weiter.

@hurdygurdyman
Hast du schon erfolgreich versucht, dein Schema auf die großen Kreuzungen anzuwenden?

chris66 · 2012-03-06 16:59:01

Eine einfache Lösung ist noch nicht in Sicht.
http://comments.gmane.org/gmane.comp.gi … n.de/92732

Fabi2 · 2012-03-06 18:01:34

Jimmy_K wrote:

Irgendwie fehlt bei vielen Schemen, wie man es tagged, wenn sich von 3 Spuren die mittlere teilt und dann jeweils 2 Fahrstreifen in eine andere Richtung gehen. (siehe oben)
Ich fürchte, man kommt ohne gezeichnete Lanes auf einer Autobahn und bei größeren Kreuzungen nicht weiter.

Kommt man sowieso nicht, weil dieser Fall den du hier anführst wird nicht der Einzige bleiben, einfach schon prinzipbedingt! Bin mal gespannt, wann man zu der Einsicht kommen wird, das man eine Spur als Abstraktion nur in vier Richtungen befahren kann (vor, zurück, links, rechts) und das es egal ist, ob man den logischen oder physischen (Asphalt)streifen jetzt Radweg, Fußweg oder Fahrspur nennt. Genug Hinweise wie man es besser machen kann, hab ich ja hier und in den Proposal'n gepostet, also kann ich mir jetzt Popcorn holen gehen. Ausarbeiten tue ich das nicht weiter, da habe ich einfach zu wenig Interesse an den Spuren. Den Routern kann man sinvvolle Datenreduktions- und Abstraktionsmechanismen beibringen, was das Schema naurlich durch passende Infos unterstützen sollte.

hurdygurdyman · 2012-03-07 12:25:31

Jimmy_K wrote:

...
@hurdygurdyman
Hast du schon erfolgreich versucht, dein Schema auf die großen Kreuzungen anzuwenden?

Ich war leider in letzter Zeit mit anderen Dingen stark ausgelastet, sodass ich da nicht viel machen konnte
Aber kurz zu meinem Stand:
Ich habe versucht, mir Wissen zu dem Thema aus Sicht des routings anzueignen. Bin da aber noch nicht ganz fertig.
Als Testgegend habe ich Freiburg (Brsg) ausgeguckt. Die Gründe dafür:
- Hochauflösende Bilder von Aerowest aus 2009 sind vorhanden.
- Das "Freiburgschema" zeichnet dort schon umfangreich Spuren unter großzügiger Auslegung von highway=*
http://www.openstreetmap.org/edit?lat=4 … 49&zoom=18
http://www.openstreetmap.org/edit?lat=4 … 42&zoom=18
- Ich kenne mich da einigermaßen aus.

Ich werde mir da ein paar Ecken für JOSM zum offline-bearbeiten herunterladen und die Aerowest-Bilder dazupacken, um meinen täglichen Zugfahrten zur Arbeit mit sinnvollen Dingen zu füllen.
Ziel des ganzen sollte dann eine Testumgebung sein, in der dann erfahrene Renderer und Router mit den Daten spielen können. Deren feedback anhand konkreter Beispiele ist mir wichtig. Anschließend sollten die Erfahrungen in das Schema einfließen.

Bitte habt noch etwas Geduld. Ich will hier nichts über's Knie brechen.

chris66 wrote:

Eine einfache Lösung ist noch nicht in Sicht.
http://comments.gmane.org/gmane.comp.gi … n.de/92732

Interessante Diskussion, die mich bestärkt, weiterzumachen.

Last edited by hurdygurdyman (2012-03-07 12:28:28)

hurdygurdyman · 2012-03-07 14:35:39

Jimmy_K wrote:

...
Irgendwie fehlt bei vielen Schemen, wie man es tagged, wenn sich von 3 Spuren die mittlere teilt und dann jeweils 2 Fahrstreifen in eine andere Richtung gehen. (siehe oben)
Ich fürchte, man kommt ohne gezeichnete Lanes auf einer Autobahn und bei größeren Kreuzungen nicht weiter.

Dazu habe ich eine vage Idee
linke Spur: lane_restriction=left_ahead
mittlere Spur: lane_restriction=split_ahead
rechte Spur: lane_restriction=right_ahead

Das entspräche für die äußeren Spuren etwa dem:
http://de.wikipedia.org/w/index.php?tit … 0126153005

Für das Teilen der mittleren Spur habe ich keinen Markierungspfeil gefunden.

Last edited by hurdygurdyman (2012-03-07 14:36:13)

aighes · 2012-03-07 14:50:44

Das sich die mittlere Spur aufteilt hab ich noch nie gesehen...gibts sowas in der Realität? Entweder kommt doch links oder rechts eine Spur hinzu bzw. fällt weg.

Last edited by aighes (2012-03-07 14:51:22)

Announcement

#251 2012-02-18 18:50:52

Re: Routing / Spurmapping

#252 2012-02-20 07:54:26

Re: Routing / Spurmapping

#253 2012-02-20 19:25:53

Re: Routing / Spurmapping

#254 2012-02-20 21:47:06

Re: Routing / Spurmapping

#255 2012-02-21 07:35:00

Re: Routing / Spurmapping

#256 2012-02-23 09:20:56

Re: Routing / Spurmapping

#257 2012-02-23 09:39:15

Re: Routing / Spurmapping

#258 2012-02-23 09:56:02

Re: Routing / Spurmapping

#259 2012-02-23 10:12:41

Re: Routing / Spurmapping

#260 2012-02-23 10:47:33

Re: Routing / Spurmapping

#261 2012-02-23 11:02:52

Re: Routing / Spurmapping

#262 2012-02-23 11:15:33

Re: Routing / Spurmapping

#263 2012-02-23 11:40:33

Re: Routing / Spurmapping

#264 2012-02-23 11:52:57

Re: Routing / Spurmapping

#265 2012-02-23 12:23:24

Re: Routing / Spurmapping

#266 2012-02-23 23:14:24

Re: Routing / Spurmapping

#267 2012-02-23 23:21:59

Re: Routing / Spurmapping

#268 2012-02-24 10:16:03

Re: Routing / Spurmapping

#269 2012-02-25 08:54:25

Re: Routing / Spurmapping

#270 2012-03-06 16:09:33

Re: Routing / Spurmapping

#271 2012-03-06 16:59:01

Re: Routing / Spurmapping

#272 2012-03-06 18:01:34

Re: Routing / Spurmapping

#273 2012-03-07 12:25:31

Re: Routing / Spurmapping

#274 2012-03-07 14:35:39

Re: Routing / Spurmapping

#275 2012-03-07 14:50:44

Re: Routing / Spurmapping

Board footer