HERE HD maps mit einzelnen Fahrspuren

Hi,

warum erfasst man bei HERE HD maps jede einzelne Fahrspur und bei OSM nur die Mittellinie (als Weg) und die Anzahl der Fahrspuren (als Merkmal)?

Bild aus einem HERE 360-Beitrag.

Gruß
Atalanttore

Das ist leider noch aus den alten Zeiten so. Früher hat man gesagt, es wäre zu kompliziert, jede Spur einzeln zu erfassen. Das es geht, zeigt das Schienennetz. Aber heute ist es zu kompliziert, alles zu ändern.

Denn es muss ja nicht nur die Datenbank geändert werden, sondern auch alle Dienste müssen upgedated werden. Das geht bei Mapnik los und hört beim Navi im Auto auf.

Langfristig wird das sicherlich kommen. Entweder als “Spur” oder (hoffentlich) als “Fläche”.

Tun sie das? Oder wurden die Linien nur zu Visualisierungszwecken eingefügt? Ich kenne leider das Datenmodell von HERE HD nicht und könnte nur Mutmaßungen anstellen… Möglicherweise erfassen sie jede einzelne Fahrspur als Fläche.

Fakt ist, dass sie mit Lasertechnik die gesamte Umgebung mit einer Genauigkeit von 10-20 cm erfasst haben. Das ist eine ganz andere Hausnummer und nicht vergleichbar mit OSM.

Was für ein Aufwand … und nach jeder baulichen Änderung müssen sie wieder mit dem Laser anrücken.

Das ist wohl das was die Autobauer am meisten interessiert um mit ihren Fahrassistenen der nächsten Generation hantieren zu können. GPS selbst gibt sowas noch nicht her, aber in Kombination mit den anderen Diensten könnte man das Auto Fahrspurengenau orten.

Is es ni so das GPS das sowieso ni hergibt?
Deshalb warten wir ja auf Galileo

Hoffentlich - vor Jahren wurden solche “Versuche” (hw=lane) als falsch abgetan. Und wieso muss vieles geändert werden - Routing-Programme haben damals über diese lanes geroutet - nur die Navis haben nichts verstanden. Das lanes-Schema ist ja gut und richtig auf durchgehenden Streckenabschnitten. An Kreuzungen zeigt sich aber, dass es nicht ausreicht.

EDIT: lanes=2 in Verbindung mit hw=lane ist z.B. auch bei zwei Linksabbieger-Spuren an einem hw=lane “richtig”

GPS zusammen mit einem Korrekturdienst (z.B. SAPOS) erlaubt die Bestimmung von festen Meßpunkten im Millimeterbereich (z.B. Lagegenauigkeit ±2 cm, Höhengenauigkeit ±4 cm). Wie das für sich schnell bewegende Objekte aussieht, kann ich aber nicht sagen.

Gruß Klaus

Galileo ist im Testbetrieb obwohl noch Satelliten fehlen, sind nun 8 von 30. 2016 soll es endlich los gehen. Es gibt aber schon das russische System und in Kombination mit GPS wäre das ein Quantensprung. Was fehlt ist die bezahlbare Hardware.

Dafür brsuchste aber feste Referenz Stationen

?

Ein-Frequenz Empfänger die “Rohdaten” ausgeben und somit RTK fähig sind gibts schon lange lange im durchaus erschwinglichen Bereich (auch kombiniert mit GLONASS) , typischerweise kostet die Antenne mehr (wenn man im cm/mm Bereich messen will muss die Antenne z.B. ausgemessen sein). Man muss auf jeden fall in irgendeiner Form noch eine Basisstation haben entweder in echt oder virtuell wie typischerweise von den staatlichen Vermessungsdiensten angeboten.

Was es noch -nicht- erschwinglich gibt, sind 2-Frequenzempfänger, die Erwartung ist aber, dass sich dies langsam ändert auch mit verfügbarkeit des L5 Signals, siehe z.B. http://gpsworld.com/why-the-price-of-precision-receivers-drop/ (2-Frequenz Empfänger können mit einem Gerät die atmospährischen Störungen rausrechnen und brauchen keine Basisstation).

Gallileo hat meines Wissens wenn man mal das Marketing ignoriert 5 im Prinzip funktionierende Satelliten, nicht 8 (1 anscheinend DOA, 2 auf falscher Umlaufbahn die man vielleicht für irgendwas mal brauchen kann).

Simon

PS: ich bezweifele ob man von ein Paar in eine mit laser scanner generierte Punktwolke reingezeichnete Linien wirklich ablesen kann wie Here tatsächlich die Fahrspuren modelliert. Es gibt aber kein Grund wieso man das nicht rückwärts kompatibel auch in OSM könnte, dass Problem besteht ja hauptsächlich in Kreuzungen wo es nicht klar ist wie man Abbiegebeschränkungen und ähnliches vernünftig modelliert.

https://de.wikipedia.org/wiki/Galileo_%28Satellitennavigation%29

Test aus dem Jahr 2002, LGV Hamburg: 2cm in der XY Ebene bei der Geschwindigkeit 80km/h
Ich bin auch für die Fahrspur Erfassung, aber wir sehen ja, wie schwierig das mit der Erfassung der Flächen gelaufen ist. Trotzdem sollten wir uns damit auseinander setzen. Rückwärts Kompatibilität kann uns nicht die Zukunft verbauen.

Meines Erachtens brauchen wir dringend eine Möglichkeit die Fahrspuren funktional und geometrisch korrekt zu beschreiben.

Den Ansatz, Mittellinien von Fahrspuren zu zeichen, halte ich für falsch. Dieser Ansatz macht vieles kompliziert und er kann die Geometrie der Straßen zwar besser als bisher, jedoch immer noch nicht korrekt beschreiben. Sollte für eine Klasse von Anwendungen ein Datenmodell mit Einzelspurwegen sehr vorteilhaft sein, so könnte man eine zweite Datenbank bereitstellen, die ein derartiges aus geeigneten OSM Rohdaten automatisch generiertes Datenmodell enthält. Damit müßte dann nicht jeder Anwender die Konversion selbst durchführen, was sicher einiges an mathematischen Know-How erfordern würde.

Einen Flächenansatz auf Basis normaler OSM-Flächen (geschlossener Wege) halte ich ebenso für ungeeignet. Flächen von Straßenteilen brauchen eine Richtung und unterscheidbare Längs- und Stirnseiten. Das gibt das Datenmodell der OSM-Fläche nicht her. Sollte für eine Klasse von Anwendungen (z.B. gewisse Renderer) ein Datenmodell mit OSM-Flächen sehr vorteilhaft sein, so könnte man auch hier eine zweite Datenbank bereitstellen, die ein derartiges aus geeigneten OSM Rohdaten automatisch generiertes Datenmodell enthält.

Ds ist richtig, wobei es neben Kreuzungen auch noch andere Problemstellen wie z.B. bei Veränderung der Spuranzahl gibt. Funktional ist die fehlende Beschreibung der Konnektivität zwischen den Spuren das Problem, wobei dies durch erweitertes Tagging (alternativ mit oder ohne Hilfe von Relationen) lösbar wäre. Leider sind die bisher dazu verwendeten Ansätze leider alle etwas zu kurz gedacht und bieten keine hinreichend universelle Funktionalität.

Um die Geometrieprobleme zu lösen, sollte man meines Erachtens dort, wo das lanes Schema nicht zur alleinigen Geometriebeschreibung ausreichend ist, zusätzliche Hilfslinien (OSM-Wege) einzeichnen, an denen die Spuren dann ausgerichtet werden können. Diese Wege sollten alles Objekte sein, die recht exakt aus dem Luftbild abzeichenbar sind, wie zum Beispiel Fahrbahnmarkierungen oder Fahrbahnränder sein. Damit man diese Objekte nicht alle mit Relationen an den Highway koppeln muss, könnten sie durch ein Tag wie beispielsweise “projection=left” dem (hier links) daneben liegenden Highway geometrisch zuordnen.

Für die Auswertung mag es besser sein, wenn diese Hilfsobjekte mittels Relation angebunden sind. Dies könnten aber in eine separaten Datenbank automatisch generierte Relationen sein, so dass das Editieren der OSM Rohdaten nicht erschwert wird.

Um ehrlich zu sein, verstehe ich das Problem nicht ganz. Man kann doch auch heute schon die Spuren geometrisch korrekt angeben, wenn man als Voraussetzung annimmt, dass der way auf der Mitte der Fahrbahn liegt (und das sollte ja immer so sein). Denn die Anzahl der Fahrstreifen kann ja nebst jeweiliger Breite getaggt werden. Entsprechende JOSM-Styles stellen das sogar korrekt dar.

Und was die Kreuzungen betrifft … es mag schöner gehen, aber wenn man die Turn-Restrictions sauber nutzt, ist auch das in den meisten Fällen lösbar (Stichwort “merge to”).

Warum also was neues erfinden? Wie gesagt, schöner geht immer, aber das derzeitige Modell stellt meines Erachtens fast alle Möglichkeiten bereit, die man braucht. Ausnahmen wären vielleicht solche Fälle, in denen z.B. Einmündungen auf einzelne Fahrstreifen getaggt werden müssen. Aber auch das lässt sich oft mit Hilfe der Change-Restrictions lösen.

Ja, das ist der Standard. Es gibt aber gute Gründe davon abzuweichen (kein Hin- und Herspringen wenn sich die Anzahl der Spuren ändert) und dafür gibt es placement.

Hast Du schonmal Lanes, Turn:lanes oder dergleichen gemalt? Was ist da genau kompliziert?

Nein, das ist falsch.

.

Siehe http://forum.openstreetmap.org/viewtopic.php?pid=518816#p518816 (Wobei ich selbst ohne placement das grosse Problem nicht sehe)

Nein?! Im bisherigen (turn|direction|destinatin|etc)Lanes-schema gibt es nur winzige Tagging-Lücken. Eine konnektivität kann man entweder als gegeben annehmen oder - so change:lanes etc. gemappt sind - ausschliessen.

Ein getrenntes/separates Lanetagging bringt Unmengen neue richtige Probleme mit sich. Das bisherige Tagging funktioniert prima.

Ich weiss nicht, wozu man da Relationen bräuchte.

Für diese wenigen zweifelhaften Fälle gibt es auch ein Proposal mit dem “transit” Key ( http://wiki.openstreetmap.org/wiki/Proposed_features/transit ). Liest sich recht kompliziert, aber ist in den wenigsten Fällen nötig und bei den wenigen nötigen Fällen einfach anzuwenden.

Ich hab das Gefühl das hier ein Mißverständnis vorliegt. Es geht hier um den Ansatz die Mittellinie jeder Fahrspur separat zu malen und zu taggen. Das dürfte doch genau das sein, was du weiter unten selbst als richtig problematisch bezeichnest:

Um die Konnektivität an Knoten zu beschreiben, wo drei oder mehr OSM-Wege aufeinandertreffen, sind Relationen schon ein ein sehr naheliegendes Mittel. Wirklich zwingend sind sie jedoch nicht, da man z.B. die anderen Wege relativ zu dem aktuell zu taggenden Weg im Uhrzeigersinn durchnummeriert (z.B. als Ziel einer Verbindung von Fahrspuren) bezeichnen könnte.

Ok, ich hab das als Strassen-mittel-linie verstanden. Nehme alles zurück und behaupte das Gegenteil - da:

bin ich davon ausgegangen, dass Du allgemein und im Speziellen geri-ocs Aufgedrösel begrüssen würdest.