Routing / Spurmapping

errt · 2012-02-14T15:22:05.000Z

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-14T15:50:59.000Z

hurdygurdyman:

Ich denke, wir müssen hier unterscheiden nach

Verwendbarkeit der Daten für Renderer als geografische Information

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.

viw · 2012-02-14T16:11:15.000Z

errt:

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.726769&spn=0.001399,0.002411&t=m&z=19&layer=c&cbll=51.0583,13.726769&panoid=7J4qJ4nLT-Zgxp6Q8kAgqA&cbp=12,317.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-15T07:42:21.000Z

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-15T08:19:48.000Z

errt:

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-15T09:18:29.000Z

hurdygurdyman:

…
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

viw · 2012-02-15T09:48:05.000Z

hurdygurdyman:

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.

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.
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-15T10:04:31.000Z

viw:

…
Also bei Zwei Dingen sehe ich ein Problem.

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.

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-15T10:59:36.000Z

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

Netzwolf · 2012-02-15T11:10:14.000Z

Nahmd,

hurdygurdyman:

• 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-15T11:23:55.000Z

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-15T11:41:50.000Z

hurdygurdyman:

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-15T12:00:44.000Z

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

hurdygurdyman · 2012-02-15T12:13:15.000Z

@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-15T14:13:06.000Z

de_muur:

hurdygurdyman:

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?

de_muur · 2012-02-15T17:00:08.000Z

hurdygurdyman:

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-15T19:01:13.000Z

de_muur:

hurdygurdyman:

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-15T19:51:51.000Z

viw:

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

Fabi2 · 2012-02-15T22:35:41.000Z

Flächenmehrfachnutzung (korrekte Abbildung des Straßenbahn auf der Straße) geht soweit ich das übersehen kann, nur wenn man die Spuren/Objekte als Fläche mappt.

Ansonsten kann man in etwa so etwas als Spumodell nehmen:
ein Way mit:

width=*
maxspeed=*
surface=*
forward=yes/no (die entsprechende Fahrtrichtung ist (nicht) erlaubt)
backward=yes/no
left=yes/no (man darf (nicht) nach links fahren (Sperrlinien/-flächen, Fußweg, Straßengraben, Überholverbot, etc.))
right=yes/no

x-Stück dieser Segmente sind dann der highway=* als Relation mit zugehörigem name=*.
Wenn sich die Eigenschaften ändern, muß man ein neues highway-Segment einzeichnen.

Das erst mal nur so als Idee zur Vereinfachung des Problems, sonst muß man mit Flächen operieren, wenn man das Straßenbahnproblem auch noch gelöst haben möcht, ist aber dann entsprechend aufwendig zu mappen, da mkann man dann nicht mal so eben nur 'ne Linie malen.

hurdygurdyman · 2012-02-16T07:52:40.000Z

Ich fange mal hinten an:

de_muur:

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

Für mich läuft das auch unter Gehirn-Jogging, was ja für einen mittlerweile fast 57-jährigen wie mich durchaus empfehlenswert sein soll und somit eine sinnvolle Zeitverschwendung darstellt
Selbst wenn nichts dabei rauskommt, ist es gut, dass wir darüber gesprochen haben. Ich habe mir dann aber erspart, im stillen Kämmerlein mühsam ein englisches proposal zu basteln, das dann keiner beachtet oder das heillos zerrissen wird.
Ich halte den Weg für sinnvoller, hier im Vertrauen auf die „german croud intelligence" gemeinsam mit euch erst einmal eine mögliche Lösung zu entwickeln, woraus dann ein proposal entstehen kann. Leider ist talk-de (noch) nicht mein Ding. Da sind wohl eher die Techniker unterwegs, deren Meinung zu diesem Thema auch interessant wäre. Da muss ich dann wohl noch ran
Solange es noch kein unausgegorenes proposal gibt, das manche Mapper dann auch noch umsetzen, sehe ich die Gefahr, dass man mir in eine Sackgasse folgt, noch nicht.

de_muur:

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.

Das muss durch das tagging-Schema verhindert werden. Über Relationen wäre da wohl eine Lösung möglich, aber die sind ja nicht unbedingt erwünscht und ich will sie auch möglichst vermeiden. Ich denke darüber nach.

de_muur:

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.

Da können doch die router eine Logik entwickeln die ungefähr so aussieht, dass bei mehreren Spuren mit derselben Richtung über die Kreuzung hinaus z.B. immer die rechte Spur bei Rechtsverkehr verwendet wird, was ja in Deutschland auch den geltenden Regeln entspricht. Für vorausschauendes routing wäre eine Regel im router denkbar, die z.B. für ein Abbiegen an der dann folgenden Kreuzung oder Abzweigung eine Spurempfehlung wählt, die ohne oder mit möglichst wenig Spurwechseln bis dorthin auskommt.

de_muur:

Desweiteren kommt dabei Murks raus, wenn man ausserhalb einer Kreuzung auf die andere Strassenseite will.

Da verstehe ich leider nicht, wie du das im Zusammenhang mit dem Vorschlag meinst