Für Routing optimieren?

slhh · 2012-10-19T23:30:11.000Z

marek kleciak:

slhh:

Man sollte auch daran denken dass es landesspezifische Abweichungen in der Bedeutung der Linientypen geben kann.

Interessanter Hinweis. Ein Beispiel dafür?

http://en.wikipedia.org/wiki/Road_surface_marking#Country_specific_information

marek_kleciak · 2012-10-19T23:36:55.000Z

Danke!
Spricht dafür, dass man länderspezifische Beziechnungen einbaut. Welche Syntax könnten sie haben? Ideen?

slhh · 2012-10-20T00:32:49.000Z

imagic:

hurdygurdyman:

Es wäre dabei zu prüfen, ob die Informationen aus turn:lanes=left|through|right usw. als Alternative oder anstelle von relation=restriction verwertbar sind

Nope - keine gute Idee! Der Schlüssel turn ist wirklich nur dazu gedacht anzuzeigen, was man auf der Straße oder auf einem Schild sieht. Das hat nicht zwangsweise etwas damit zu tun, was man dann machen darf/muß.

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.

slhh · 2012-10-20T01:03:42.000Z

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.

slhh · 2012-10-20T01:14:07.000Z

marek kleciak:

Danke!
Spricht dafür, dass man länderspezifische Beziechnungen einbaut. Welche Syntax könnten sie haben? Ideen?

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.

Tordanik · 2012-10-20T08:11:49.000Z

slhh:

marek kleciak:

Danke!
Spricht dafür, dass man länderspezifische Beziechnungen einbaut. Welche Syntax könnten sie haben? Ideen?

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.

aighes · 2012-10-20T08:19:06.000Z

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

errt · 2012-10-20T11:06:37.000Z

Tordanik:

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.

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.

MasiMaster · 2012-10-20T11:56:19.000Z

imagic:

MasiMaster:

destination:lanes=|A:A||B:B|

Die Idee mit den unterschiedlichen Zeichen kam schon mehrmals auf, hat nur zwei Nachteile:

Kaum intuitiv, vor allem wenn dann noch so Zeichen wie # dazu kommen. (Kann mich nicht mehr erinnern wofür das gedacht war).

Bei welchen :lanes-Schlüssel sollen sie verwendet werden? Es können beliebige viele sein.

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.

Tordanik · 2012-10-20T12:32:00.000Z

aighes:

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

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.

errt:

Tordanik:

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.

Entspricht aber eigentlich nicht dem, was wir hier sonst so machen.

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.

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.

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.

aighes · 2012-10-20T14:27:21.000Z

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.

marek_kleciak · 2012-10-20T17:39:24.000Z

aighes:

Sprich fürs Routing braucht man crossing:=, 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.

errt · 2012-10-20T19:03:50.000Z

Tordanik:

errt:

Tordanik:

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.

Entspricht aber eigentlich nicht dem, was wir hier sonst so machen.

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.

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.

Tordanik:

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.

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.

Tordanik · 2012-10-24T23:51:56.000Z

aighes:

Spontan fallen mir Busspuren ein. […] Oder die Radwegbegrenzung auf der Straße. […]

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.

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

hurdygurdyman · 2012-10-25T03:32:53.000Z

Tordanik:

…
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:

imagic:

Zusammen mit einem Kollegen (“It’s so funny” ; Johan) aus den Niederlanden habe ich mal zu Versuchszwecken begonnen einige Stellen mit change:lanes zu taggen. Von den ursprünglichen Werten left, right, … sind wir eher wieder abgekommen. Johan hat richtigerweise bemerkt, dass wir ja nur dann taggen, wenn ein Wechsel nicht erlaubt ist. Daher probieren wir es jetzt einmal mit folgenden Werten:

yes (Wechsel erlaubt; äquivalent zu both)

not_right (nicht nach rechts; äquivalent zu left)

not_left (nicht nach links; äquivalent zu right)

no (kein Wechsel erlaubt; äquivalent zu none)

Wenn wir ein paar Erfahrungswerte haben, melde ich mich wieder.

Ob das jetzt “crossable” oder “change:lanes” heißt… Ich denke, “change:lanes” ist selbsterklärender.

errt · 2012-10-25T07:44:42.000Z

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

hurdygurdyman · 2012-10-25T07:45:51.000Z

imagic:

hurdygurdyman:

Es wäre dabei zu prüfen, ob die Informationen aus turn:lanes=left|through|right usw. als Alternative oder anstelle von relation=restriction verwertbar sind

Nope - keine gute Idee! Der Schlüssel turn ist wirklich nur dazu gedacht anzuzeigen, was man auf der Straße oder auf einem Schild sieht. Das hat nicht zwangsweise etwas damit zu tun, was man dann machen darf/muß.
…

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.

chris66 · 2012-10-25T08:02:39.000Z

slhh:

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.

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.

hurdygurdyman · 2012-10-25T09:05:58.000Z

chris66:

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?

viw · 2012-10-25T09:37:01.000Z

hurdygurdyman:

chris66:

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