http://en.wikipedia.org/wiki/Road_surface_marking#Country_specific_information
Danke!
Spricht dafür, dass man länderspezifische Beziechnungen einbaut. Welche Syntax könnten sie haben? Ideen?
Das hat nicht zwangsweise miteinander zu tun, aber dürfte in den meisten Fällen passen. Wir brauchen dann nur ein Tag, das in den vergleichsweise wenigen Fällen, in denen dies nicht passt, ein übersteuern der Information aus turn:lanes=* ermöglicht.
Ich schlage dazu einen Key turn:physical=* bzw. turn:physical:lanes=* vor, dar definiert in welche Richtung die Spuren am Endpunkt des Weges weiterlaufen.
Die Werte können dem Key turn=* prinzipiell entsprechen, wobei jedem Wert einem Winkel entpricht. Der Router hat dann denjenigen weiterführenden Way zu verwenden, dessen Winkel am besten dazu passt. Diese Vorgehensweise halte ich für deutlich selektiver als jedem Wert einen vordefinierten Winkelbereich zuzuweisen.
Für wenige sehr komplizierte Fälle kann man auch zulassen, bei turn:physical direkt einen Winkel in Grad anzugeben.
Wenn dann klar ist, auf welchem weiterführenden Way eine Spur führt, wird in einigen Fällen auch noch unklar sein, auf welche der Spur des weiterfürrenden Way sie führt. Dazu schlage ich einen optionalen Key turn:input:lanes=* vor, der definiert, in welchem Winkel man in die Spur hineinfährt bzw. einbiegt. Werte prinzipiell analog zu turn:physical, jedoch kann es auch Spuren geben, in die am Beginn des Way entstehen: Hierfür schlage ich folgende Werte vor:
“split_from_right”, “split_from_left” und “new”
Damit kann der Router auch entscheiden, ob sich der Fahrer bei einer Spuraufteilung nur auf der passenden Seite halten muss oder ob ein aktiver Spurwechsel auf eine neu entstandene Spur nötig ist.
Die braucht man doch eigentlich nur, wenn die Tags das Aussehen und nicht die Funktion wiedergeben.
Das Routing würde durch die ganzen landesspezifischen Sonderregeln auch nicht gerade einfacher.
Du kommst nicht um landesspezifische Sonderregeln herum. Entweder für die Übersetzung von Aussehen in Funktion, oder (falls man die Funktion taggt) eben für die Übersetzung von Funktion in Aussehen. Und die Defaults für sowohl Rendering als auch Spurassistenz/Routing dürften sowieso landesspezifisch sein.
Selbst unter Berücksichtigung landesspezifischer Unterschiede bezweifle ich übrigens, dass eine Übersetzung von Funktion in Aussehen funktionieren würde. Die andere Richtung (Aussehen → Funktion) hingegen muss eindeutig sein, denn ein menschlicher Fahrer macht ja nichts anderes.
Daher halte ich das Eintragen der Art (Aussehen) der Markierung für den einzig gangbaren Weg. Das erspart dem Mapper übrigens auch, alle Details der Bedeutung einer Spurmarkierung zu kennen.
Ich würde mal davon ausgehen, dass wenn es Anwendungen gibt, die sich um die Darstellung der Straßenlinien geht, diese nicht aus den Ways holen wollen, sondern die exakte Geometrie der Straße aus einer Straßenfläche holen wollen. Dann wäre es (wie weiter oben in #45 angesprochen) sehr sinnvoll, dem Renderer an der Fläche zu sagen, wie er die Linie rendern soll und dem Router am Weg die Info zu lassen, die er braucht um ein Routing zusammen zu basteln.
Ein Überführen von Aussehen in Funktion und umgekehrt halte ich in einigen Fällen für unmöglich (ebenfalls weiter oben in #45 angedeutet).
Entspricht aber eigentlich nicht dem, was wir hier sonst so machen. Außerdem sind länderspezifische Sonderregeln, was das Aussehen angeht weniger problematisch, also solche, die die Funktion betreffen, denn da kann eine falsche Interpretation schnell zu groben Fehlern führen, vor allem, wenn der Fahrer (z.B. im Ausland) selbst nicht hundertprozentig die Bedeutung der Linientypen kennt und dann dem Navi vertraut.
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|
Steht wohl für eine schraffierte Fläche.
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