Ok, war von mir nicht bis zu Ende gedacht… Das Schema passt wohl besser zu divider:lanes oder so. (Bin in dem lanes:* Schema nicht richtig drin. Der Beitrag sollte nur eine eingeworfene Idee sein.)
Da “|” der Trenner für die lanes ist, kann er nicht gleichzeitig als Symbol für die Linienart verwendet werden. Außer nimmt für divider:lanes einen anderen Trenner. zB: |4:3|:2|1| oder |x:x|:x|x| oder “L” für lane |L:L|:L|L|
Da muss man aber auch bedenken, wie realistisch dieses Szenario ist. Wenn ich die Wahl habe zwischen Tags an Ways, die flächendeckend eine korrekte Darstellung der Straßenlinien erlauben, und den hochgenauen Experimenten mit Flächen für einzelne Spuren in der Nachbarschaft einiger weniger Powermapper, dann fällt meine Wahl aus praktischen Gründen auf die Way-Tags.
Davon abgesehen ist es nicht so, dass die Darstellung als Way fürs Rendering ausschließlich Nachteile gegenüber Flächen hätte - z.B. hat man an Ways unter Umständen leichteren Zugang zu gerichteter Information wie der Steigung oder es lassen sich Annahmen zur Krümmung der Straßenoberfläche quer zur Wegrichtung treffen. Und natürlich die leichtere Verknüpfbarkeit mit Routing-Resultaten, die daraus resultieren dürfte, dass beide denselben Datensatz nutzen. Man will ja Rendering und Routing idealerweise nicht als zwei komplett getrennte Welten haben, sondern auch seine spurgenaue Route in ein entsprechendes Rendering einzeichnen können.
Hast du denn ein konkretes Beispiel für die fehlende Möglichkeit einer Übersetzung Aussehen → Funktion? #45 geht da auch nicht so weit ins Detail, dass ich verstehe, an welche Situationen du denkst.
Das hat aber auch entsprechende Konsequenzen: Es ist unmöglich, auf Grundlage von OSM-Daten Verkehrszeichen zu rendern. Auf das Rendern von Spurtrennern möchte ich für meinen Teil nicht verzichten.
Bevor wir hier darüber streiten, welche Anwendung “wichtiger” ist, sollten erst mal alle Anwendungen überhaupt möglich sein
Ich halte das Taggen der Funktion übrigens nicht unbedingt für weniger fehleranfällig, die Fehler sind nur andere: Wenn die Regeln eines Routers für ein ganzes Land fehlerhaft sind, ist das natürlich ein Problem. Es fällt aber auch viel eher auf, als wenn ein einzelner Mapper aufgrund eines Missverständnisses des örtlichen StVO-Äquivalents manche Straßen falsch taggt.
Spontan fallen mir Busspuren ein. Die sind bei uns meist mit einer dicken durchgezogenen Linie abgegrenzt. Busse dürfen die Linie dennoch überfahren. Oder die Radwegbegrenzung auf der Straße. Wenn ich links abbiegen möchte, darf ich die als Radfahrer überfahren. Die durchgezogene Linie in der Mitte aber nicht.
Sprich durchgezogene Linie heißt nicht immer, dass man diese nicht überfahren darf. Ebenso kann man nicht davon ausgehen, dass wenn man eine Linie überfahren darf, dass diese gestrichelt ist. Wenn man jetzt mal von hiesigen Linienarten aus geht. Evtl. gibt es auch Länder, wo die Linien andere Bedeutungen haben.
Auf manchen Autobahnen gibt es auch Spursperrungen für LKWs. Die Linien sind gestrichelt, dennoch dürfen nicht alle diese Linie überfahren.
Sprich fürs Routing braucht man crossig:=, wobei der komische String aussagen muss, wie man wechseln darf. Für das Rendering möchte ich nur wissen, ob da jetzt eine dicke, durchgezogene Linie ist oder eine dünne, gestrichelte.
Absolut richtig. Kann jemand daraus einen Taggingvorschlag machen? Ich gebe zu, es ist nicht meine Stärke, viele von Euch machen es deutlich besser als ich.
Naja, aus den Daten, die wir an die Wege kleben zumindest nicht besonders gut, aber es gibt ja durchaus schon Möglichkeiten, um auch Schilder einzutragen. Ohne die allgemeine Auswertung von Einschränkungen zu stören. Und ansonsten stimme ich dir zu, Spurtrenner gehören gerendert. Wenn die allerdings mal nicht hundertprozentig mit der Realität übereinstimmen, ist das aber auch kein Beinbruch.
Wenn die Regeln für ein ganzes Land fehlerhaft sind, dann ja. Aber Grenzbereiche, die schlecht ausgeschnitten sind oder Mapper die finden, eine andere Tagkombination entspricht dem Aussehen nach eher dem Zustand auf der Straße (als etwas übertriebenes Beispiel könnte sein, dass jemand durchgehende Linien als unterbrochen taggt, weil sie stellenweise verblasst oder vedreckt sind), sind keine systematischen Fehler.
Interessante Sammlung! Du hast Recht mit deiner Argumentation: Es reicht oft nicht, nur das Aussehen zu taggen.
Ich habe daher noch mal etwas über das Thema nachgedacht und denke, dass man nichtsdestotrotz mit Default-Werten arbeiten könnte - so ähnlich, wie wir es ja bei highway-Werten tun. Beispielsweise wäre eine gestrichelte Linie standardmäßig für alle Fahrzeuge von beiden Seiten überquerbar. Eine gestrichelte+durchgezogene Trennung nur von links. Und so weiter.
Es sollte also definitiv Tags für “crossable”, “crossable:hgv” und so weiter geben. Allerdings hätte jedes Linienmuster landesabhängige Vorgabewerte, die im “Normalfall” unverändert belassen werden können (aber nicht müssen).
Siehe auch:
http://forum.openstreetmap.org/viewtopic.php?pid=284554#p284554
Edit Zitat:
Ob das jetzt “crossable” oder “change:lanes” heißt… 
Ich denke, “change:lanes” ist selbsterklärender.
@Tordanik: Und dann taggen wir, die Linie sei durchgezogen (weil die Allgemeinheit sie nicht überqueren darf) und für Busse gestrichelt (weil es eben eine Busspur ist)? Das gibt doch auch nicht das Aussehen wieder, sondern die Funktion, dann könnten wir auch gleich bei der Funktion bleiben. Die braucht auch wenigstens keine landesspezifischen Defaults.
Ich habe mal in der StVO für Deutschland ( http://www.verkehrsportal.de/stvo/stvo_41.php in verbindung mit http://www.verkehrsportal.de/stvo/anlage_2.php ) und Österreich ( http://www.jusline.at/9_Verhalten_bei_Bodenmarkierungen_StVO.html ) nachgelesen. Fahrbahnmarkierungen wie Richtungspfeile, Haltelinien u.a. sind somit Gebote oder Verbote, die sich auf die Straße, die Fahrbahn oder die Spur beziehen und durchaus entsprechenden verkehrsschildern gleichzusetzen. Also ist das entsprechend dargestellte Gebot oder verbot eine Eigenschaft der Spur für unseren Fall hier. Genauso wie es z.B. bei maxspeed=* auch gehandhabt wird, kann ein entsprechender tag wie turn:lanes=left|through|right die relation=restriction ersetzen oder als Alternative verwendbar sein. Das entsprechende turn:lanes=left|through|right würde sich dann auf den in Fahrtrichtung nächsten gemeinsamen Knoten mit einem anderen highway=* beziehen.
Diese Heuristik ist ja der große Nachteil dieser relationslosen Lanes-Lösung. Bei der Relation ist explizit angegeben für
welchen Ziel-Way sie gilt, bei turn:lanes muss der Router den passenden Way anhand der Geometrie bestimmen, was
fehleranfällig ist. Aber erstmal abwarten, vielleicht ist es doch ganz brauchbar.
Ich denke dass bei Kreuzungen oder Einmündungen mit bis zu vier sich treffenden ways das Problem nicht auftritt und somit die Masse der Fälle problemlos sein dürfte.
Sternkreuzungen ab fünf Straßen werden schwierig, wenn dort kein Kreisverkehr ist. Hat jemand einen solchen Fall mit hochauflösenden Hintergrundbildern für einen Test?
Ich hoffe du irrst nicht. Aber schon der Unterschied bei dieser Kreuzung: http://maps.google.de/maps?q=Dresden+Tiergartenstra%C3%9Fe&hl=de&ie=UTF8&ll=51.033169,13.774641&spn=0.000684,0.002045&sll=51.175806,10.454119&sspn=11.123555,33.508301&hnear=Tiergartenstra%C3%9Fe,+01219+Dresden,+Sachsen&t=h&z=20
Im vergleich zu http://maps.google.de/maps?q=Dresden+Tiergartenstra%C3%9Fe&hl=de&ie=UTF8&ll=51.032084,13.777526&spn=0.000684,0.002045&sll=51.175806,10.454119&sspn=11.123555,33.508301&hnear=Tiergartenstra%C3%9Fe,+01219+Dresden,+Sachsen&t=h&z=20
Macht doch einige Unterschiede. Während bei der ersten Kreuzung vorgeschrieben ist von welchem Fahrstreifen auf welchen abgebogen werden muss (durchgezogenen Linie beim Abbiegen) ist bei der zweiten Kreuzung alles freigestellt. Ich kann frei wählen zwischen dem ersten oder zweiten Fahrstreifen.
Als Testgelände könnte ich dir vielleicht auch den Schillerplatz empfehlen. Aufgrund der Einbahnstraßen vereifacht sich zwar einiges, aber die nahgelegenen anderen Abzweigungen und insbesondere die Straßenbahnen könnten dich vor Herausforderungen stellen.
Natürlich auch noch mit Link: http://maps.google.de/maps?q=Dresden+Tiergartenstra%C3%9Fe&hl=de&ie=UTF8&ll=51.052062,13.806892&spn=0.000684,0.002045&sll=51.175806,10.454119&sspn=11.123555,33.508301&hnear=Tiergartenstra%C3%9Fe,+01219+Dresden,+Sachsen&t=h&z=20
Bitte bedenkt bei allen Konstrukten auch daran was passiert wenn jemand einfach eine Straße hinzufügt oder löscht ohne explizit Abbieger zu berücksichtigen. Da sind Relationen denke ich im Vorteil. Weil die gehen kaput und sind dann unbrauchbar. Eine generische Zuweisung zu Straße 1, 2 oder 3 kann zu falschen Ergebnissen führen.
Hier wäre das Modell mit eigenen Wegen wohl am ehesten im Vorteil, denn die kann man kaum übersehen und wird sich dann wohl drum kümmern. Selbst wenn man das nicht tut, sollte zumindest das, was schon da ist, problemlos weiter funktionieren.
Das Modell mit den eigenen Wegen sieht auf den ersten Blick sehr lukrativ aus. Das Problem ist nur wie macht man dem Router den möglichen Spurwechsel begreifbar? Wie verhält sich ein Router wenn man gerade losfährt? Es gibt ja keine Möglichkeit per GPS zu erkennen auf welcher Spur man sich gerade befindet?
Zu Fall 1:
Wenndie Karcherallee als way in OSM mit der Richtung nach oben angelegt ist, wäre ein Schlüsselpaar turn:lanes=|through|right_right_lane denkbar, um die linke Spur der Winterbergstraße auszuschließen.
Zu Fall 2:
Nichts besonderes.
Zum Schillerplatz:
Durch Schatten und abgenutzte Markierungen ist die Situation so schwer einschätzbar
Die Straßenbahn sind keine Herausforderung, da sie als separater way in geografisch korrekter Lage gemappt werden könnten. Es geht hier um routing für Straßenverkehrsteilnehmer und deren Verkehrsführung durch Verkehrszeichen oder Markierungen. In der Tolkewitzer Straße sehe ich eine Sperrfläche, weshalb hier die beiden gegenläufigen Fahrbahnen sowieso als separate ways anzulehgen wären.
http://www.openstreetmap.org/?lat=51.0519084334373&lon=13.8068452477455&zoom=18
Ich verstehe deinen Einwand nicht.
Wenn die Linie dort durchgezogen ist, taggen wir sie als durchgezogene Linie. Damit ist das Aussehen definiert. Außerdem wird erstmal für alle Verkehrsmittel angenommen, dass sie nicht überfahrbar ist.
Da nun Busse doch drüberfahren dürfen, tragen wir diese Ausnahme zusätzlich explizit ein als “überfahrbar”:bus = yes
Dann haben aber crossable und crossable:* völlig unterschiedliche Semantik und auch Syntax, nämlich ersteres Linienarten und letztere Zulässigkeit des Spurwechsels. Scheint mir wirklich keine gute Idee zu sein. Dann doch lieber bei beiden die Funktion getaggt. Oder, wie wäre es denn hiermit: Ein Tag für’s Aussehen und eines (+ Spezifizierungen) für Funktion. Dann haben wir beides und müssen uns für keinen Fall auf irgendwelche Defaults verlassen. Natürlich entsteht dann eine gewisse Redundanz, aber die würde zumindest Fehlersuchtools helfen, potenzielle Fehler zu finden, wenn die Werte nicht zusammenzupassen scheinen.
Ich weiß nicht, woher das Missverständnis kommt, ich wolle “crossable” für Linienarten benutzen.
Mein Vorschlag ist ein Tag für Linienarten (für das ich in meinem vorletzten Post keinen Namen vorgeschlagen hatte) einzuführen. Zusätzlich sollte es ein Tag wie “crossable” geben, das bei Bedarf auch mit angehängtem Verkehrsmittel oder sonstigen “Conditional restrictions” verwendet werden kann und einen Teil der Funktion des Spurtrenners abbildet.
Das ist letztlich dasselbe wie ich vorschlage, mit dem einzigen Unterschied, dass bei dir der Mapper immer die ganze Palette an Spurtrenner-Funktionstags angeben muss. Meine Idee wäre, dass er diese nur dort zusätzlich zur Linienart angeben muss, wo die Bedeutung vom Normalfall abweicht - und sie anderswo lediglich “zur Sicherheit” angeben kann.
Naja, ich schließe aus deinen Posts #66, wo du sagtst, das Eintragen des Aussehens sei der einzige gangbare Weg und dass Mapper die Bedeutung dessen nicht kennen müssten (also nicht eintragen könnten), sowie #74, wo du von crossable, Linienmustern und Defaultwerten für selbige sprichst. Von beidem hab ich jetzt nirgends was finden können. Ansonsten ist ja alles schön, wenn alles nur Missverständnisse sind. Ich wäre trotzdem dafür, die Funktion im Allgemeinen und abweichendes Aussehen nur wenn nötig anzugeben und abgesehen davon sowieso dafür, die Spuren über einzelne Wege abzubilden.
@viw: Kein Nachteil zum Modell ohne eigenständige Spuren. Es gibt ja trotzdem noch den normalen highway Weg, also kann der Router zunächst allgemein annehmen, dass man sich auf diesem Weg befindet und dann zum nächstmöglichen Zeitpunkt eine Spur vorschlagen. Mehr bleibt ihm ohne Spurwege ja auch nicht übrig.