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