Workshop Advanced Navigation in Erlangen

Wir haben mal ausgiebig in http://forum.openstreetmap.org/viewtopic.php?id=14710&p=1
über Spurmapping und komplexe Kreuzungen diskutiert.
Ich habe nun mit dem Vicepräsidenten meiner Firma darüber gesprochen.

Ergebnis: Es wäre machbar, die Vertreter der wichtigsten Autohersteller und uns zusammen zu bringen um gemeinsam eine Lösung zu erarbeiten,
die aus Sicht der Autoindustrie notwendig wäre um die OSM Daten verwenden zu können.

Ich denke Ende Oktober wäre als Termin vorstellbar.

Klingt nach einer guten Idee für mich. Ich habe den Vorschlag mal ins Navit-Forum weitergeleitet - es gibt bestimmt auch Interesse aus der Navit-Community, daran teilzunehmen. Insbesonders nutzt Navit ja schon lange OSM-Daten:

https://forum.navit-project.org/viewtopic.php?f=5&t=437

Sehr gern.
Könntest Du ggf auch kommen?
Schöne Grüße!
Marek

Wären Stimmen von Navi-App-Machern wie Skobbler oder MapFactor nicht auch interessant, gerade da sie ja auch viele Erfahrungen sowohl mit proprietären Datenformaten als auch mit OSM-Daten haben?

Huhu, ich habs dank MHomann drüben im Navit-Forum gesehen.

Klingt ja spannend und irgendwie wichtig, gibt es dafür schon eine Roadmap bzw. worum genau soll es dabei gehen?

  • Mapping-Schemas

  • Erfassungs-Technologien

  • Datenspenden

  • sonstige Kooperationen

Es gab mal von Seiten der OSMF oder skobbler einen (merkwürdigen?) Vorstoß in die Richtung der Automotive-Industrie, von daher sollte man da in meinen Augen möglichst transparent arbeiten, was ich denke du hiermit ja tust :slight_smile:

Ich selbst werde leider nicht kommen können, da ich die nächsten Monate im Ausland bin.
Mein einziger Hinweis basierend aus meinen Tagging-Diskussionen wäre, sich möglichst auch einigen “Normalmapper” mit dazu zu holen, denn sonst neigt man als Experte wahrscheinlich dazu, zu viele Details mit zu umständlichen Tagging-Gebilden erfassbar zu machen, die aber 99% der Community dann eh nicht erfassen werden :wink:

Die volle Transparenz und Anwesenheit der Mapper, insbesondere der “Normalmapper” wie Du schreibst, ist hier absolut am wichtigsten.
Wir wollen alle keine Geheimabsprachen. Nichts geschieht ohne Mapper. Was man also alles in Zukunft machen will, muss für alle transparent und nachvollziehbar sein.
Vielleicht wird nicht alles einfach sein können wenn es sich um z.B. um komplizierte Kreuzungen handelt, trotzdem müssen wir es so verständlich halten, wie es nur geht…
Es geht mir insbesondere darum, dass man bei uns begreift, welche Bedenken, Vorbehalte, Anregungen im Bezug auf OSM seitens Autoindustrie bestehen.

Beide Seiten können davon profitieren:

  • indem wir lernen, was der Autoindustrie wichtig ist und
  • indem die Autoindustrie lernt, was wir noch MEHR können bzw. wo wir unsere Schwächen / Grenzen sehen.

Im Zuge dieser Paneldiskussion könnten wir womöglich endlich ein Mapping Schema für Lanes und komplexe Kreuzungen festlegen.
Auf der anderen Seite könnten wir auch von der Autoindustrie über Erfassungstechnologien diskutieren. Esist ja bekannt, dass die neuen Autos mit Kameras fahren und den Schätzungen zufolge etwa 100.000 Autos in ganz Deutschland ausreichen würden um die Karte (Straßenraum besser gesagt) stets auf dem aktuellsten Stand zu halten.

Es wäre natürlich schön, wenn die Leute von der OSMF (Vorstand?) dabei wären. Schade dass Du nicht dabei sein kannst. Vieleicht nächstes Mal.
Ein runder Tisch an dem man sich z.B. einmal im Jahr trifft, wäre sicherlich vorteilhaft.

???
Ich dachte das Tagging-Schema für Lanes wäre bestätigt und auch in Nutzung.

Edbert (Edbert )

Das Schema ist schon mal ein guter Anfang.
Es könnte sich aber die Frage stellen, ob dieses für die Belange der professionellen Auswertung (Autofirmen und sonstige Anbieter von routing-software) ausreicht.

Dank deiner links bin ich auch auf offensichtliche mapping-Fehler gestoßen, wie z.B.:
http://taginfo.openstreetmap.org/tags/turn%3Alanes=through|left
http://taginfo.openstreetmap.org/tags/turn%3Alanes=left|rhrough|through
http://taginfo.openstreetmap.org/tags/turn%3Alanes=left%3Bstraight|straight|right
Dann wird hier: http://wiki.openstreetmap.org/wiki/Key:turn
auch “none” vorgeschlagen, wenn keine Spurhinweise vorhanden sind. Verwendet wird aber auch sehr oft die Variante ohne “none”: http://taginfo.openstreetmap.org/tags/turn%3Alanes=|||merge_to_left
Da gibt es sicher noch Diskussionsbedarf auch auf unserer Seite und die Notwendigkeit eines QA-Tools und dessen Umsetzung wäre zu klären.

Und wie wir mit solchen Kreuzungen http://wiki.openstreetmap.org/wiki/File:MarekOSMcrossingConnections2.jpg
umgehen, an denen ggf. ein lane-to-lane-tagging erforderlich wird, wissen wir auch noch nicht.

Mareks Vorschlag hat somit durchaus seine Berechtigung.

Für mich ist es leider etwas weit (die Strecke kennst Du ja von der SotM) - aber da ich ein paar Kollegen in Erlangen habe, ließe es sich vielleicht mit einem Arbeitsbesuch dort verbinden. Ich schaue mal, was sich machen lässt. Ansonsten müsste es aber ein paar Navit-Entwickler im süddeutschen Raum geben.

Tervitusi Tartust (Grüße aus Tartu)!

Hallo Edbert,
es ist nun so: Die Absicht ist zu zeigen was wir bereits haben und wie wir arbeiten und warum.
Ich sehe in Lanes eigentlich weniger bzw. kaum Probleme. Vielmehr mit komplexen Kreuzungen und davon gibt es nicht so viele als dass sie für einen wenig erfahrenen Mapper von Bedeutung wären.
Es mag ja ein Wenig unglaublich klingeln aber ich hatte während meiner Abeit in Hamburg einen Kollegen der mit ziemlicher Sicherheit anhand der Kreuzungsgeometrie der hochkomplexen Kreuzungen sagen konnte um welche es sich handelt. Selbst in ener Großstadt sind es nur einige. Dort aber bedeutet ein Fehler in einer Navi die die Fahrspur Unterstützung arbeitet sehr schnell 2-3 km ums Eck fahren.

Aus meiner sicht sollte ein solches Treffen vor Allem dem gegenseitigen Verständnis und der Erarbeitung passabler Lösungen dienen durch die wir eine ernst zu nehmende Datenquelle für diese Industrie werden (werden können). Im Übrigen: Es wäre super, wenn Du und andere alte Hasen von dem Forum kommen könnten.

Hallo zusammen,

ich habe selbst vor kurzem begonnen, mit dem “lanes/turn-lanes”-Schema zu arbeiten und würde mich wohl als “Casual-Mapper” bezeichnen. Da ich das Thema auch beruflich leicht streife (ich beschäftige mich mit Verkehrssimulationen), würde ich gerne am Treffen teilnehmen, falls das möglich/erwünscht ist.

Gibt es schon einen genaueren Termin?

Gerhard
(Seoman)

Hallo Gerhard,
Bis ende August haben wir noch Ferien und viele Leute sind nicht erreichbar. Ich bemühe mich asap um ein Termin. Es wäre klasse, wenn Du dabei sein könntest.
Die Diskussionsrunde ist selbstverständlich offen für alle.

Wäre es Dir möglich einkleines Demo Gebiet vollständig zu atributtieren? Eine Diskussionsvorlage wäre wohl sehr hilfreich…
Grüße,
Marek

Grundsätzlich gern, ich wollte bei mir in der Gegend (Duisburg, einige Straßen in Düsseldorf) ohnehin mehr Straßen mit “lanes/turn-lanes” mappen. Ich kann dann z.B. auch Beispiele für übliche Schwierigkeiten/Uneinheitlichkeiten (“lanes” mit/ohne Fahrradspuren; Positionen/Richtungen von Ampeln; …) protokollieren.

Welche Gebietsgröße schwebt dir denn vor und welche Attribute sollten in der Demo-Gegend getaggt sein (ggf. nach welchem Schema, meines muss ja nicht das “richtige” sein)?

Bislang berücksichtige ich jenseits der üblichen Tags wie “name”, “maxspeed” etc. vor allem:

  • lanes

  • turn:lanes

  • traffic_signals:direction

  • change:lanes (nur manchmal)

(Sehr viel) später will ich noch “destination” hinzufügen.

Gerhard

Ich möchte hier nicht (wieder) anfangen, wegen dem taggen von lanes, highway, relationen. Da ich auch kein Navi zum testen habe, nutze ich (fertige) Router-Programme um das Routing zu prüfen.

Ich habe hier eine Kreuzung in meiner Nähe mit aufgeteilten highways (was falsch sein sollte - aber dem tatsächlichen entspricht). Mapquest und GraphHopper routen hier genau wie ich fahren muss - also auch über die entsprechenden “Spuren” der Kreuzung.

Am Abzweig Oberbärenburg wurde das alles auf lanes “umgerubelt”. Dort funktioniert aber das routen nicht mehr. Vom südlichen Parkplatz kommt man nur zu Fuß auf den nördlichen Parkplatz, weil die B 170 mit 3 Fahrspuren (2 bergwärts, 1 bergab) mit Doppellinie getrennt ist. PKW muss also vom Parkplatz über Abzweig Schellerhau nach Parkplatz Nord. Oder von Nord über Abzweig Oberbärenburg nach Süd. Das hatte früher (ohne lanes) funktioniert. Selbst wenn ich nur eine Karte als Ausdruck (wie einen Autoatlas) nutze, wir mir die Routenmöglichkeit nicht ersichtlich (lanes sehe ich ja auch nicht auf der Karte). Ich fasse dort nichts mehr an, um es (richtig)zu ändern, weil es mir zu viele Diskussionen dazu gab. Aber die “größere Probleme” ergeben sich m.E. mit lanes als mit "getrennten “highway-lanes”. Selbst restrictionen, die nicht als Verkehrszeichen angezeigt sind, sind bei highway-lanes unnötig. (Und den Fehler “nicht verbundene ways” kann man ingnorieren.)

Ja, ich weiß “Detailmapping” werden einige sagen, aber entspricht das nicht mehr der tatsächlichen Wirklichkeit, das was ich sehe?
Und das versteht auch ein “OSM-Laie” auf Anhieb.

Hi Seoman,
ich weiß nicht, welches Gebiet genau bereits erfasst ist. Was weitere Fragen angeht:Ich schreibe Dir morgen mehr dazu.
Lieber Geri-Oc, dito: Ich schraibe Was dazu morgen.

Beste Grüße,
Marek

Da fehlt dann eine Turn-Restriction. Dass das früher trotz fehlender Restriction geklappt hat und der scharfe Left-Turn nicht vorgeschlagen wurde, war eher Glück.

Ich denke, ein Spur-zu-Spur Tagging ist in den meisten Fällen nicht notwendig. Beim Abiegen wird einfach die nächstliegende Spur genommen. Obige Kreuzung erfordert meiner Meinung nach kein Spur-zu-Spur Tagging. Dass man beim Abbiegen von einer zweiten Abbiegespur in der Regel in die entsprechende zweite Spur des Querweges fahren sollte, dürfte meines Erachtens so offensichtlich sein, dass man das nicht explizit eintragen muss. Bei obiger Kreuzung kann das meiner Meinung nach ohne Probleme berechnet werden.
Aber wie immer gilt, trotz Navi das eigene Hirn zu benutzen.

Wichtig, welche Spur benutzt werden soll, wird es erst abhängig vom weiteren Verlauf der Route, also von den nächsten Kreuzungen. Zweimal Rechts abbiegen bedeutet dann, dass man eine Spur wählen sollte, von der man beim nächsten Abbiegen auch rechts abbiegen darf. Beim Rechts-dann-Links Abbiegen muss man wohl einen Spurwechsel einplanen. Meiner Meinung nach geht das in der Regel ohne, dass man eine feste Spur-zu-Spur Beziehung einträgt.
Eine Ansage “An der nächsten Kreuzung rechts abbiegen und dann zu den linken zwei Spuren wechseln” sollte meiner Meinung nach (in der Regel) völlig ausreichen.

In dem Sinne,
“Wir stellen das Spur-Konzept bei OSM vor und wir diskutieren gemeinsam,
ob ggfs. noch Ergänzungen für komplexe Kreuzungen notwendig sind.”
ist das Spur-Tagging natürlich ein wichtiges Thema.

Man sollte aber generell darauf achten, dass ein Tagging-Schema möglichst einfach bleibt.
Mit zunehmender Komplexität wird ein Schema immer weniger verwendet.

Als Demo könnte man die Heinemannstraße in Bonn nehmen.
Auf dem ca. 1200m langen Stück mit getrennten Richtungsfahrbahnen sind 6 Kreuzungen (ohne Service-Wege). Dort habe ich in vielen Stunden Arbeit die turn-lanes erfasst. Der Aufwand schon dafür ist also nicht zu unterschätzen. Zusätzlich noch Spur-zu-Spur Beziehungen einzutragen, würde diesen Aufwand noch mal erheblich vergrößern. Ich würde mir das nicht mehr antun und ich denke, dass dies vielen anderen ähnlich gehen wird.

Edbert (Edbert)

Nein, das klappte, weil da jede Fahrspur als eigene highway=primary drin war (auch die, zwischen denen man wechseln darf; ist auch noch in den Daten zu sehen (war ja bestimmt nicht so wenig Aufwand das abzumalen))…
Das Lane-Tagging ist dort nur grob von mir eingebaut worden um eine OSM-Note zu schliessen und sollte noch verbessert werden.

Warum änderst Du aus BaWü solche Sachen in Sachsen? Ich finde, die Entscheidung welches Schema angewandet wird, sollte lokal getroffen werden.

Für jede Fahrspur (d.h. für ein lanes=4 vier Stück) jeweils ein highway=* oneway=* fällt imo nicht mehr unter “die Entscheidung welches Schema angewandet wird, sollte lokal getroffen werden”.