Routing / Spurmapping

viw · 2012-02-14 09:31:34

hurdygurdyman wrote:

Warum konzentrieren wir uns nicht auf das Thema dieses threads "Routing und Spurmapping", welches in der Masse der Fälle nur Straßen (und selten auch Radwege) betrifft. Mir ist eine Lösung für 80-95 % der Fälle lieber als für 100 % keine Lösung.

Warum? Weil sonst immer andere Dinge passieren werden:
http://www.openstreetmap.org/?lat=48.14 … 8&layers=M

Das hat mich doch echt gewundert wie hier in der Dachauer Straße zwei Straßenbahngleise gezeichnet werden konnten. Und genau das wird dir nachher dein schönes Schema zerstören. Denke ich jedenfalls. Im Gegensatz zu einem reinen Autonavi ist OSM eben für alle da. Sogar Fahrradfahrer und Straßenbahnbenutzer. Der Anspruch geht sogar noch weiter. Auch blinde Menschen sollen alle relevanten Informationen finden. Wie bitte soll das bewerkstelligt werden?

Ich möchte gerne noch diese schon ältere Wikiseite ins Rennen werfen:
http://wiki.openstreetmap.org/wiki/DE:W … ir_routing

Ich hoffe ihr könnt erahnen was diese Spezifikation für Auswirkungen auf die Daten haben würde, wenn sie wirklich konsequent umgesetzt werden würden. Aber das rede ich ja auch schon viel zu lange.

hurdygurdyman · 2012-02-14 12:00:31

viw wrote:

Warum? Weil sonst immer andere Dinge passieren werden:
http://www.openstreetmap.org/?lat=48.14 … 8&layers=M
Das hat mich doch echt gewundert wie hier in der Dachauer Straße zwei Straßenbahngleise gezeichnet werden konnten. Und genau das wird dir nachher dein schönes Schema zerstören. Denke ich jedenfalls. Im Gegensatz zu einem reinen Autonavi ist OSM eben für alle da. Sogar Fahrradfahrer und Straßenbahnbenutzer. Der Anspruch geht sogar noch weiter. Auch blinde Menschen sollen alle relevanten Informationen finden. Wie bitte soll das bewerkstelligt werden?
Ich möchte gerne noch diese schon ältere Wikiseite ins Rennen werfen:
http://wiki.openstreetmap.org/wiki/DE:W … ir_routing
Ich hoffe ihr könnt erahnen was diese Spezifikation für Auswirkungen auf die Daten haben würde, wenn sie wirklich konsequent umgesetzt werden würden. Aber das rede ich ja auch schon viel zu lange.

Also geht es doch um die eierlegende Wollmilchsau für den dümmsten anzunehmenden Mapper.
Fange ich mal hinten an:
Renderer setzen Informationen optisch um und suchen sich je nach Zielsetzung und Genauigkeit die passenden Daten in OSM dazu. Je nach Zoom-Level wird generalisiert. Router hingegen können ohne grafische Darstellung anhand der Daten den geeigneten Weg berechnen und darstellen.
Nach umfangreichem Studium vieler Vorschläge und Überlegungen in der Wiki denke ich über eine Lösung nach, die durch
http://wiki.openstreetmap.org/wiki/Wiki … %C3%BCndel
und hier speziell das Fazit von Tordanik angeregt wurde.
Es wird ein neuer key lane=* eingeführt. Sobald mehrere Spuren mit verschiedenen Eigenschaften eines highway=* vorhanden sind und der Wechsel zwischen diesen für Verkehrsteilnehmer physisch möglich ist, werden entsprechende lane=* parallel zum highway angelegt, was bei hochauflösenden Bildern als Grundlage möglich wird. Diese lane=* können mit entsprechenden Zusatz-tags genau wie highway=* versehen werden, um weitere Eigenschaften zu definieren.

Somit steht es den Renderern frei, je nach Zielsetzung oder Generalisierung die für sie wichtigen Informationen aus highway und/oder lane herauszulesen. Router können Informationen aus highway und lane je nach Bedürfnis und Verkehrsmittel verwenden.

Dies ist momentan noch ein Gedankenspiel, das ich noch an Beispielen testen und verfeinern muss. Die Straßenbahn auf der Dachauer Straße wäre außen vor, weil kein physischer Spurwechsel möglich/erlaubt ist Aber ich bin gespannt auf eure Argumente, weshalb das nicht gehen soll

Last edited by hurdygurdyman (2012-02-14 12:17:31)

viw · 2012-02-14 14:04:36

hurdygurdyman wrote:

Dies ist momentan noch ein Gedankenspiel, das ich noch an Beispielen testen und verfeinern muss. Die Straßenbahn auf der Dachauer Straße wäre außen vor, weil kein physischer Spurwechsel möglich/erlaubt ist

Das musst du mir jetzt nochmal genauer erläutern. Wie würdest du die Straßenbahn auf der Dachauerstraße in deinem System erfassen? Als zwei Spuren oder als zwei Highways?

Falls du zu einer Linie tendierst mag ich dir kurz das Problem erläutern:
http://www.openstreetmap.org/?lat=51.03 … 8&layers=M

http://maps.google.de/?ll=51.03529,13.8 … 9,,0,31.33

Wie willst du also kenntlich machen aus welchem Gleis man hier abzweigen darf. Die Idee mit Einbahnstraßen kannst du gleich verwerfen. Dies sind keine Einbahnstraßen. Sie werden in beiden Richtungen befahren mal vorwärts mal rückwärts. Sowie es der Betrieb erfordert. Früher noch häufiger als heute.

Auch diese Stelle kann man nach deinem Modell nur schwer nachbilden: http://maps.google.de/?ll=51.038477,13. … .19,,0,2.3

Bedenke insbesondere die Abgrenzung zu diesem Beispiel hier:
http://maps.google.de/?ll=51.113357,13. … 3,,0,-3.34

Beim ersten ist nämlich mit der Straßenbahn im Gegenverkehr zu rechnen, während beim zweiten die Straßenbahn in Mittellage von beiden Fahrspuren recht unabhängig fährt und die Gleise zum überholen verwendet werden können.

hurdygurdyman · 2012-02-14 14:52:52

viw wrote:

Das musst du mir jetzt nochmal genauer erläutern. Wie würdest du die Straßenbahn auf der Dachauerstraße in deinem System erfassen? Als zwei Spuren oder als zwei Highways?
...

Das ist doch einfach. Solltest du meine Idee genau gelesen haben geht es um Spuren als Bestandteil von highway=*. Straßenbahn ist railway=tram. In den von dir gezeigten Beispielen handelt es sich um konkurrierende Verkehrssysteme auf der gleichen Fläche. Die ways überlagern sich. Den railway=tram zeichne ich somit als selbstständigen way über die Straße. Das hat mit den lane=* des highway nichts zu tun.

Weiterhin gehe ich davon aus, dass Straßenbahnen als Schienensystem keine routing-Informationen aus OSM beziehen und niemals beziehen werden, da die Weichen durch andere technische Eingriffe gestellt werden. Sollte es um die Abbildung von Straßenbahnlinien gehen, kann man das über die bekannten Relationen lösen.

Edit:
Ich habe mir mal die Königsbrücker Landstraße angeschaut:
http://www.openstreetmap.org/?lat=51.11 … 8&layers=M
Dort sind highway=secondary und railway=tram auf dem gleichen way gemappt und somit auch konkurrierend.

Last edited by hurdygurdyman (2012-02-14 15:04:23)

viw · 2012-02-14 15:28:55

hurdygurdyman wrote:

viw wrote:
Das musst du mir jetzt nochmal genauer erläutern. Wie würdest du die Straßenbahn auf der Dachauerstraße in deinem System erfassen? Als zwei Spuren oder als zwei Highways?
...
Das ist doch einfach. Solltest du meine Idee genau gelesen haben geht es um Spuren als Bestandteil von highway=*. Straßenbahn ist railway=tram. In den von dir gezeigten Beispielen handelt es sich um konkurrierende Verkehrssysteme auf der gleichen Fläche. Die ways überlagern sich. Den railway=tram zeichne ich somit als selbstständigen way über die Straße. Das hat mit den lane=* des highway nichts zu tun.
Weiterhin gehe ich davon aus, dass Straßenbahnen als Schienensystem keine routing-Informationen aus OSM beziehen und niemals beziehen werden, da die Weichen durch andere technische Eingriffe gestellt werden. Sollte es um die Abbildung von Straßenbahnlinien gehen, kann man das über die bekannten Relationen lösen.
Edit:
Ich habe mir mal die Königsbrücker Landstraße angeschaut:
http://www.openstreetmap.org/?lat=51.11 … 8&layers=M
Dort sind highway=secondary und railway=tram auf dem gleichen way gemappt und somit auch konkurrierend.

Es geht mir nicht darum, wie es jetzt gemacht ist, sondern wie es in Zukunft gemacht werden soll. Du würdest also mit deinem Beispiel sagen, dass obwohl die Straßenbahn auf der Straße fährt lieber zwei Gleise einzeichnen und dann die Straße als highway in die Mitte legen. Gerade das Beispiel zwei an der Ludwig-Hartmann-Straße ist denke ich nicht unrelevant fürs Routing. Denn Ob mir auf meiner Fahrspur eine Straßenbahn entgegenkommt oder ob die wie in Nürnberg neben der Straße fährt ist denke ich ein entscheidender Unterschied. Oder nicht?

Auch habe ich noch nicht verstanden, wie du dann die vielen Linien lane=* dann einem highway=* zuordnen möchtest. Eventuell könnte das aber notwendig sein. Wenn wir uns an die Anfänge von navis erinnern, wo die nicht unterscheiden konnten ob man auf der Autobahn oder der Straße daneben fährt.
Das zweite interessante Kriterium ist bei dir dass hier Lanes angelegt werden solange man physisch dazwischen hin und her wechseln kann. Wie willst du damit dies hier abbilden:
http://maps.google.de/?ll=51.060083,13. … .58,,0,4.1

Aber auch die Stelle scheint mir interessant zu sein: http://maps.google.de/?ll=51.041718,13. … 6.89,,0,-4
Vor allem in Hinblick auf die Fußwege. Kann man hier nun die Straße überqueren oder nicht der Autofahrer kann jedenfalls die Spur nicht wechseln.

Last edited by viw (2012-02-14 15:34:14)

hurdygurdyman · 2012-02-14 15:50:25

@viw:
Bevor ich mir jetzt hier die Finger wund tippe, werde ich deine Fragen in Ruhe bedenken.
Ich sagte, es sei ein Denkansatz, und danke dir für deine Problemkandidaten zur Anregung meines Hirnschmalzes.

Lasst mich jetzt erst mal basteln. Ich melde mich dann wieder, bin aber für weitere Anregungen und Kritiken offen.

viw · 2012-02-14 16:08:52

Hier habe ich doch noch was für dich. Wie möchtest du das http://maps.google.de/?ll=52.441773,13. … 6,,0,12.31

von dem http://maps.google.de/?ll=48.143315,11. … =12,0,,0,0 unterscheiden.

Du malst den highway in die Mitte und dann links und rechts die Straßenbahn. Die hat aber keinen Bezug zum highway.
Solltest du die Straßenbahn auf die Fahrspur legen, dann bedenke die Königsbrücker Straße ab dem 30er Schild. Dort sind dann plötzlich zwei Gleise in der Mitte. Es gibt dann also keine Mittelspur mehr und nur noch halbe Spuren neben den Straßenbahngleisen.

errt · 2012-02-14 16:22:05

Ich würde dazu tendieren, im Falle der Königsbrücker Landstraße drei parallele Wege zu erfassen, einmal den Highway (+ eventuell Lane für die Mittelspur) in der Mitte und dann zwei Lanes rechts und links davon. Vor dem 30er Schild die Straßenbahn auf dem mittleren Weg (ob nun als eigener Weg mit den gleichen Knoten oder direkt am Weg sei dahingestellt) und danach auf den seitlichen Lanes. Ich denke, das gibt die Situation am ehesten wieder.

Zu den beiden letztgenannten Beispielen: Beim ersten 5 Ways: Ein Highway in der Mitte, dann rechts und links je eine Lane, dann rechts und links je ein Railway. Beim zweiten nur 3 Ways, ein Highway in der Mitte und zwei Lanes rechts und links davon, die auch die Straßenbahn enthalten.

Fabi2 · 2012-02-14 16:50:59

hurdygurdyman wrote:

Ich denke, wir müssen hier unterscheiden nach
1. Verwendbarkeit der Daten für Renderer als geografische Information
2. Auswertbarkeit zum (vorausschauenden) Routing
An diesem Spagat scheitern wohl die meisten Ansätze, zumal auch noch der Anspruch besteht, in dem Schema das gesamte Linienbündel incl. bus, tram, footway und cycleway sowie aller möglichen Trennungen dazwischen erschlagen zu wollen. Und dann soll das alles auch noch für den Mapper transparent und ohne Tools erfassbar sein

Man muß da sagen, das für das Routing die Daten doch eh, je nach Gerät passend aufbereitet werrden müssen, gerade wenn man solche Sachen wie Anweisungen auf Spurebene realisieren will, also kommt man um um die Vorverarbeitung nicht drum herum. Die Frage ist da eher, wie mancht man das Tagging so, das der Router leichter das Zug was ihn nicht interessiert ausortiern kann.

Spätestens jetzt für das Mapping auf Spurebene braucht man eine type=street-Relation, für die Straße, wo alles an Wegen/Spuren drin ist, was die Straße mit Namen x darstellt. Das ist immer noch besser/handhabbarer als nur mit Hilftools bearbeitbare Tags.

Dann muß man klar per Tag (z.B. lane=yes) zwischen "das die Straße als ein Weg" und "ab hier wurde sie in Einzelspuren aufgesplittet" unterscheiden können. Das ist wichtig, damit das auch der Router kann und dann z.B. bei 5 Einzelspuren (1x links, 1x links+geradeaus, 2x geradeaus, 1x rechts), doppelte Richtungen nach folgenden Schema rauswerfen kann: Ah, da kann man rechts fahren, OK rechts zum Routingsgraphen hinzugefügt. Ah, dann kann man rechts und geradeaus fahren, rechts hab ich für die Richtung schon, wird in die Tonne getreten, geradeaus noch nicht: wird zum Routingsgraphen hinzugefügt. usw. Damit kann man dann die Daten der Einzelwege auch passend fürs Routing vereinfachen.

Last edited by Fabi2 (2012-02-14 16:52:53)

viw · 2012-02-14 17:11:15

errt wrote:

Ich würde dazu tendieren, im Falle der Königsbrücker Landstraße drei parallele Wege zu erfassen, einmal den Highway (+ eventuell Lane für die Mittelspur) in der Mitte und dann zwei Lanes rechts und links davon. Vor dem 30er Schild die Straßenbahn auf dem mittleren Weg (ob nun als eigener Weg mit den gleichen Knoten oder direkt am Weg sei dahingestellt) und danach auf den seitlichen Lanes. Ich denke, das gibt die Situation am ehesten wieder.

Die Frage ist ob du vor dem 30er Schild die Mittlere Spur zum überholen ignorierst oder ob nach dem 30er Schild eine Spur in der Mitte zu viel ist. Aber um es noch mal platisch zu machen. Das Problem ist das hier wieder von Pkws ausgegangen wird. Denn ein Zweirad (motorrad oder Fahrrad) können auch nach dem 30er Schild die Straßenbahn rechts überholen. Pkws können das nur davor.
Das gleiche Problem tritt übrigens bei überbreiten Fahrspuren auf.
http://maps.google.de/?ll=51.0583,13.72 … 8,,0,11.09
die Rechte Spur ist breit genug für zwei Pkw aber nur für einen Lkw, welcher dann eben nicht überholte werden kann. Für den Ausbau der Königsbrücker Straße war so ein Modell im übrigen für einen ganzen Straßenzug im Gespräch.

errt · 2012-02-15 08:42:21

Wie gesagt, ich würde vor dem 30er Schild wohl auf dem mittleren Weg eine Lane zusätzlich erfassen, danach nicht. Dann ist da weder eine Spur zuviel noch zu wenig. Dass Zweiräder etwas anders überholen, wird sich nie korrekt darstellen lassen, da das Spurenkonzept nunmal (schon in der Realität) auf zweispurige Fahrzeuge ausgelegt ist. Allerdings kann man vielleicht mit einer gewissen Berechtigung annehmen, dass Zweiräder überall überholen können. Ist auch für meinen Geschmack nicht ganz so wichtig, denn Überholen ist aktuell ja noch kein Feature von Navigationsgeräten, oder?

viw · 2012-02-15 09:19:48

errt wrote:

Wie gesagt, ich würde vor dem 30er Schild wohl auf dem mittleren Weg eine Lane zusätzlich erfassen, danach nicht. Dann ist da weder eine Spur zuviel noch zu wenig. Dass Zweiräder etwas anders überholen, wird sich nie korrekt darstellen lassen, da das Spurenkonzept nunmal (schon in der Realität) auf zweispurige Fahrzeuge ausgelegt ist. Allerdings kann man vielleicht mit einer gewissen Berechtigung annehmen, dass Zweiräder überall überholen können. Ist auch für meinen Geschmack nicht ganz so wichtig, denn Überholen ist aktuell ja noch kein Feature von Navigationsgeräten, oder?

Ich weiß nicht so genau. Ich denke dieser Umstand ist für eine Aufwandsberechnung sicher nicht unerheblich. In Verkehrssimulationen sieht man ja immer wieder das der ÖPNV als Pulkführer auftritt.
Mir fällt gerade keine Stelle ein wo es die Spuren bei Radwegen auch gibt. Aber auch dort gibt es Abbieger und ähnliches. Wahrscheinlich in Fahrradstädten noch mehr als hier in Dresden.
Außerdem zeigt das Beispiel wieder unser eigentliches Problem. Wenn wir nur die Straßenmitte angeben, sagt das nichts über die Fahrspuren aus. wenn wir jetzt die Fahrspurenmitte auswählen dann sagt das nichts über die Gleislage in der Fahrspur aus.
Daher wäre schon die Frage ob man das optische nicht von dem Routing teilt. Eine flächige Erfassung des Straßenraumes.

hurdygurdyman · 2012-02-15 10:18:29

hurdygurdyman wrote:

...
Es wird ein neuer key lane=* eingeführt. Sobald mehrere Spuren mit verschiedenen Eigenschaften eines highway=* vorhanden sind und der Wechsel zwischen diesen für Verkehrsteilnehmer physisch möglich ist, werden entsprechende lane=* parallel zum highway angelegt, was bei hochauflösenden Bildern als Grundlage möglich wird. Diese lane=* können mit entsprechenden Zusatz-tags genau wie highway=* versehen werden, um weitere Eigenschaften zu definieren.
...

Nach weiteren Überlegungen habe ich mal einige Punkte zu meiner Vorgehensweise festgelegt. Es macht für mich noch wenig Sinn, jetzt schon über 1%-5%-Probleme nachzudenken, wenn das Grundschema noch nicht transparent ist. Dies heißt aber nicht, dass diese Probleme ignoriert werden. Leider ist aber nicht alles Denkbare auch in OSM machbar

Grundsätze:
• lane=* wird nur verwendet, wenn es um die detaillierte Erfassung von Spuren geht, die Bestandteil eines highway=* sind, um das spurabhängige routing im Bereich von Kreuzungen, Abzweigungen und Anschlussstellen zu ermöglichen.
• lane=* impliziert immer oneway=yes. Einzige Ausnahme ist lane=footway.
• Da highway=* in der Regel richtungsunabhängig verwendet wird und als way auf der Straßenmitte liegt, ist lane=* immer zusätzlich als way zu erfassen.
(Ausnahmen könnten bei „divided highway" denkbar sein)
• Der Spurwechsel zwischen Spuren gleicher Klassifizierung ist für entsprechend berechtigte Verkehrsteilnehmer generell möglich.
• Der Spurwechsel auf eine Spur mit anderer Klassifizierung ist generell möglich, wenn der Verkehrsteilnehmer zur Nutzung der Spur berechtigt ist.
• Das separate umfängliche Erfassen der highway=* nach den bekannten Kriterien ist weiterhin erforderlich, um die etablierten Auswertungen nicht zu gefährden. Die hierdurch bestehende Gefahr von Redundanzen zwischen highway=* und lane=* bedarf besonderer Beachtung beim Erfassen.
• Es ist denkbar, später eine relation=highway einzuführen, welche dann highway=* für die als lane=* vollständig erfassten Bereiche ersetzt und die gemeinsam für alle beteiligten lane=* geltenden Attribute auf der Ebene der Relation zusammenfasst.

Im ersten Schritt liegt der Fokus auf der Spurführung für motorisierten Verkehr. Cycleway und footway bleiben hier vorerst noch unberücksichtigt. Für diese wird das Schema im zweiten Schritt erweitert. In einem dritten Schritt wird geprüft, ob die Einbindung z.B. von railway=tram als „konkurrierender" Verkehrsteilnehmer möglich ist.
Dies wird meine Testkreuzung für erste Schritte zum Tagging-Schema:
http://wiki.openstreetmap.org/wiki/File:Kreuzung.png

Last edited by hurdygurdyman (2012-02-15 10:38:48)

viw · 2012-02-15 10:48:05

hurdygurdyman wrote:

Grundsätze:
• lane=* wird nur verwendet, wenn es um die detaillierte Erfassung von Spuren geht, die Bestandteil eines highway=* sind, um das spurabhängige routing im Bereich von Kreuzungen, Abzweigungen und Anschlussstellen zu ermöglichen.
• lane=* impliziert immer oneway=yes. Einzige Ausnahme ist lane=footway.
• Da highway=* in der Regel richtungsunabhängig verwendet wird und als way auf der Straßenmitte liegt, ist lane=* immer zusätzlich als way zu erfassen.
(Ausnahmen könnten bei „divided highway" denkbar sein)
• Der Spurwechsel zwischen Spuren gleicher Klassifizierung ist für entsprechend berechtigte Verkehrsteilnehmer generell möglich.
• Der Spurwechsel auf eine Spur mit anderer Klassifizierung ist generell möglich, wenn der Verkehrsteilnehmer zur Nutzung der Spur berechtigt ist.
• Das separate umfängliche Erfassen der highway=* nach den bekannten Kriterien ist weiterhin erforderlich, um die etablierten Auswertungen nicht zu gefährden. Die hierdurch bestehende Gefahr von Redundanzen zwischen highway=* und lane=* bedarf besonderer Beachtung beim Erfassen.
• Es ist denkbar, später eine relation=highway einzuführen, welche dann highway=* für die als lane=* vollständig erfassten Bereiche ersetzt und die gemeinsam für alle beteiligten lane=* geltenden Attribute auf der Ebene der Relation zusammenfasst.

Also bei Zwei Dingen sehe ich ein Problem.
1. lane impliziert oneway= yes Das solltest du nicht zu festlegen, bzw. solltest du die Möglichkeit schaffen dies aufzuweichen. Es gibt nicht nur wie auf der Königsbrücker Straße Fahrspuren für beie Richtungen, sondern insbesondere auch mit dauerlichtszeichen markierte Spuren, welche die Richtung jeweils in Hauptverkehrsrichtung wechseln können. Das sollte wenn schon oneway angenommen wird auch abbildbar sein.
2. der Wechsel zwischen den Spuren. Insbesondere bei Autbahnkreuzen und vor Kreuzungen kommt es oft vor, dass die Spuren nicht oder nur in einer Richtung gewechselt werden können. Diesen Umstand würde dein Modell komplett ignorieren. Auch das Überholen nicht überholen ist damit einfach ausgeblendet.

hurdygurdyman · 2012-02-15 11:04:31

viw wrote:

...
Also bei Zwei Dingen sehe ich ein Problem.
1. lane impliziert oneway= yes Das solltest du nicht zu festlegen, bzw. solltest du die Möglichkeit schaffen dies aufzuweichen. Es gibt nicht nur wie auf der Königsbrücker Straße Fahrspuren für beie Richtungen, sondern insbesondere auch mit dauerlichtszeichen markierte Spuren, welche die Richtung jeweils in Hauptverkehrsrichtung wechseln können. Das sollte wenn schon oneway angenommen wird auch abbildbar sein.
2. der Wechsel zwischen den Spuren. Insbesondere bei Autbahnkreuzen und vor Kreuzungen kommt es oft vor, dass die Spuren nicht oder nur in einer Richtung gewechselt werden können. Diesen Umstand würde dein Modell komplett ignorieren. Auch das Überholen nicht überholen ist damit einfach ausgeblendet.

Danke für deine Anmerkungen.
zu 1:
Ich denke, dass in 99% der Fälle oneway=yes zutreffen würde. Beim Rest könnte man dann ja oneway=no oder lane_restriction=bidirectional und ggf. weitere Zusatztags verwenden. lane_restriction habe ich analog zur restrictions-Relation sowieso mit en values left_only, no_left_turn usw. eingeplant.
zu 2:
Für den Fall der durchgezogenen Linie zwischen Spuren plane ich einen key lane_changing mit den values no, no_left und no_right.
Damit dürfte auch die Überholmöglichkeit abgebildet sein. Sobald lane_changing fehlt, ist Spurwechsel möglich.

Ich denke bei den Grundsätzen sollte ich noch ergänzen, dass Spurwechsel in die Gegenfahrbahn grundsätzlich ausgeschlossen ist. Für u_turn müsste explizit lane_changing=u_turn oder lane_restriction=u_turn (bei separater Spur) anzugeben sein.

viw · 2012-02-15 11:59:36

Naja mit diesen Ergänzungen zu deinen Grundgeanken kann ich durchaus leben.
Mal schauen was die anderen dazu meinen.

Netzwolf · 2012-02-15 12:10:14

Nahmd,

hurdygurdyman wrote:

• Es ist denkbar, später eine relation=highway einzuführen, welche dann highway=* für die als lane=* vollständig erfassten Bereiche ersetzt und die gemeinsam für alle beteiligten lane=* geltenden Attribute auf der Ebene der Relation zusammenfasst.

Meines Wissens gehen die "Großen" so vor wie von Dir beschrieben. Allerdings ist die Relation dann Pflicht. Von den Mitgliedern der Relation werden entweder die highways oder die Lanes gezeichnet. Zu versuchen, die gleiche Geometrie für abstrakten und konkreten Weg zu benutzen, macht die Konstruktion unübersichtlicher.

Gruß Wolf

viw · 2012-02-15 12:23:55

Eventuell brauchen wir auch noch Übergangslösungen. Wie kann man aus Straßen Spuren machen, so lange nicht alle Straßen detailiert erfasst sind sollte ja dennoch die Erreichbarkeit der Lanes sichergestellt sein. Außerdem ist es fragglich ob bei gleichbelibenden Spuren auf Landstraßen wirklich viele Menschen dazu neigen werden dort noch je Richtung einen weiteren Way als lane anzulegen.

de_muur · 2012-02-15 12:41:50

hurdygurdyman wrote:

Sobald lane_changing fehlt, ist Spurwechsel möglich.

Und von wo nach wo????

Fuers Routing braucht man einen Graphen aus Knoten und Kanten. Wie willst du aus deinen einzeln erfassten Lanes ableiten, von welchem Knoten der einen Lane man nun zu welchem Knoten der anderen Lane wechseln kann? Ohne weitere Relation weiss die eine Lane ja nicht mal was von der anderen.

Gruss
Torsten

hurdygurdyman · 2012-02-15 13:00:44

Vielleicht ist es interessant, warum ich die Beispiel-Kreuzung so angelegt habe:
http://wiki.openstreetmap.org/wiki/File:Kreuzung.png
Die orange durchgezogene und die blau gestrichelte Linie sowie die roten Punkte und die Ampel repräsentieren das bisherige tagging als highway=*, highway=crossing und traffic-signals. Sie dienen dazu, eventuell erforderliche Änderungen an diesen als Voraussetzung oder Folge des lane-taggings darzustellen.

Südstraße:
Ein einfacher highway, um zu testen, ob der sich ohne weiteres tagging in das Schema intgrieren lässt.

Weststraße:
Hier ist ein auftrennen in zwei highways (divided highway) mit jeweils zwei lanes wegen der baulichen Trennung erforderlich. Die obere Autospur nach Westen könnte noch ein „only_right_turn" erhalten, um von Osten her das vorausschauende routing zu testen (einordnen in der nördlichen Spur der Oststraße, um Spurwechsel zu vermeiden)

Nordstraße:
„Standard" für exklusive Abbiegespuren von Norden her. (Die Spur Richtung Norden wird höchstens ein lane=residential oder benötigt kein lane=* ??)

Oststraße:
„Standard" wie Nordstraße ohne Abbiegemöglichkeit nach Süden. Sie muss wie die Weststraße auch in zwei highways aufgetrennt werden. Da könnte man zu Testzwecken noch eine Parkspur oder eine Bus-Haltebucht einbauen.

Rot uni ist ein cycleway, grau mit Muster sind footways und blass rotgrau mit Muster ist ein path mit Zeichen DE:240 für Fußgänger und Radfahrer. Diese und die Fußgängerübergänge wurden später für das entsprechende tagging und routing angelegt.

Ich werde auch noch eine typische Beispielzeichnung für einen motorway_link oder primary_link anfertigen und das Schema dafür testen. Dann dürften gefühlt über 80% der Standard-Fälle ins Schema eingeflossen sein. Momentan entwickle ich die key/value tags, die ich dann als pdf zur Diskussion hochlade.

Aber da nun hier im Südwesten die ernstzunehmende närrische Zeit auf Hochtouren anläuft, werde ich die nächsten Tage etwas ruhiger mit dem Thema umgehen. Aber ich werde alle Bedenken und Einwände – gerne aber auch Lösungsansätze - zur Kenntnis nehmen und versuchen, eine Antwort zu finden

Last edited by hurdygurdyman (2012-02-15 13:32:54)

hurdygurdyman · 2012-02-15 13:13:15

@viw:
Schön, dass du mit meinen Grundgedanken jetzt leben kannst
Ich bin mir nicht sicher, ob wir Übergangslösungen brauchen, da highway=* ja erstmal bleibt. Wenn lane=* oder die relation=highway vorhanden ist, kann der Renderer/Router je nach Willen und Können ja darauf zurückgreifen. Gibts die nicht, muss er die highway-infos nehmen.

@Netzwolf:
Die relation=highway muss also kommen, wenn highway=* an entsprechender Stelle komplett durch lane=* und relation=highway ersetzt werden kann?

@de_muur:
Ich denke über das Graphen/Knoten/Kanten-Problem nach Macht aber vielleicht erst Sinn, wenn das tagging-Schema ansatzweise steht. Da muss ich mich aber noch etwas schlauer machen. Hat jemand einen Vorschlag, wie das ohne weitere relation zu lösen ist? Ich möchte eigentlich mit Relationen so sparsam wie möglich umgehen.

hurdygurdyman · 2012-02-15 15:13:06

de_muur wrote:

hurdygurdyman wrote:
Sobald lane_changing fehlt, ist Spurwechsel möglich.

Und von wo nach wo????
Fuers Routing braucht man einen Graphen aus Knoten und Kanten. Wie willst du aus deinen einzeln erfassten Lanes ableiten, von welchem Knoten der einen Lane man nun zu welchem Knoten der anderen Lane wechseln kann? Ohne weitere Relation weiss die eine Lane ja nicht mal was von der anderen.
Gruss
Torsten

Ich unterscheide jetzt im Interesse einer Lösung mal für routing und rendering:
Für routing beziehungsweise die Ansage besteht die Lösung darin, dass ja am Beginn der entsprechenden Spur ein gemeinsamer Knoten mit mindestens einer Nachbarspur besteht. Somit kann sich der router ja den hier befindlichen frühesten Punkt zum Spurwechsel wählen und auch entsprechend ansagen/anzeigen.
lane-changing wäre somit eher für den Renderer, um optisch die "durchgezogene Linie" oder "gestrichelte Linie" auf der entsprechenden Seite abzubilden. Sollte die gestrichelte irgendwann zur durchgezogenen Linie werden, müsste man den lane dort auftrennen und den tag fur den folgenden Rest setzen.

Kannst du damit leben, Torsten?

Last edited by hurdygurdyman (2012-02-15 15:25:51)

de_muur · 2012-02-15 18:00:08

hurdygurdyman wrote:

Für routing beziehungsweise die Ansage besteht die Lösung darin, dass ja am Beginn der entsprechenden Spur ein gemeinsamer Knoten mit mindestens einer Nachbarspur besteht. Somit kann sich der router ja den hier befindlichen frühesten Punkt zum Spurwechsel wählen und auch entsprechend ansagen/anzeigen.
...
Kannst du damit leben, Torsten?

Nein, denn das funktioniert nur, wenn zusaetzlich eine Abbiegespur hinzu kommt. wenn aber eine Strasse ueber eine Kreuzung hinweg mehrspurig ist, dann klappt das nicht mehr.
Desweiteren kommt dabei Murks raus, wenn man ausserhalb einer Kreuzung auf die andere Strassenseite will.

Ausserdem ist einige Seiten weiter vorne ausgiebig dargelegt worden, dass durch die mehrfachen Wege die Kreuzungstopologien fuer die automatische Auswertung nicht mehr verstaendlich sind. So kann ein Router zwar noch eine optimale Strecke finden, er kann aber kaum noch brauchbare Abbiegeanweisungen erzeugen.

=> Mit dem Ansatz verrennst du dich in eine Sackgasse. Dass kann mir im Prinzip egal sein, es ist ja deine Zeit, die dabei rauf geht. Das Problem ist nur, dass andere dir in die Sackgasse folgen moegen, und OSM ist nun mal herdengetrieben.

Gruss
Torsten

viw · 2012-02-15 20:01:13

de_muur wrote:

hurdygurdyman wrote:
Für routing beziehungsweise die Ansage besteht die Lösung darin, dass ja am Beginn der entsprechenden Spur ein gemeinsamer Knoten mit mindestens einer Nachbarspur besteht. Somit kann sich der router ja den hier befindlichen frühesten Punkt zum Spurwechsel wählen und auch entsprechend ansagen/anzeigen.
...
Kannst du damit leben, Torsten?
Nein, denn das funktioniert nur, wenn zusaetzlich eine Abbiegespur hinzu kommt. wenn aber eine Strasse ueber eine Kreuzung hinweg mehrspurig ist, dann klappt das nicht mehr.
Desweiteren kommt dabei Murks raus, wenn man ausserhalb einer Kreuzung auf die andere Strassenseite will.
Ausserdem ist einige Seiten weiter vorne ausgiebig dargelegt worden, dass durch die mehrfachen Wege die Kreuzungstopologien fuer die automatische Auswertung nicht mehr verstaendlich sind. So kann ein Router zwar noch eine optimale Strecke finden, er kann aber kaum noch brauchbare Abbiegeanweisungen erzeugen.
=> Mit dem Ansatz verrennst du dich in eine Sackgasse. Dass kann mir im Prinzip egal sein, es ist ja deine Zeit, die dabei rauf geht. Das Problem ist nur, dass andere dir in die Sackgasse folgen moegen, und OSM ist nun mal herdengetrieben.
Gruss
Torsten

Hast du alles richtig gelesen? Die bisherige Strucktur highway=* bleibt erhalten. Dein schlaues navi erzeugt also wie bisher die Abbiegehinweise aus den Grundtopologien und kann bei Bedarf die Spuren anzeigen und wenn die dann eine direction haben sagt er dir dann sogar ordnen sie sich in der Spur geradeaus nach Berlin ein. Das findest du bei den heutigen Daten sicher noch nicht.

de_muur · 2012-02-15 20:51:51

viw wrote:

Hast du alles richtig gelesen? Die bisherige Strucktur highway=* bleibt erhalten. Dein schlaues navi erzeugt also wie bisher die Abbiegehinweise aus den Grundtopologien und kann bei Bedarf die Spuren anzeigen und wenn die dann eine direction haben sagt er dir dann sogar ordnen sie sich in der Spur geradeaus nach Berlin ein.

Das schlaue Navi will ich haben.

Fuer den Fall, dass die meisten Navis nicht so schlau sind, koennten wir ja vielleicht auch ein einfacher auszuwertendes Taggingschema benutzen.

Gruss
Torsten

Announcement

#201 2012-02-14 09:31:34

Re: Routing / Spurmapping

#202 2012-02-14 12:00:31

Re: Routing / Spurmapping

#203 2012-02-14 14:04:36

Re: Routing / Spurmapping

#204 2012-02-14 14:52:52

Re: Routing / Spurmapping

#205 2012-02-14 15:28:55

Re: Routing / Spurmapping

#206 2012-02-14 15:50:25

Re: Routing / Spurmapping

#207 2012-02-14 16:08:52

Re: Routing / Spurmapping

#208 2012-02-14 16:22:05

Re: Routing / Spurmapping

#209 2012-02-14 16:50:59

Re: Routing / Spurmapping

#210 2012-02-14 17:11:15

Re: Routing / Spurmapping

#211 2012-02-15 08:42:21

Re: Routing / Spurmapping

#212 2012-02-15 09:19:48

Re: Routing / Spurmapping

#213 2012-02-15 10:18:29

Re: Routing / Spurmapping

#214 2012-02-15 10:48:05

Re: Routing / Spurmapping

#215 2012-02-15 11:04:31

Re: Routing / Spurmapping

#216 2012-02-15 11:59:36

Re: Routing / Spurmapping

#217 2012-02-15 12:10:14

Re: Routing / Spurmapping

#218 2012-02-15 12:23:55

Re: Routing / Spurmapping

#219 2012-02-15 12:41:50

Re: Routing / Spurmapping

#220 2012-02-15 13:00:44

Re: Routing / Spurmapping

#221 2012-02-15 13:13:15

Re: Routing / Spurmapping

#222 2012-02-15 15:13:06

Re: Routing / Spurmapping

#223 2012-02-15 18:00:08

Re: Routing / Spurmapping

#224 2012-02-15 20:01:13

Re: Routing / Spurmapping

#225 2012-02-15 20:51:51

Re: Routing / Spurmapping

Board footer