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.
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.
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.
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.
Mit change:lanes beschreibt die Konnektivität zwischen den Spuren eines einzelnen OSM-Weges. Das Problem liegt eher in der Konnektivität zwischen zwei oder mehr aufeinandertreffenden OSM-Wegen.
Beispiel: Einbahnstraße, 2 Spuren gehen in 3 über. Wie unterscheiden wir die 6 möglichen Fälle:
Neue Spur kommt links hinzu (nur über Spurwechsel erreichbar)
Neue Spur kommt in der Mitte hinzu (nur über Spurwechsel erreichbar)
Neu Spur kommt rechts hinzu (nur über Spurwechsel erreichbar)
linke Spur teilt sich auf zwei Spuren auf
rechte Spur teilt sich in zwei Spuren auf
Übergang ohne Spurmarkierung im Kreuzungsbereich (mittlere Spur ist von beiden Spuren des vorangegangenen OSM-Weges ohne Spurwechsel erreichbar)
Bezogen auf die Anzahl von Verbindungspunkten von OSM-Wegen sind es tatsächlich wenig Zweifelsfälle, in absoluten Zahlen jedoch extrem viele.
Das Proposal ist schon ein Ansatz, der in die richtige Richtung geht, um das Konnektivitäsproblem zu lösen. Allerdings halte ich dies weder für etabliert noch für ausgereift.
Ich halte dies Proposal für unnötig kompliziert und funktional für zu eingeschränkt (siehe dazu auch meine schon etwas älteren Kommentare im Wiki).
Da man für Key placement ohnehin eine Numerierung der Fahrspuren eingeführt hat, kann man diese auch gleich zur Angabe der Konnektivität nutzen.
Das sollte eine deutlich einfacher verständliche Beschreibung und eine erhöhte Funktionalität ergeben. Für die oben genannten Beispielfälle könnte das Tagging dann wie folgt aussehen.
transit:lanes=2|3
transit:lanes=1|3
transit:lanes=1|2
transit:lanes=1;2|3
transit:lanes=1|2;3
transit:lanes=1;2|2;3
In den Fällen a-c wird die Erreichbarkeit der neuen Spur wird druch die (Nicht-)Verwendung von change:lanes im zweiten OSM-Weg definiert.
Wir haben eine dreistreifige Straße (also mit 3 Spuren, wie man das ja meist nennt, sprich insgesamt 4 Begrenzungslinien, keine baulichen Trennungen).
Es gibt jetzt zwei Möglichkeiten:
a) Es wird 1 Way “gemalt” und mit entsprechenden Tags versehen.
b) Es werden 3 Ways “gemalt” und separat mit Tags versehen.
Ich bin immernoch im a)-Team unterwegs, bin mir aber bei MKnight und slhh nicht mehr ganz sicher
Könnte man in manchen Fällen, allerdings: für placement bezieht man sich immer auf die Spuren desselben Weges, das ist einfach überschaubar und auch automatisch kontrollierbar. Für transit bezieht man sich auf die Spuren eines anderen Weges. Und wenn sich die Straße aufteilt hat man zwei Zielwege jeder mit einer Spur Nummer 1. Die Wege kann man nicht durchnummerieren, sonst gibt es ein großes Chaos wenn doch mal jemand noch einen zusätzlichen Trampelpfad zwischen zwei Straßen einträgt.
Aber wir schweifen wohl etwas vom Thema ab.
Das funktioniert vermutlich für weit mehr als 90% der Straßenlänge gut, und zwar überall dort, wo die Fahrbahn- und Fahrspurbreiten entlang des des OSM-Weges konstant bleiben. Der Rest schaft die Geometrieprobleme. In der Realität ändert sich die Fahrbahn- oder Fahrspurbreite selten sprunghaft, sondern meist kontinuierlich. Die OSM-Wege in infinitesimal kurze Abschnitte zu zerlegen, würde zwar eine hinreichend genaue Geometriebeschreibung ermöglichen, ist aber sicher nicht als praktikable Lösung anzusehen.
Gewisse Verbesserungen der Geometriebeschreibung sind noch durch erweitertes Tagging möglich. So könnte z.B. mittels width:lanes:start und width:lanes:end die Spurbreite am Anfang und Ende des OSM Weges separat spezifiziert werden. Derartiges sollte man auch nutzen, zumal das für viele Anwendungen schon hinreichend sein mag.
In Bereichen wo man sehr hoch auflösende Karten erzeugen möchte, wird dies aber nicht alle Ansprüche an die Qualität der Straßengeometrie befriedigen können. Um diese befriedigen zu können, wäre es sinnvoll Ergänzungen zum bisherigen System zu entwickeln.
Prinzipiell sollte es bei a) bleiben. An Stellen wo dies die Geometrie nicht hinreichend beschreibt, sollte es jedoch zulässig sein, zusätzlich die 4 Begrenzungslinien mit zu malen, soweit Ihre Lage nicht vom Tagging des Hauptweges korrekt beschrieben wird. In der Realität wären wohl meist ein oder zwei zu malende Begrenzungslinien ausreichend.
Anwendungen, die die zusätzliche Geometrieinformation der Begrenzungslinien nicht benötigen, können diese einfach ausfiltern. Dann liegt für diese wieder rein a) vor.
Meines Erachtens:
Nach der Darstellung in OSM "umfahren sich die Linksabbieger - entspricht aber nicht der Realität und kann somit auch nicht “real” angezeigt werden. Auch Router können das nicht “berechnen”, da es in lanes und turn:lanes falsch erfasst ist.
Man sollte vielleicht einmal die Kreuzung (die bei Mapillary in Bildern für alle zugänglich ist - auf Luftbild umschalten) mappen (nicht hochladen - aber den Datensatz zur Diskussion stellen). Eventuell mit neuen/anderen tags und Text, warum so … Vielleicht kann die “Varianten” auch jemand visualisieren - (Meinetwegen auch eine andere Kreuzung).
http://map.project-osrm.org/ routet mir alle möglichen Sachen auf der Kreuzung so wie ich es erwarte. An den Lanes und turn:lanes sehe ich auch keine Fehler.
(Ich geb zu, dass das alles nicht exakt mit der Realität übereinstimmt, aber abstrahiert funktioniert es nahezu genauso)
Es geht um detaillierteres Mappen bzw. Erfassen (HERE HD maps mit einzelnen Fahrspuren) - abstrahiert funktioniert auch ein Kreuzungspunkt. Das war vor 10 Jahren - heute etwas detailreicher - in 10 Jahren …
Deswegen der “Vorschlag” - einmal unabhängig andere Ideen aufzuzeigen, die es eventuell zukünftig geben kann (area:highway; keinen gemeinsamen node, wenn ich den Weg dort nicht verlassen kann; highway=lane in Kreuzungsbereichen, die in größeren Zoomstufen detailieren können; getrennte ways für Fuß und Rad.)
Solche Kreuzungen (diese kenne ich zufällig selber) gibt es aber etliche, und sie sind unterschiedlich getaggt worden. Ich selbst halte mich in solchen Fällen eher an den Ansatz, dass man den Inhalt darstellt, sehe es aus, wie es wolle (“Man taggt nicht für den Renderer.”), was in diesem Falle heißt, dass die Übergänge eben wirklich separat getaggt werden. Mal gucken, ob ich ein Beispiel finde … stimmt, hier in Schwerin zum Beispiel oder hier in Köln.
In deinem Schwerin-Beispiel stellt sich mir die Frage, warum die beiden Fahrtrichtungen westlich der Kreuzung getrennt erfasst sind - dort gibt es keine bauliche Trennung.
Das Köln-Beispiel ist ein absolutes Negativbeispiel - die Kanelstraße hat nirgends eine bauliche Trennung und trotzdem sind da drei getrennte Highways erfasst, die über lange Strecken parallel verlaufen - auch da wo man Spuren noch wechseln darf. Das führt zu vielen falschen Anweisungen bei Navis, da keine heute verfügbare Navi-Hardware (spezielle professionelle differentielle GPS-Geräte ausgenommen) eine so hohe Genauigkeit hat um zu bestimmen, auf welcher Spur man gerade ist.
Wenn man direkt auf der Kreuzung solche Abbiegespuren getrennt von den Hauptfahrbahnen mappt, werden die wenigsten widersprechen. Wirkliche Probleme gibt es erst, wenn die Spuren über längere Strecken getrennt sind, z.B. in Bereichen wo die Spur noch gewechselt werden darf.
