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 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/WikiProject_Germany/Workshops/Linienb%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
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?
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.
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.
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.
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?
@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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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
Aber ich bin gespannt auf eure Argumente, weshalb das nicht gehen soll 
