Für Routing optimieren?

marek_kleciak · 2012-10-18T11:16:49.000Z

Tordanik:

destination:lanes=A|A|B|B
type:divider = solid|dashed|double_solid|dashed|solid

So bekommt man die Flexibilität, mit der das :lanes-Tagging für sich wirbt - inklusive z.B. der Möglichkeit, dividers weitere Tags zu geben (Beispiel: colour:divider zur Unterscheidung zwischen gelben und weißen Fahrbahnmarkierungen).

+1

Kollege aus Polen ergänz dass man beispielsweise sowas machen könnte:

highway:lanes=cycleway|tertiary|tertiary
bicycle:lanes=yes|yes|no
maxspeed:lanes=30|50|80

aighes · 2012-10-18T11:27:47.000Z

marek kleciak:

destination:lanes=A|A|B|B
crossable=no|yes|no,no|yes|no

Tordanik:

destination:lanes=A|A|B|B
type:divider = solid|dashed|double_solid|dashed|solid

Technisch sehe da jetzt keinen Unterschied. Bei Mareks Idee würde ich das no,no durch ein einfaches no ersetzen. Das reicht aus. Diese Variante kann ohne Probleme weiter detailliert werden, wenn es Unterschiede gibt, ob man als Radfahrer oder als Autofahrer etc. unterwegs ist. Bspw. durch ein crossable:bicycle=… etc.

Beim Vorschlag von Tordanik sehe ich das Problem, dass in den Daten dann zwar steht, dass da eine durchgezogene Linie ist, doch es sagt nichts über dessen Bedeutung aus. Bspw. wäre es denkbar, dass dort zwar eine gestrichelte Linie ist, eine bestimmte Fahrzeuggruppe aber dennoch nicht die Spur wechseln darf. Ebenso wäre auch der umgekehrte Fall denkbar (durchgezogene Linie, die von einer Gruppe überfahren werden darf).

marek_kleciak · 2012-10-18T11:49:11.000Z

aighes:

Bei Mareks Idee würde ich das no,no durch ein einfaches no ersetzen. Das reicht aus.

Die Idee ist vom Immagic.
Wie auch immer: ich denke es reicht nicht aus, weil es eine andere Straßenbesichlderung ist, die wir auch uunterschiedlich rendern wollen. Wenn schon, dann schon

aighes:

Bspw. wäre es denkbar, dass dort zwar eine gestrichelte Linie ist, eine bestimmte Fahrzeuggruppe aber dennoch nicht die Spur wechseln darf. Ebenso wäre auch der umgekehrte Fall denkbar (durchgezogene Linie, die von einer Gruppe überfahren werden darf).

Guter Hinweis.
Was kann man dagegen tun?

aighes · 2012-10-18T12:28:20.000Z

Naja…ich denke man müsste zu einer generellen Lösung kommen, die Routing und Rendering trennt. Für das Routing braucht man Daten in einem Routinggraph-ähnlichem Objekt (way) und für das Rendering geht die Reise eher in Richtung Flächen.

Das hat natürlich zur Folge, dass man Sachen doppelt eintragen muss, weil sie für beide Bereiche wichtig sind, aber jeweils in einer anderen Weise. Sprich man wird in der Darstellung für den Renderer die Info platzieren müssen, dass dort eine durchgezogene Linie ist und in der Darstellung für den Router muss man die Info platzieren, dass der LKW nur auf der rechten Spur fahren darf.

Von daher sollte man meiner Meinung nach die Gedanken in Richtung Flächenmapping und Linienmapping nicht allzu isoliert sehen, sondern eher als gemeinsame Lösung betrachten und überlegen, in welcher Darstellungsform welche Informationen benötigt werden.

marek_kleciak · 2012-10-18T13:04:11.000Z

aighes:

Von daher sollte man meiner Meinung nach die Gedanken in Richtung Flächenmapping und Linienmapping nicht allzu isoliert sehen, sondern eher als gemeinsame Lösung betrachten und überlegen, in welcher Darstellungsform welche Informationen benötigt werden.

Genau so ist es, da kämpfen wir uns langsam durch

Nochmal die einladung nach Garching, ich habe kurz Intro und die Agenda ergänzt: http://wiki.openstreetmap.org/wiki/Navigation_and_Micromapping_Workshop_Garching

hurdygurdyman · 2012-10-18T13:38:21.000Z

aighes:

Mir gefällt das Polygon mit highway=junction nicht wirklich.

Wofür braucht man das Polygon und warum reicht es nicht, die Straßenfläche als area:highway=* zu erfassen. Ein Problem wird der Renderer bekommen, der so wie jetzt auch schon bei den Ways üblich auch die area:highway=primary-Flächen rot malen will und die area:highway=residential-Flächen weiß malen will.

Wenn es darum geht, alle Bestandteile eine Kreuzung zusammenzufassen, dann denke ich wäre eine Relation besser geeignet. Wenn man nur in den Daten festhalten will, dass diese Straßenfläche eine Kreuzung ist, dann wäre meiner Meinung nach ein Zusatztag zu area:highway deutlich besser.

BTW: Man sollte noch dazusagen, dass man für das AeroWest-Bild die Projektion auf GausKrüger 3 stellen muss

Wenn es eine andere Lösung statt highway=junction gibt, um kreuzende highways ohne gemeinsamen node bzw. relation=restriction zu ermöglichen, können wir darauf verzichten.

Erste Idee:
junction:lanes=yes als zusätzlicher tag bedeutet, dass der highway mit diesem tag andere highway=* kreuzen darf, ohne mit diesem einen gemeinsamen node zu haben. QA-tools (OSMI, keepright! usw.) werten dies dann nicht als Fehler aus.
GaussKrüger 3 hatte ich als "Allgemeinbildung für Aerowest-Bilder vorausgesetzt

errt · 2012-10-18T14:26:30.000Z

Tordanik:

destination:lanes=A|A|B|B
type:divider = solid|dashed|double_solid|dashed|solid

So bekommt man die Flexibilität, mit der das :lanes-Tagging für sich wirbt - inklusive z.B. der Möglichkeit, dividers weitere Tags zu geben (Beispiel: colour:divider zur Unterscheidung zwischen gelben und weißen Fahrbahnmarkierungen).

Dann aber eher divider:type und divider:colour, oder?

Tordanik · 2012-10-18T14:35:53.000Z

errt:

Tordanik:

destination:lanes=A|A|B|B
type:divider = solid|dashed|double_solid|dashed|solid

So bekommt man die Flexibilität, mit der das :lanes-Tagging für sich wirbt - inklusive z.B. der Möglichkeit, dividers weitere Tags zu geben (Beispiel: colour:divider zur Unterscheidung zwischen gelben und weißen Fahrbahnmarkierungen).

Dann aber eher divider:type und divider:colour, oder?

Mir wäre das egal. Allerdings hat sich das Lanes-Proposal für width:lanes, destination:lanes, maxspeed:lanes, … entschieden, und nicht etwa lanes:width etc.

Daher passt es dann irgendwie besser, auch colour:divider (oder :dividers?) und so weiter zu nehmen.

slhh · 2012-10-18T23:44:02.000Z

Da bei right und left noch zu definieren wäre, ob ich dieses auf den Weg oder die tatsächliche Fahrtrichtung bezieht, wäre vielleicht auch
change:lanes=>|<>|<|>|<>|<
oder
change:lange=+1|-1,+1|-1|+1|-1,+1|-1
eine Alternative.

Insbesondere für Straßen mit Gegenverkehr könnte man auch die Werte “in” und “out” (Spurwechsel zur Straßenmitte bzw. von dieser weg) als alternative zu “left” und “right” zulassen.

Man hätte auch, den Vorteil, dass die Tags die Funktion wiedergeben und nicht nur das Aussehen der Trennlinie. Man sollte auch daran denken dass es landesspezifische Abweichungen in der Bedeutung der Linientypen geben kann.

aighes · 2012-10-18T23:53:02.000Z

hurdygurdyman:

GaussKrüger 3 hatte ich als "Allgemeinbildung für Aerowest-Bilder vorausgesetzt

GaussKrüger, ja…aber die Nummer variiert schon innerhalb Deutschlands

Wenn es bei der highway=junction-Fläche nur um Fehlertools geht, dann sollte man diese weglassen, bzw. das normale Tagging für flächige Straßen verwenden.

marek_kleciak · 2012-10-19T00:52:44.000Z

slhh:

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

Interessanter Hinweis. Ein Beispiel dafür?

viw · 2012-10-19T06:05:19.000Z

Vielleicht Schweden mit der benutzung des Seitenstreifens bei Überholvorgängen.

hurdygurdyman · 2012-10-19T07:03:08.000Z

slhh:

Da die abweichende Anzahl von Dividern und Lanes eventuell einige Mapper verwirren wird, wäre es vielleicht besser statt der Trennlinie die Spurwechselmöglichkeit anzugeben, z.B.:
change:lanes=right|both|left|right|both|left
…

+1. Gute Idee. Entspricht dem bewährten Schema des “sprechenden” value. Sonderzeichen sind zwar schneller getippt, abstrahieren aber. Ebenso erscheint mir +1 usw. zu abstrakt.

hurdygurdyman · 2012-10-19T07:07:20.000Z

aighes:

…
Wenn es bei der highway=junction-Fläche nur um Fehlertools geht, dann sollte man diese weglassen, bzw. das normale Tagging für flächige Straßen verwenden.

Ok, was hältst du/haltet ihr von dem Vorschlag mit junction:lanes=yes am way, um den Zwang des gemeinsamen nodes bei kreuzenden highway auszuhebeln?
http://forum.openstreetmap.org/viewtopic.php?pid=283045#p283045

imagic · 2012-10-19T09:27:54.000Z

Hi erstmal - ich gebe hier auch mal meinen Senf dazu.

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

marek kleciak:

Idee 1 (geht auf Immagic zurück):

crossable=yes - gestrichelt
crossable=no - durchgezogen
crossable=no,no - Doppellinie
crossable=no,yes - solid,dashed
crossable=yes,no - dashed,solid

So war das nicht gedacht. Mit crossable:lanes wollte ich die legalen Beschränkungen des Spurwechsels angeben. Also immer zwei pro Spur, wobei man auf den äußeren Spuren darauf verzichten könnte.

Beispiel:
crossable:lanes=no,yes|yes,no|yes,no|no,no

Spur 4 (am weitesten links): nur Wechsel nach rechts erlaubt (links würde die Fahrbahn verlassen, könnte man weglassen)
Spur 3: nach links erlaubt, nicht nach rechts
Spur 2: nach links erlaubt, nicht nach rechts
Spur 1: kein Spurwechsel erlaubt

Kann man sich so vorstellen: | 4 : 3 |: 2 | 1 |

Der Grund warum ich das so andachte damals war, dass ich bei allen :lanes-Schlüsseln die selbe Anzahl an Werte haben will.

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.

aighes:

Wofür braucht man das Polygon und warum reicht es nicht, die Straßenfläche als area:highway=* zu erfassen.

Der Schlüssel ist egal. Ob highway=junction oder area:highway macht keinen Unterschied. Der Punkt ist, dass der Editor wissen muss, dass er bei xxx=yyy keinen Fehler wegen überschneidender Wege anzeigen darf, wenn diese (am selben Layer) innerhalb der Fläche sind.

Tordanik:

destination:lanes=A|A|B|B
type:divider = solid|dashed|double_solid|dashed|solid

So bekommt man die Flexibilität, mit der das :lanes-Tagging für sich wirbt - inklusive z.B. der Möglichkeit, dividers weitere Tags zu geben (Beispiel: colour:divider zur Unterscheidung zwischen gelben und weißen Fahrbahnmarkierungen).

Diese Idee gefällt mir prinzipiell gut, nur bin ich noch nicht 100% davon überzeugt, a) dass wir wirklich das Aussehen taggen müssen und b) dass wir einen zweiten Suffix einführen sollen/müssen. Auch der Schlüssel type:divider ist irgendwie … naja… aber ich habe auch nichts besseres bei der Hand. Trotzdem: gefällt mir.

slhh:

change:lanes=>|<>|<|>|<>|<
oder
change:lange=+1|-1,+1|-1|+1|-1,+1|-1

Eines der Grundprinzipien von OSM sind lesbare Tags. Ob das hier zutrifft?

slhh:

change:lanes=right|both|left|right|both|left

Das ist jetzt genau das selbe wie crossable:lanes. Mit left/right/both gefällt es mir aber sogar besser!

slhh:

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

Deswegen bin ich eher dafür den Effekt zu mappen als das Aussehen.

hurdygurdyman:

Ok, was hältst du/haltet ihr von dem Vorschlag mit junction:lanes=yes am way, um den Zwang des gemeinsamen nodes bei kreuzenden highway auszuhebeln?

Das hätte den Nachteil, dass man das auf jeden Weg draufgeben muss und es sich z.B. wenn jemand Wege kombiniert und kopiert leicht “fortpflanzt”. Bei einer Fläche passiert dir das nicht so schnell. Denke an Leute die keine Ahnung von diesen Tags haben. Bei einer Fläche erkennen sie schnell: ok, das ist wohl die Kreuzung. Bei junction:lanes=yes haben sie keine Ahnung und ignorieren den Tag. Langer Rede kurzer Sinn: ist fehleranfälliger.

Soviel erstmal von mir.
Martin

aighes · 2012-10-19T09:34:51.000Z

hurdygurdyman:

aighes:

…
Wenn es bei der highway=junction-Fläche nur um Fehlertools geht, dann sollte man diese weglassen, bzw. das normale Tagging für flächige Straßen verwenden.

Ok, was hältst du/haltet ihr von dem Vorschlag mit junction:lanes=yes am way, um den Zwang des gemeinsamen nodes bei kreuzenden highway auszuhebeln?
http://forum.openstreetmap.org/viewtopic.php?pid=283045#p283045

Ein Schlüssel am Weg halte ich für eine gute Sache. Ich würde eher in Anlehnung an junction=roundabout junction=crossing vorschlagen.

hurdygurdyman · 2012-10-19T11:07:45.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ß.

Aber warum soll man nicht darüber nachdenken, ob der Schlüssel nicht auch noch einen anderen Zweck erfüllen kann Auswertungen könnten doch aus dem key/value erkennen, wohin man am nächsten Kreuzungspunkt mit anderen highway=+ abzweigen kann

imagic:

aighes:

Wofür braucht man das Polygon und warum reicht es nicht, die Straßenfläche als area:highway=* zu erfassen.

Der Schlüssel ist egal. Ob highway=junction oder area:highway macht keinen Unterschied. Der Punkt ist, dass der Editor wissen muss, dass er bei xxx=yyy keinen Fehler wegen überschneidender Wege anzeigen darf, wenn diese (am selben Layer) innerhalb der Fläche sind.

area:highway kann überall auch außerhalb von Kreuzungsbereichen verwendet werden, wenn man eine Straßenfläche darstellen will. Da kann dann kein Router/Renderer/QA unterscheiden, ob es ein Fehler ist oder nicht.

imagic:

hurdygurdyman:

Ok, was hältst du/haltet ihr von dem Vorschlag mit junction:lanes=yes am way, um den Zwang des gemeinsamen nodes bei kreuzenden highway auszuhebeln?

Das hätte den Nachteil, dass man das auf jeden Weg draufgeben muss und es sich z.B. wenn jemand Wege kombiniert und kopiert leicht “fortpflanzt”. Bei einer Fläche passiert dir das nicht so schnell. Denke an Leute die keine Ahnung von diesen Tags haben. Bei einer Fläche erkennen sie schnell: ok, das ist wohl die Kreuzung. Bei junction:lanes=yes haben sie keine Ahnung und ignorieren den Tag. Langer Rede kurzer Sinn: ist fehleranfälliger.

Die Gefahr des falschen “Fortpflanzens” hat man schon jetzt bei x Fällen. Ich denke, dass Leute ohne Ahnung sich an komplexe Kreuzungen eher noch nicht rantrauen. Da sollte dann die Wiki ein klares how to anbieten, um Fehleranfälligkeit zu minimieren, wobei erst einfache Fälle und dann komplexere Beispiele auch bildhaft vorgestellt werden sollten.

hurdygurdyman · 2012-10-19T11:16:57.000Z

aighes:

Ein Schlüssel am Weg halte ich für eine gute Sache. Ich würde eher in Anlehnung an junction=roundabout junction=crossing vorschlagen.

Auch wenn ich mal bei meinem Versuch, Einzelspuren zu erfassen, die Idee mit der junction-Fläche propagierte, sehe ich in der Lösung junction:lane=yes oder ähnlichem mittlerweile auch Vorteile bei der Auswertung durch QA und Router.
QA müssen nicht erst prüfen, ob ein Kreuzungspunkt von zwei highways in einer Fläche junction liegt, sondern erkennen gleich am way: "Der ist junction:lane=yes, also kann ‘gemeinsamer Kreuzungspunkt ja/nein-Prüfung’ entfallen.
Für Router entfallen Kreuzungspunkte, an denen sie prüfen müssen, ob eine restriction vorliegt.

Jetzt müssen wir uns nur noch entscheiden, was uns lieber ist…

marek_kleciak · 2012-10-19T11:28:13.000Z

Für Router entfallen Kreuzungspunkte, an denen sie prüfen müssen, ob eine restriction vorliegt

Der Vorteil ist also klar. Weniger Relationen = weniger potentielle Fehler. Die gemeinsamen Punkte bestehen trotzdem, also können wir anzeigen, dass sich Straßen schneiden und das auf einem Display beliebiger Navigation anzeigen.

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