Für Routing optimieren?

Hallo,

bei OSRM werden die Richtungsangaben m.W. aus dem Schnittwinkel der beteiligten Wege bzw. genauer der beiden Segmente (A,C)->(C,B) ermittelt.

Am Beispiel der ersten Bedingung im Codebeispiel unten: Winkel größer gleich 23° und kleiner 67° => Scharf rechts abbiegen. Für die anderen Bedingungen entsprechend vorgehen, sollte einigermaßen klar sein. Falls keine der Bedingungen passt, wird ein "Wenden" vorgeschlagen.

Bevor jetzt der Einwand kommt: wir mappen nicht für den Router! - das sollte nur zur groben Veranschaulichung dienen, wie die Richtungsangaben überhaupt zustande kommen.

␣␣␣static␣inline␣double␣GetTurnDirectionOfInstruction(␣const␣double␣angle␣)␣{
if(angle␣>=␣23␣&&␣angle␣<␣67)␣{
return␣TurnSharpRight;
}
if␣(angle␣>=␣67␣&&␣angle␣<␣113)␣{
return␣TurnRight;
}
if␣(angle␣>=␣113␣&&␣angle␣<␣158)␣{
return␣TurnSlightRight;
}
if␣(angle␣>=␣158␣&&␣angle␣<␣202)␣{
return␣GoStraight;
}
if␣(angle␣>=␣202␣&&␣angle␣<␣248)␣{
return␣TurnSlightLeft;
}
if␣(angle␣>=␣248␣&&␣angle␣<␣292)␣{
return␣TurnLeft;
}
if␣(angle␣>=␣292␣&&␣angle␣<␣336)␣{
return␣TurnSharpLeft;
}
return␣UTurn;
}

Gruß,
mmd

Bevor jetzt der Einwand kommt: wir mappen nicht für den Router!

Das ist schon klar. Wenn da eine längere Kurve ist, kommt die natürlich in die Karte und der Router muss das irgendwie auswerten. Ein Tag a la "turn:lanes=left|right" sollte dem Router ja in den meisten Fällen die nötige Information geben können.
Trotzdem bräuchte der Router für solche größeren Kreuzungen wahrscheinlich eine Methode den "Gesamtwinkel" über mehrere Knoten hinweg festzustellen.

mueschel wrote:

Ist das einzig eine Sache der Routing-Software, oder können wir beim Tagging irgendetwas tun?

Beides.
Was man tun kann:

• Fleissig das destination Tag mappen.
  
• Kein Separat-Spurmapping
  

Chris

Ich würde vorschlagen, für das Problem mit OSRM einen Bugreport aufzumachen, siehe Post #16 im Nachbarthread.

turn:lanes und destination scheinen aktuell gar nicht berücksichtigt zu werden. Ob es so einfach ist, einen Gesamtwinkel zu bestimmen, ist mir nicht klar. Wegen turn restrictions könnten die Fahrspuren einer Kreuzung ja in mehrere kurze Abschnitte zerteilt worden sein, so dass erst mehrere Wege zusammen das "big picture" ergeben.
Vielleicht ließe sich die Information "highway-Typ ändert sich" (von trunk auf trunk_link, etc.) noch berücksichtigen?

Gibt es eigentlich schon irgendwelche langfristigen Ideen zu diesem Problem? Bei kleinen Kreuzungen ist das ganze kein Problem. Spur-mapping kommt hier nicht in Frage und die Abbiegebeziehungen sind einfach und gut zu detektieren. Für komplexere Kreuzungen muss man in vielen Fällen wohl mit Spurmapping leben, alleine schon aus Gründen der genauen Abbildung (ich meine nicht Kartendarstellung) der Realität. Um gutes Routing zu erhalten sehe ich mehrere Möglichkeiten (nur mal ein paar Ideen niedergeschrieben, ausgereift ist da noch nichts):

- Kreuzungen werden generell auf einen Knoten in der Mitte reduziert wie in einem Proposal gewünscht - schön für Router aber für alles andere nicht zu gebrauchen. Zumal die Winkel der einzelnen Wege bei breiten Straßen komplett verzerrt werden.
- Router werden so intelligent, dass sie alle Kreuzungen selbstständig detektieren. Das ist wohl Wunschdenken und wird nicht realisiert werden können.
- Es wird flächendeckend mit turn:lanes=* gearbeitet und Router benutzen diese Information um die möglichen Richtungen herauszufinden.
- Es wird eine Relation eingeführt, die alle Knoten einer Kreuzung zusammenfasst. Der Router kann dann die Abbiegerichtung ermitteln, indem er den Winkel zwischen dem letzten Weg vor dieser Relation und dem ersten Weg nach dieser Relation bestimmt.

Ich persönlich halte eine Kombination aus den letzten beiden für das Erfolgversprechendste. Wahrscheinlich ließe sich das auch gut kombinieren mit den vorgeschlagenen Highway-Areas.

mmd wrote:

Vielleicht ließe sich die Information "highway-Typ ändert sich" (von trunk auf trunk_link, etc.) noch berücksichtigen?

Das macht der Garmin Router automatisch (wenn man die Standard-Garmin-Straßentypen "Ramp" nimmt).

Das Ansageverhalten ist dann für Autobahn Auf-/Abfahrten optimiert.

Chris

chris66 wrote:

mmd wrote:

Vielleicht ließe sich die Information "highway-Typ ändert sich" (von trunk auf trunk_link, etc.) noch berücksichtigen?

Das macht der Garmin Router automatisch (wenn man die Standard-Garmin-Straßentypen "Ramp" nimmt).

Welchem OSM-Tag entspricht das? Bzw. welche Garmin-Karte setzt das richtig um von motorway_link bzw. trunk_link?

Hi Muschel, betreffend #6 -
es ist zwar offtopic aber es betrifft Deine Überlegungen:
Komm nach Garching, da werden wir eine solche Lösung diskutieren wenn wir über Routing und Autonavigation sprechen..

chris66 wrote:

Was man tun kann:

• Fleissig das destination Tag mappen.
  
• Kein Separat-Spurmapping
  

Das halte ich auch für am sinnvollsten. Sinnvollere Routenanweisungen stehen im Moment bei OSRM aber nicht ganz oben auf der Prioritätsliste.

mueschel wrote:

chris66 wrote:

mmd wrote:

Vielleicht ließe sich die Information "highway-Typ ändert sich" (von trunk auf trunk_link, etc.) noch berücksichtigen?

Das macht der Garmin Router automatisch (wenn man die Standard-Garmin-Straßentypen "Ramp" nimmt).

Welchem OSM-Tag entspricht das? Bzw. welche Garmin-Karte setzt das richtig um von motorway_link bzw. trunk_link?

Der Standard mkgmap-Stil (und alle Karten die diesen nutzen) macht die Zuordnung folgendermaßen:

motorway_link␣␣->␣0x09␣␣"Ramp␣major"
trunk_link␣␣␣␣␣->␣0x09␣␣"Ramp␣major"
primary_link␣␣␣->␣0x08␣␣"Ramp␣minor"
secondary_link␣->␣0x08␣␣"Ramp␣minor"
tertiary_link␣␣->␣0x08␣␣"Ramp␣minor"

DennisL wrote:

chris66 wrote:

• Kein Separat-Spurmapping
  

Das halte ich auch für am sinnvollsten.

Das ist dann aber genau genommen wieder "Mapping für den Router". Wenn detailgetreu gemappt werden soll, z.B. auch für Blinde, dann können große Kreuzungen nicht nur aus zwei Straßen bestehen. Alles was über einfache Spuren hinausgeht wird dann zwangsläufig zu Problemen führen.

Leider bin ich kein Experte was solche Suchalgorithmen angeht...

DennisL wrote:

chris66 wrote:

• Kein Separat-Spurmapping
  

Das halte ich auch für am sinnvollsten.

Ich halte es nicht für sinnvoll, darauf zu verzichten, besonders nicht dann, wenn da noch eine Verkehrsinsel zwischen den Spuren ist.

Gruß,
Mondschein

Verkehrsinsel ist ok (bauliche Trennung).

So, hier mal ein Test mit der Implementierung der destination-Auswertung für Garmin (Nüvi 250).

Folgendes muss dazu in die "lines" Datei eingefügt werden:

#␣Set␣the␣routing␣direction
(highway=motorway|highway=motorway_link)␣&␣destination=*␣{␣add␣display_name␣=␣'${ref}␣(${destination})'␣}
(highway=trunk|highway=trunk_link)␣␣␣␣␣␣␣&␣destination=*␣{␣add␣display_name␣=␣'${ref}␣(${destination})'␣}

#␣Set␣highway␣names␣to␣include␣the␣reference␣if␣there␣is␣one

Testobjekt: Kreuz Münster Süd (Ist vollständig destination-gemappt ).

(a) von A43 West kommend nach A1 Richtung Bremen

Ansage: "nach 300 Metern rechts abfahren, dann links halten"

(b) von A43 West kommend nach A1 Richtung Dortmund

Ansage: "nach 300 Metern rechts abfahren, dann rechts halten"

Damit das funktioniert müssen für xyz_link die Garmin Typen "Rampe" 0x08 und 0x09 benutzt werden, außerdem
muss das erste nicht-link-Straßenstück nach den Abbiegespuren auch ein destination-Tag tragen, da der Garmin
Router nur dies auswertet.

außerdem muss das erste nicht-link-Straßenstück nach den Abbiegespuren auch ein destination-Tag tragen, da der Garmin
Router nur dies auswertet.

Da man den Mappern nicht zumuten kann für Garmin zu mappen bietet sich hier eine Vorverarbeitung an. Eine erste Version habe ich nun erstellt. Der Algorithmus ist simpel:
Für alle hw=*link mit gesetztem destination wird der nächstfolgende Way gesucht. Wenn dies ein motorway oder (oneway-)trunk ohne destination Tag ist, wird die destination aus dem link rüberkopiert.

Werde damit nun mal eine Nüvikarte bauen und Testen.

Auszug aus dem Log:

File␣:␣10000052.osm

id␣hw␣␣␣␣␣␣␣␣␣␣␣␣␣ref␣␣␣␣␣␣dest␣(*␣=␣added␣by␣tool)
----------␣--------------␣--------␣--------------------
3993952␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Wiesbaden;␣Niedernha
4007900␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Limburg-Nord;␣Diez;
4188884␣motorway_link␣␣A␣60␣␣␣␣␣Frankfurt␣a.M.;Darms
4188885␣motorway␣␣␣␣␣␣␣A␣63␣␣␣␣␣*Kaiserslautern;Ludw
4188886␣motorway_link␣␣A␣60␣␣␣␣␣Frankfurt␣a.M.;Darms
4188887␣motorway_link␣␣A␣63␣␣␣␣␣Kaiserslautern;Ludwi
4208767␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Mainz-Kastel;␣Wiesba
4443859␣motorway_link␣␣18␣␣␣␣␣␣␣Wattenheim;␣Eisenber
4446759␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Kaiserslautern-West;
4453461␣motorway_link␣␣12␣␣␣␣␣␣␣Frankfurt;␣Mainz;␣In
4454068␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Kaiserslautern;␣Darm
4514843␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Mainz-Mombach;␣-Inne
4527121␣motorway_link␣␣A␣63␣␣␣␣␣Frankfurt␣am␣Main;Ma
4541849␣motorway_link␣␣B␣50␣␣␣␣␣Rheinböllen;␣Trier;
4854593␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Ludwigshafen;Mainz;B
4854595␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Frankfurt;Koblenz
4859933␣motorway␣␣␣␣␣␣␣A␣63␣␣␣␣␣*Kaiserslautern;Ludw
5123492␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Kaiserslautern-Einsi
5201093␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Idstein;␣Usingen;␣Ba
5201206␣motorway_link␣␣B␣255␣␣␣␣Montabaur;␣Koblenz;
5233728␣motorway_link␣␣A␣62␣␣␣␣␣Trier;Birkenfeld;Kus
5233730␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Pirmasens;Landstuhl-
5233731␣motorway_link␣␣A␣62␣␣␣␣␣Pirmasens;Landstuhl-
5536512␣motorway␣␣␣␣␣␣␣A␣65␣␣␣␣␣*Frankenthal;␣Mutter
7034887␣motorway_link␣␣A␣61␣␣␣␣␣Koblenz
7034893␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Saarbrücken;␣Kaiser
7034901␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Koblenz;␣Karlsruhe;
7034906␣motorway_link␣␣A␣6␣␣␣␣␣␣Mannheim;␣Ludwigshaf
7034910␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Koblenz
9046916␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Neustadt/Weinstr.;␣F
9046917␣motorway_link␣␣A␣65␣␣␣␣␣Frankenthal;␣Mutters
9046919␣motorway_link␣␣A␣65␣␣␣␣␣Neustadt/Weinstr.
9047704␣motorway_link␣␣A␣65␣␣␣␣␣Mutterstadt-Nord
9052756␣motorway_link␣␣A␣61␣␣␣␣␣Karlsruhe;␣Neustadt/
9053750␣motorway_link␣␣A␣6␣␣␣␣␣␣Frankfurt␣a.␣M.;␣Fra
9641721␣motorway_link␣␣A␣48␣␣␣␣␣Trier;␣Koblenz
9891359␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Ludwigshafen;Alzey
10713286␣motorway␣␣␣␣␣␣␣A␣61␣␣␣␣␣*Bonn;Köln
15382502␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Kaiserslautern-Centr
21827862␣motorway_link␣␣A␣3␣␣␣␣␣␣Limburg-Süd
23069518␣motorway␣␣␣␣␣␣␣A␣650␣␣␣␣*Bad␣Dürkheim
23377824␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Gundersheim;␣Westhof
23483148␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Mörstadt
23486653␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Alzey;␣Gau-Odernheim
23701466␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Mainz-Gonsenheim
23763027␣motorway_link␣␣A␣643␣␣␣␣Trier;␣Koblenz;␣Bing
23781848␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Limburg-Nord;␣Diez;
24033964␣motorway_link␣␣A␣650␣␣␣␣Bad␣Dürkheim
24033966␣motorway_link␣␣A␣650␣␣␣␣Ludwigshafen
24033967␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Ludwigshafen;␣Bad␣DÃ
24033974␣motorway_link␣␣A␣650␣␣␣␣Bad␣Dürkheim
24033976␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Bad␣Dürkheim;␣Mannh
24223240␣motorway␣␣␣␣␣␣␣A␣643␣␣␣␣*Koblenz;␣Bingen;␣Ma
24351895␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Ludwigshafen;Mainz;F
24351899␣motorway␣␣␣␣␣␣␣A␣48␣␣␣␣␣*Frankfurt;Koblenz
24442677␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Mörstadt;␣Worms-Nor
24442678␣trunk␣␣␣␣␣␣␣␣␣␣L␣425␣␣␣␣*Worms-Nord;␣Worms-A
24462530␣motorway␣␣␣␣␣␣␣A␣63␣␣␣␣␣*Kaiserlautern
24462537␣motorway_link␣␣A␣63␣␣␣␣␣Köln;Koblenz;Ludwig
24462540␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Ludwigshafen
24462541␣motorway_link␣␣A␣61␣␣␣␣␣Kaiserlautern
24462542␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Köln;Koblenz
24462544␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Kaiserlautern
24475781␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Bad␣Camberg;␣Aarberg
24502053␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Ludwigshafen;␣Bad␣Kr
24620724␣motorway␣␣␣␣␣␣␣A␣6␣␣␣␣␣␣*Mannheim;Karlsruhe;
24620766␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Ramstein-Miesenbach;
24621264␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Mehlingen
24621371␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Kaiserlautern-Ost
24621391␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Enkenbach-Alsenborn;
24740193␣motorway_link␣␣B␣50␣␣␣␣␣Gensingen;␣Bingen-Sp
24979621␣motorway_link␣␣A␣63␣␣␣␣␣Kaiserslautern
25354792␣motorway_link␣␣B␣50␣␣␣␣␣Bingen-Mitte;␣St.␣Go
25384630␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Bornheim;␣Flonheim
25601028␣motorway_link␣␣47␣␣␣␣␣␣␣Waldlaubersheim;␣Gul
25819360␣motorway␣␣␣␣␣␣␣A␣48␣␣␣␣␣*Frankfurt;Koblenz
25849190␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Trier;Koblenz
25849191␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Trier;Koblenz
25849192␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Trier;Koblenz
25849193␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Trier;Koblenz
25879219␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Worms-Nord;␣Worms-Ab
26724719␣trunk␣␣␣␣␣␣␣␣␣␣B␣455␣␣␣␣*Wiesbaden-Stadtmitt
27483967␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Bad␣Dürkheim
27488798␣trunk␣␣␣␣␣␣␣␣␣␣L␣425␣␣␣␣*Mörstadt
27594972␣motorway␣␣␣␣␣␣␣A␣65␣␣␣␣␣*Neustadt/Weinstr.
27879282␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Saarbrücken;␣Kaiser
27896161␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Mutterstadt-Nord
27896176␣motorway␣␣␣␣␣␣␣A␣65␣␣␣␣␣*Mutterstadt-Nord
27896186␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Neustadt/Weinstr.
27896356␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Speyer;␣Neustadt/Wei
28280344␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Köln;Koblenz
28280358␣motorway␣␣␣␣␣␣␣A␣63␣␣␣␣␣*Kaiserlautern
28505907␣motorway␣␣␣␣␣␣␣A␣61␣␣␣␣␣*Speyer;␣Neustadt/We
28527070␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Luxemburg;Trier;Saar
33836870␣motorway_link␣␣A␣63␣␣␣␣␣Kaiserslautern
33836883␣motorway_link␣␣A␣63␣␣␣␣␣Mainz
34260592␣motorway␣␣␣␣␣␣␣A␣62␣␣␣␣␣*Trier;Birkenfeld;Ku
38334828␣trunk␣␣␣␣␣␣␣␣␣␣L␣425␣␣␣␣*Mörstadt
38336007␣trunk␣␣␣␣␣␣␣␣␣␣B␣455␣␣␣␣*Mainz-Kastel;␣Wiesb
38336072␣trunk␣␣␣␣␣␣␣␣␣␣B␣455␣␣␣␣*Wiesbaden-Stadtmitt
38447323␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Köln;␣Bonn;␣Koblenz
42425450␣motorway␣␣␣␣␣␣␣A␣643␣␣␣␣Bingen;␣Mainz;␣Frank
47370522␣motorway_link␣␣A␣6␣␣␣␣␣␣Mannheim;Karlsruhe;M
47370523␣motorway_link␣␣A␣6␣␣␣␣␣␣Saarbrücken;Trier
47370526␣motorway_link␣␣A␣6␣␣␣␣␣␣Saarbrücken;␣Kaiser
49196675␣motorway␣␣␣␣␣␣␣A␣66␣Rhe␣*Frankfurt
49201156␣trunk␣␣␣␣␣␣␣␣␣␣B␣455␣␣␣␣*Mainz-Kastel;␣Wiesb
53791939␣motorway␣␣␣␣␣␣␣A␣650␣␣␣␣*Ludwigshafen
61420525␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Kaiserslautern-West;
61420527␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Kaiserslautern-West;
83157584␣motorway␣␣␣␣␣␣␣A␣65␣␣␣␣␣*Mutterstadt-Nord
92932733␣motorway␣␣␣␣␣␣␣A␣63␣␣␣␣␣*Kaiserslautern
94061754␣motorway␣␣␣␣␣␣␣A␣63␣␣␣␣␣*Mainz
111545789␣motorway␣␣␣␣␣␣␣A␣60␣␣␣␣␣*Frankfurt␣a.M.;Darm
112072760␣motorway␣␣␣␣␣␣␣A␣61␣␣␣␣␣*Speyer;␣Neustadt/We
112599196␣motorway␣␣␣␣␣␣␣A␣62␣␣␣␣␣*Pirmasens;Landstuhl
112599198␣motorway␣␣␣␣␣␣␣A␣62␣␣␣␣␣*Trier;Birkenfeld;Ku
116002598␣motorway␣␣␣␣␣␣␣A␣48␣␣␣␣␣*Trier;Koblenz
123313505␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Rüdesheim
124734578␣trunk␣␣␣␣␣␣␣␣␣␣L␣425␣␣␣␣*Worms-Nord;␣Worms-A
132979563␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Bad␣Dürkheim;␣Mannh
132979566␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Neustadt/Weinstr.
134378212␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Rasthof␣Wonnegau-Ost
134378213␣motorway_link␣␣12␣␣␣␣␣␣␣Frankfurt;␣Mainz;␣In
134378214␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Monsheim
134378215␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Mörstadt
134378217␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Frankfurt␣a.␣M.;␣Mai
142769513␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Wiesbaden-Frauenstei
143164001␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Wiesbaden-Äppelalle
143414058␣motorway_link␣␣A␣643␣␣␣␣Wiesbaden;␣Wiesbaden
143414062␣motorway_link␣␣A␣643␣␣␣␣Koblenz;␣Bingen;␣Mai
143414065␣motorway_link␣␣A␣66␣␣␣␣␣Frankfurt
143414071␣motorway␣␣␣␣␣␣␣A␣66␣Rhe␣*Frankfurt
143414072␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Rüdesheim
144118153␣motorway_link␣␣B␣263␣␣␣␣Wiesbaden-Mainzer␣St
144118157␣motorway_link␣␣B␣263␣␣␣␣Darmstadt;␣Wiesbaden
144123633␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Wiesbaden-Stadtmitte
144449837␣motorway␣␣␣␣␣␣␣A␣650␣␣␣␣*Bad␣Dürkheim
144453294␣motorway_link␣␣A␣650␣␣␣␣Mannheim;␣Ludwigshaf
144453315␣motorway␣␣␣␣␣␣␣A␣650␣␣␣␣*Ludwigshafen
146414975␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Wiesbaden;␣Wiesbaden
146611369␣motorway␣␣␣␣␣␣␣A␣643␣␣␣␣*Wiesbaden;␣Wiesbade
146611376␣motorway␣␣␣␣␣␣␣A␣643␣␣␣␣*Koblenz;␣Bingen;␣Ma
148274960␣motorway␣␣␣␣␣␣␣A␣60␣␣␣␣␣*Frankfurt␣a.M.;Darm
149120482␣motorway␣␣␣␣␣␣␣A␣63␣␣␣␣␣*Kaiserslautern
149896911␣motorway_link␣␣48␣␣␣␣␣␣␣Dorsheim;␣Rümmelshe
155363678␣motorway␣␣␣␣␣␣␣A␣61␣␣␣␣␣*Rasthof␣Wonnegau-Os
155363725␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Monsheim
155363734␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Worms
155363746␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Monsheim;␣Worms
155363762␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Rasthof␣Wonnegau-Ost
165776953␣motorway_link␣␣B␣263␣␣␣␣Wiesbaden-Mainzer␣St
169412993␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Kaiserslautern-Centr
175118086␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Frankfurt;Koblenz
175118089␣motorway_link␣␣␣␣␣␣␣␣␣␣␣Bonn;Köln

Hallo,
wende dich doch mal an die Jungs von mkgmap-dev, wenn das funktionieren sollte. Dann könnte man das direkt in mkgmap integrieren.

Habe selber schon mal drüber nachgedacht so etwas ähnliches zu implementieren. Mit Vorlage geht sowas aber natürlich viiiiel einfacher :-)

Meine Idee ging sogar noch etwas weiter und sollte eigentlich nicht nur auf Autobahnen beschränkt sein. Ich habe nämlich recht häufig den Text "Rechts auf Rampe" angesagt bekommen. Ggf. könnte man der Rampe besser den Namen der Zielstraße (z.B. "Richtung B51") verpassen. Mehr als eine Idee ist das aber nie gewesen. Ich weiß also überhaupt nicht, ob das sinnvoll ist und funktioniert. Wäre auf jeden Fall schon mal gut, wenn wir mit Autobahnen anfangen könnten. Das andere kann man dann ja nach und nach dazuimplementieren.

WanMil

Offtopic: Für seltene Fälle uneindeutiger Geometrien der Einbahn Abbiegeverläufe wo man aber eindeutige Ansage braucht gibt es (nicht in der OSM) spezielle Punkte die diese Ansage beinhalten. Ist so ein Punkt vorhanden, wird die Geometrie/Kurvigkeit etc nicht untersucht. Die Angabe an einem solchen Punkt hat den Vorrang.

Ja, hab ich mir schon gedacht, dass die Profis mit solchen Hints arbeiten.

Nach und nach ist auch OSM ein Profi Projekt.. 😉 Überleg mal wie sowas in OSM aussehen könnte..
Und klar - es wäre ein klarer Fall vom Mappen für den Routing 🙂

Da gab es auf der SOTM in Japan einen Vortrag von Leuten von Bosch, die Routing betreiben und gerne solches Tagging hätten. Stichwort "Complex Junctions".

Na, dann werde ich nicht erschossen für den Verrat wichtiger Betriebsgeheimnisse. 😄
Wenn die Katze also aus dem Sack ist, könnten wir auch dieses Thema anpacken.
So kompliziert ist es auch nicht.

Das mit dem Punkt ist ja schön und gut, nur denke ich, dass es nicht Sinn und Zweck von OSM ist, der Navi-Industrie blind hinterher zu dackeln. Es ist nun mal der komplette Weg, der die Auffahrt mit der direction bildet. Diesen sollte man so auch taggen. Wenn nun ein Auswerter meint, nur einen Punkt zu brauchen, ist es ein leichtes, einen Punkt des Weges zu wählen und die Tags entsprechend zu setzen.

Stimmt ja auch. Das Wichtigste ist der allgemeine Mehrwert einer Lösung.
Es bleibt zu prüfen welche praktische Vorteile hätte man, wenn man dem Vorschlag von Bosh folgte und ob es auch nicht anders geht.

DennisL wrote:

Da gab es auf der SOTM in Japan einen Vortrag von Leuten von Bosch, die Routing betreiben und gerne solches Tagging hätten. Stichwort "Complex Junctions".

Ist "Bosch" dann auch die Auflösung des Preisrätsels, mit wem sich eine Abordnung des OSMF-Vorstands vor einigen Monaten getroffen hat?

Marek, das Problem ist doch, dass es keinen Standard gibt, der alle glücklich macht. Garmin braucht bspw. die Info am Weg hinter dem *_link, Bosch hätte es gerne an einem Knoten irgendwo und wieder ein anderer Hersteller hätte es gerne an einem weiteren Ort. Damit hab ich kein Problem, ist halt deren Entscheidung, dass jeder sein eigenes Format haben möchte.

Meines Erachtens sollte OSM sich hier nicht einem Hersteller an den Hals schmeißen und sagen, dein System ist super, sonder bei der Realität bleiben. Die Realität ist nun mal, dass die Auffahrt die Eigenschaft hat, in welche Richtung sie führt und dementsprechend sollte auch der way das Tag direction=* bekommen. Ob man dann daraus einen Punkt erezugt oder die Infos auf den folgenden Weg überträgt oder was auch immer damit macht ist dann Sache des Auswerters.

Die Realität ist nun mal, dass die Auffahrt die Eigenschaft hat, in welche Richtung sie führt und dementsprechend sollte auch der way das Tag direction=* bekommen.

+1

aighes wrote:

Marek, das Problem ist doch, dass es keinen Standard gibt, der alle glücklich macht...
Meines Erachtens sollte OSM sich hier nicht einem Hersteller an den Hals schmeißen und sagen, dein System ist super, sondern bei der Realität bleiben...

Mittlerweile haben wir x Diskussionen, welche ergebnislos irgendwie dieses Thema behandelten:
http://forum.openstreetmap.org/viewtopi … =14710&p=1
http://forum.openstreetmap.org/viewtopic.php?id=18265
http://forum.openstreetmap.org/viewtopi … =17795&p=1
http://forum.openstreetmap.org/viewtopi … 43#p168643
http://forum.openstreetmap.org/viewtopic.php?id=14664
http://forum.openstreetmap.org/viewtopic.php?id=12554
http://forum.openstreetmap.org/viewtopi … 05#p138705
http://forum.openstreetmap.org/viewtopic.php?id=11008
http://forum.openstreetmap.org/viewtopi … 730#p33730
(Die Liste erhebt keinen Anspruch auf Vollständigkeit)
Wäre schön, wenn jetzt mal eine Lösung dabei herauskommt, mit der Erfasser, Renderer und Router leben könnten.

Die meisten Probleme kommen vermutlich vom "spurnahen" Mappen. Wenn ich das Ursprungsbeispiel nehme, wäre das bei der Kreuzung Hamburger Straße / Kasseler Straße so.
Die Abbiegespur ist ja eine eigene kurze Linie. Wie wäre es, wenn man diese mit einem einzuführugenden Tag von der Winkelberechnung ausnimmt? Oder ählichen dem motorway_link ein secondary/.../residential_junction einführt.

Liebe Freunde,
ich bin zur Zeit leider gesundheitlich angeschlagen daher habe ich noch keine Einladung nach Garching verschickt. Trotzdem, wie Hurdygurdyman denke ich dass wir uns endlich auf ein Schema einigen sollen. Wollen wir erste Novemberhälfte zwecks Treffen in Garching anpeilen und bis dato einige Lösungsansätze vorbereiten?

aighes wrote:

wende dich doch mal an die Jungs von mkgmap-dev, wenn das funktionieren sollte. Dann könnte man das direkt in mkgmap integrieren.

Ja das funktioniert, sehe nun bei ca. 30% aller AB-Kreuze die destination. Auf der mkgmap-dev hatte ich das Preprocessing bereits als Vorschlag gemeldet.
Wer's mal testen möchte, die DACH+ Karte für's Nüvi steht in Kürze auf meine Wikiseite zum download zur Verfügung.

Das Lanes-Schema http://wiki.openstreetmap.org/wiki/DE:Lanes wurde jetzt am komplexen Kreuzungsbereich der Kronenbrücke in Freiburg
http://www.openstreetmap.org/?lat=47.99 … 57&zoom=18
getestet. Die wesentliche Arbeit hat hierbei dankenswerterweise der österreichische Kollege imagic http://wiki.openstreetmap.org/wiki/User:Imagic geleistet, der auch das proposal sowie die Wiki-Seite zum Schema verfasst hat.

Herausgekommen ist dabei dies:
http://ubuntuone.com/7ZD8chqc8HMyBqeqAy23IM
Wenn ihr die Datei in JOSM öffnet, könnt ihr diesen Hintergrund von Aerowest verwenden:
http://ubuntuone.com/4yMyNVBfX1UqCQrjQkkLNB

Es wurden nur die Straßen bzw. Fahrspuren im Bereich der Brücke erfasst. Die Kreuzungsflächen wurden als highway=junction angelegt und sind gelb und grün markiert. Auf dieser Fläche sich kreuzende highway=* müssen keine gemeinsamen nodes haben, wenn dort ein Wechsel auf den anderen highway nicht möglich ist, um relation=restriction weitestgehend zu vermeiden.

Mein Fazit:
Das Schema eignet sich in der Hand von erfahrenen Mappern auch für komplexe Kreuzungsbereiche und sollte auch bevorzugt dort angewendet werden, damit Router diese Spur-Informationen auswerten und anzeigen können, denn gerade an diesen Kreuzungen werden sie vom Autofahrer dringend benötigt.
Ich werde das Schema in meinen Bearbeitungen ab sofort einsetzen und meine Ideen zum Spurmapping
http://forum.openstreetmap.org/viewtopi … 86#p277786
so nicht weiter verfolgen.

Exkurs:
Die Idee mit highway=junction zur Vermeidung von restriction sollte allerdings weiter verfolgt werden. 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, um diese mittelfristig zu ersetzen. Dann könnte auch auf highway=junction verzichtet werden.

Ich freue mich, dass diese Arbeit weiter geht.
Wir werden in Garching hoffentlich den letzten Schliff besprechen können, etwa den Gedanken mit den Lan dividers die dem Schema Hinzugefügt werden können.

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

getaggt mit etwa:

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

für eine einfache Straße mit 4 Fahrspuren und einer Doppellinie in der Mitte.

Idee 2:

alle Tags in einer Reihe:

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

Idee 3:

alle Tags in einer Reihe, leicht verständliche Tags:

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

Nachteil der Idee 2 und 3:

Die Vermischung der Angabe von Destination mit Spurtrennern.

Nachteil der Idee 1:

Ich muß bei komplexen Abschnitten richtig die die gezeichnete Richtung der Straße erkennen, damit der User nicht in die verkehrte Richtung taggt.
Man kann leichter Durcheinander beim Taggen kommen, da man sich leicht verzählen kann.

marek kleciak wrote:

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

getaggt mit etwa:

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

Schwierig 🤔 vier Spuren mit drei Trennern und fünf Trennlinien mit vier Trennern. Wie soll das der Renderer zusammenbringen?
Wenn wir uns entschließen könnten, mindestens in den Fällen der Erfassung von *:lanes auch die durchgezogene Linie als Trennung von Fahrspuren ohne Wechselmöglichkeit zu akzeptieren, könnten wir auf crossable=* oder ähnliches verzichten, weil dann der Spurwechsel innerhalb einer Fahrspur beliebig möglich wäre.

Wie soll das der Renderer zusammenbringen?

Geht, wir haben Tests gemacht. einfacher geht´s mit einer Zeile, da weniger Fehler befürchtet. Am einfachsten ginge es mit einem WYSIWYG http://de.wikipedia.org/wiki/WYSIWYG Editor, wo man gleich Ergebnisse seht und nicht schreiben muss. Nur drag and drop.

Die Syntax der Tagging weiß man zwar in einem solchen Fall und natürlich wäre das auch manuell veränderbar.
Wie gesagt, es existiert berets eien Entwicklerversion von einem JOSM PlugIn, ich diskutierte es mit imagic, er wies darauf hin, dass es auch Arbeiten zu diesem Thema gibt daher wäre die Implementierung relativ zügig gemacht. Danach könnten wir es testen und Entscheidungen treffen.

Überzeugt mich nicht. Für einfache Fälle, ok. Aber mangels zusätzlicher Geometrie können komplexere Gegebenheiten nicht dargestellt werden. Fußgängerrouting und Rendering in sehr hohen Zoomstufen werden auch nicht bzw. kaum verbessert. Und: Meiner Meinung nach ist das deutlich fehleranfälliger. Eigenständige lanes fallen dem Bearbeiter sofort auf, aber die Tags können leicht übersehen werden, wenn Wege geteilt oder - schlimmer - vereinigt werden. Letztendlich hat man nicht weniger Komplexität, man verschiebt sie nur von einfachen Geometrien zu komplexen Tagsystemen. Diese sind unintuitiv (z.B. warum und auf welche Weise genau werden Radspuren von Kfz-Spuren getrennt) und stark voneinander abhängig (was soll ein Auswerter aus einem Weg machen, der lanes=x, aber y verschiedene Werte in :lanes Erweiterungen hat - oder gar unterschiedlich viele je Schlüssel).

Btw.: Wenn schon, dann wäre ich eindeutig für Idee 3. Reduziert Abhängigkeiten zwischen Tags und ist halbwegs intuitiv. Wobei ich es logischer fände, crossable mit access zu kombinieren, nicht mit destination.

Das stimmt ja alles, errt. Macht mir ja auch ziemlich Kopfzerbrechen. Ich verbinde es aber mit Straße als Fläche und denke, dass dies nur mit einem guten Editor möglich wäre, sonst lieber die Ffinger davon lassen denn die einfachen Fälle sind ausgerechnet die, die am wenigsten gebraucht werden.
Ich bereite nun für Garching eine Präsentation mit einigen Alternativen sowie dem möglichen User Interface von einem solchen Editor.

Hi,
wurde schon darüber nachgedacht, die Fahrspurentrenner mit Symbolen zu kartieren?

:␣␣␣-␣␣␣gestrichelt
|␣␣␣-␣␣␣durchgezogen
||␣␣-␣␣␣Doppellinie
|:␣␣-␣␣solid,dashed
:|␣␣-␣␣dashed,solid

destination:lanes=|A:A||B:B|
(nach dieser logik: crossable=no|yes|no,no|yes|no )

Sieht übersichtlich aus, aber bestimmt nicht so gut auswertbar!?

Gruß
Masi

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 😉

marek kleciak wrote:

Idee 1 (geht auf Immagic zurück):
[...]
destination:lanes=A|A|B|B
crossable=no|yes|no,no|yes|no

Idee 2:
[...]
destination:lanes=no|A|yes|A|no,no|B|yes|B |no

Idee 3:
[...]
destination:lanes=solid|A|dashed|A|double_solid|B|dashed|B |solid

Idee 2 und 3 haben trotz der oberflächlichen Ähnlichkeit wenig mit dem akzeptierten lanes-Proposal zu tun, wo man ein Tag pro Schlüssel erstellt und eben nicht alles in einen Wert packt Die Idee ist schließlich, mehrere Tags mit *:lanes versehen zu können - also z.B: noch turn:lanes und width:lanes. Die Divider will man aber nur einmal nennen, also sind die Werte der *:lanes-Tags eher nicht der richtige Ort dafür.

Idee 1 hingegen lässt nicht genug Spurtrenner zu, um alle in der Realität vorkommenden Variationen abbilden zu können. Das könnte man mit den sprechenden Werten aus Idee 3 problemlos beheben.

Für mich daher die naheliegendste Variante: Analog zu :lanes noch :divider einführen und dort sprechende Werte verwenden. Also:

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

Tordanik wrote:

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

marek kleciak wrote:

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

Tordanik wrote:

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

aighes wrote:

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

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?

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.

aighes wrote:

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/Navi … p_Garching

aighes wrote:

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 😉

Tordanik wrote:

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?

errt wrote:

Tordanik wrote:

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.

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

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.

hurdygurdyman wrote:

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.

slhh wrote:

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

Interessanter Hinweis. Ein Beispiel dafür?

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

slhh wrote:

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.

aighes wrote:

...
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/viewtopi … 45#p283045

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

hurdygurdyman wrote:

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

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

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

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

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

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

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

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

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

hurdygurdyman wrote:

aighes wrote:

...
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/viewtopi … 45#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.

imagic wrote:

...

hurdygurdyman wrote:

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

aighes wrote:

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

hurdygurdyman wrote:

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.

aighes wrote:

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

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.

marek kleciak wrote:

slhh wrote:

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_surfa … nformation

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

imagic wrote:

hurdygurdyman wrote:

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.

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.

marek kleciak wrote:

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.

slhh wrote:

marek kleciak wrote:

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.

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

Tordanik wrote:

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.

imagic wrote:

MasiMaster wrote:

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|

1. Steht wohl für eine schraffierte Fläche.
   

aighes wrote:

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

Tordanik wrote:

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.

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:<Fahrzeugart>=<komischer String>, 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.

aighes wrote:

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

Tordanik wrote:

errt wrote:

Tordanik wrote:

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

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.

aighes wrote:

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:<Fahrzeugart>=<komischer String>, 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).

Tordanik wrote:

...
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/viewtopi … 54#p284554
Edit Zitat:

imagic wrote:

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.

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

imagic wrote:

hurdygurdyman wrote:

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_B … _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.

slhh wrote:

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.

chris66 wrote:

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?

hurdygurdyman wrote:

chris66 wrote:

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+Ti … n&t=h&z=20
Im vergleich zu http://maps.google.de/maps?q=Dresden+Ti … n&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+Ti … n&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.

errt wrote:

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?

viw wrote:

Ich hoffe du irrst nicht. Aber schon der Unterschied bei dieser Kreuzung: http://maps.google.de/maps?q=Dresden+Ti … n&t=h&z=20
Im vergleich zu http://maps.google.de/maps?q=Dresden+Ti … n&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+Ti … n&t=h&z=20

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.05 … 55&zoom=18

errt wrote:

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

errt wrote:

Dann haben aber crossable und crossable:* völlig unterschiedliche Semantik und auch Syntax, nämlich ersteres Linienarten und letztere Zulässigkeit des Spurwechsels.

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.

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.

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.

hurdygurdyman wrote:

Das entsprechende turn:lanes=left|through|right würde sich dann auf den in Fahrtrichtung nächsten gemeinsamen Knoten mit einem anderen highway=* beziehen.

Das turn:lanes=left|through|right sollte sich immer auf das Ende des Weges beziehen. Wenn man es immer auf den nächsten Knoten beziehen würde, hätte man erstens probleme mit anschließenden Fusswegen etc.. Wenn es sich auf den Knoten beziehen würde, bräuchte man z.B. eine Abbiegespur hinter dem Knoten normalerweise nicht mehr und müßte den Weg daher ohnehin in diesem knoten aufteilen.
Häufig dürfte es jedoch vorkommen, dass sich die turn:lanes Werte nicht auf das Ende des aktuellen Weges sondern erst auf das Ende des nächsten, übernächsten, etc. Weges beziehen, weil eine Abbiegespur entsprechend lang ist.
Hier kann man dann mit turn:physical:lanes=through|through|through oder kurz turn:physical=through die Wirkung für das Ende des ersten Weges übersteuern.

chris66 wrote:

slhh wrote:

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.

Hier ist es aber eine eindeutige Regel, wie der Weg vom Router auszuwählen ist. Sollte dabei die Tags eben so setzen, das auch bei leichten Geometrieveränderungen noch das gewünschte Ergebnis sicher herauskommt.

Wenn man jeden Router seine eigene Heuristik verwenden lassen , die dann nur manchmal funktioniert, wäre es natürlich problematisch.

Eine gewisse Fehleranfälligkeit bei Veränderungen bleibt natürlich, aber ist diese bei Relationen nicht durch mangelnde Sichtbarkeit noch höher?

slhh wrote:

hurdygurdyman wrote:

Das entsprechende turn:lanes=left|through|right würde sich dann auf den in Fahrtrichtung nächsten gemeinsamen Knoten mit einem anderen highway=* beziehen.

Das turn:lanes=left|through|right sollte sich immer auf das Ende des Weges beziehen. Wenn man es immer auf den nächsten Knoten beziehen würde, hätte man erstens probleme mit anschließenden Fusswegen etc.. Wenn es sich auf den Knoten beziehen würde, bräuchte man z.B. eine Abbiegespur hinter dem Knoten normalerweise nicht mehr und müßte den Weg daher ohnehin in diesem knoten aufteilen.

Logisch.

Häufig dürfte es jedoch vorkommen, dass sich die turn:lanes Werte nicht auf das Ende des aktuellen Weges sondern erst auf das Ende des nächsten, übernächsten, etc. Weges beziehen, weil eine Abbiegespur entsprechend lang ist.
Hier kann man dann mit turn:physical:lanes=straight|straight|straight oder kurz turn:physical=straight die Wirkung für das Ende des ersten Weges übersteuern.

Wenn am nächsten Kreuzungspunkt mit einem highway das Abbiegen in der am way beschriebenen Form nicht möglich ist, darf dort kein gemeinsamer node sein. Sollte an diesem Punkt aber z.B. nur eine von mehreren Abzweigmöglichkeiten machbar sein, müsste es natürlich einen gemeinsamen Knoten geben und wir kämem um eine relation=restriction hier nicht herum.

hurdygurdyman wrote:

Wenn am nächsten Kreuzungspunkt mit einem highway das Abbiegen in der am way beschriebenen Form nicht möglich ist, darf dort kein gemeinsamer node sein.

Da sich turn auf das Wegende beziehen muss, stört gemeinsame Punkt stört erst dann, wenn dort auch der Weg endet. Aber auch in diesem Fall stört er nur geringfügig, da mit turn:physical=through dem Router mitgeteilt werden kann, dass die Fahrspuren in diesem Knoten noch geradeaus weiterlaufen, auch wenn sie schon anders markiert sind, wie durch turn:lanes beschrieben wird.

hurdygurdyman wrote:

Sollte an diesem Punkt aber z.B. nur eine von mehreren Abzweigmöglichkeiten machbar sein, müsste es natürlich einen gemeinsamen Knoten geben und wir kämem um eine relation=restriction hier nicht herum.

Eine Relation brauchen wird dafür noch lange nicht.
Beispiel: eine Einbahnstraße kreuzt eine Straße mit baulich getrennten Fahrbahnen. Wir haben einen also zwei Kreuzungsknoten.
Nehmen wir weiter an, die Einbahnstraße hat vor dem ersten Kreuzungsknoten drei Spuren mit turn:lanes=left|through|right. Man kann dabei natürlich im ersten Kreuzungsknoten nur nach rechts und im zweiten Knoten nur nach links abbiegen. Das können wir dem Router wie folgt mitteilen:

Die Einbahnstraße wird durch drei separate Wege dargestellt werden:
- bis zum ersten Kreuzungsknoten
lanes=3
turn:lanes=left|through|right
turn:physical:lanes=through|through|right
- zwischen den beiden Kreuzungsknoten
lanes=2
turn:lanes=left|through
- nach dem zweiten Kreuzungsknoten
lanes=1

Das
turn:physical:lanes=through|through|right
im ersten Abschnitt könnte natürlich auch als
turn:physical:lanes=through||
geschrieben werden, da dann für die anderen Spuren die Werte aus turn:lanes zu übernehmen wären. Insgesamt hat dieses turn:physical:lanes die Aufgabe, dem Router mitzuteilen, dass die linke Spur zwar mit einem Linksabbieger-Pfeil gekennzeichnet ist, jedoch im ersten Kreuzungsknoten dennoch geradeaus weiterführt.

In diesem einfachen Fall könnten wir auch so abwandeln, dass aus den beiden kreuzenden Fahrbahnen zwei eigenständige Straßen jeweils mit Gegenverkehr werden. Nehmen wir dann an, dass die Abbiegemöglichkeiten unverändert bleiben, so können die Tags der Einbahnstraße unverändert bleiben.

Im ursprüglichen einfachen Fall wäre es das turn:physical:lanes prinzipiell redundant, wenn der Router die oneway Eigenschaft der kreuzenden Fahrbahnen auswertet. Dann ist im ersten Kreuzungspunkt die am besten zum turn value left passende in abgehender Richtung befahrbare Weg ohnehin der geradeaus zum zweiten Kreuzungspunkt führende Weg.
Ein Router sollte so arbeiten, dass er in diesem Fall auch ohne turn:physical:lanes auskommt, jedoch sollte ein Inspektor dies besser als Fehler melden.
Die Tags sollten so gesetzt werden, dass man ohne Ausnutzung der oneway-Eigenschaft zum richtigen Ergebnis kommt. Andernfalls kann es leicht zum Chaos führen, wenn Einschränkungen der Oneway Eigenschaft hinzukommen (bespielsweise Fahrräder in Gegenrichtung frei).

viw wrote:

Ich hoffe du irrst nicht. Aber schon der Unterschied bei dieser Kreuzung: http://maps.google.de/maps?q=Dresden+Ti … n&t=h&z=20
Im vergleich zu http://maps.google.de/maps?q=Dresden+Ti … n&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.

Im ersten Fall könnte der von mir vor einigen Tagen vorgeschlagene Key
turn:input:lanes=left|right eingesetzt werden, um zu kennzeichnen, in welcher Form in die
Spuren der abgehenden Winterbergstraße (dort zu taggen) eingefahren werden kann.

hurdygurdyman wrote:

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.

Dies ist auch keine schlechte Idee, allerdings wird es mit der Bezeichnung in der Form

_right_lane schwierig, wenn dort sehr viele Spuren vorhanden sind.
Vieleicht sollten wir ein Tag zu Benennung von Spuren einführen. Wenn man z.B. die Winterbergstraße mit
lanename:lanes=WBS_F1|WBS_F2
taggt, könnte in der Karcherallee mit
turn:lanes=|through|right:WBS_F2
das Rechsabbiegen in die linke Spur ausgeschlossen werden.

Die Namen für die Lanes sind natürlich frei wählbar. Meine Idee bei WBS_F1 war Abkürzung des Straßennamens + Fahrtrichtung (forward) + Nummerierung der Spur.

Alternativ zu lanename:lanes könnte auch folgende Keys verwendet werden:

lamelabel:lanes
label:lanes
name:lanes
lane:lanes

Die Benennung der Lanes würde uns auch erlauben, zu definieren, dass die Abzweigung bereits vor dem Ende des Weges erfolgt, wenn die passend benannte weiterführende Spur nicht an dem Endknoten, sondern an einer früheren Interconnection des Weges vorhanden ist. Wenn dann alle
turn Möglichkeiten einer Spur abgezweigt sind, sollte dies bedeuten, dass die betreffende Spur vorzeitig endet. Damit können wir uns viele Aufteilungen von Wegen und den zugehörigen Aufwand, um deren Spuren wieder richtig zu verknüpfen, ersparen.

Bitte nicht für Garmin taggen.
Oder heißt die Straße wirklich "A 45 links fahren Richtung Frankfurt a M Siegen Hagen"? 😎
http://www.openstreetmap.org/?lat=51.42 … 8&layers=M

chris66 wrote:

Bitte nicht für Garmin taggen.
Oder heißt die Straße wirklich "A 45 links fahren Richtung Frankfurt a M Siegen Hagen"? 😎
http://www.openstreetmap.org/?lat=51.42 … 8&layers=M

Als Entdecker lasse ich dir den Vortritt beim Rausschmiss. Stammt zwar von einem hier nicht unbekannten... 🙄

Das sollte sich egtl. so im style von mkgmap lösen lassen.

highway=motorway_link␣&␣destination=*␣&␣ref=*␣{set␣name='$ref'␣Richtung␣'${destination|subst:;␣␣}'}

chris66 wrote:

Bitte nicht für Garmin taggen.
Oder heißt die Straße wirklich "A 45 links fahren Richtung Frankfurt a M Siegen Hagen"?

Dulden, oder rausschmeissen (bzw. von 'name' nach 'description' verschieben) ?

Ist allerdings schon von 2009:
http://www.openstreetmap.org/browse/changeset/1785880

Chris

aighes wrote:

Hallo,
wende dich doch mal an die Jungs von mkgmap-dev, wenn das funktionieren sollte. Dann könnte man das direkt in mkgmap integrieren.

Erster Patch verfügbar (Hab's noch nicht getestet):

WanMil wrote:

attached is a patch that implements the proposed completion of the destination tag.

It can be enabled with the --enable-destination-completion

The code logs which ways are additionally tagged with destionation and which are skipped:
uk.me.parabola.mkgmap.reader.osm.LinkDestinationHook.level=INFO

Please give it a try. Maybe someone find some additional useful rules how to complete the destination tag.
At the moment only a "forward" completion is performed, i.e. for all *_link ways the destination tag is copied to all connected ways in driving direction. This is not done if the connected way has itself multiple connections.

Hier das gepatchte mkgmap (V2370).
https://www.wetransfer.com/dl/UJ6t3fJI/ … adf62c101d
(Link 2 Wochen gültig)

Hab's noch nicht getestet

Mittlerweile erfolgreich getestet, und in den letzten Tagen täglich ein AK destiniert. 😄
(An der Stelle nochmal Danke an den Master von autobahn-bilder.de)

Edit: Ab V2372 ist die Option im Standard mkgmap drin.