Ich habs mir mal gerade angeschaut. Für eine Entwicklerversion ist es schon eine tolle Sache. Es ist einfach zu bedienen und was es am Ende in die Daten schriebt ist ja nebensächlich, bzw. sollte man sich dann eher an der Auswertung orientieren.
Was da noch fehlt:
Eigenschaften pro Spur
Spuren auch ohne Kreuzung (freie Strecke, Kreisverkehr,…)
lanes=2 als default-Annahme verstehen.
Übergang zwischen den Spuren regeln
Dinge rückgängig machen/löschen können
Einige Tage Arbeit und es ist implementiert…
Ja, schon vor einer Weile. Es funktioniert zur Modellierung der Situation an Kreuzungen, aber sowohl das Plugin als auch das dahinter stehende Datenmodell kann eben nur das, d.h. es ist überspezialisiert. Die Eigenschaften von Spuren ohne Kreuzung in der Nähe kann man systembedingt nicht erfassen.
Wenn man es mit einer Möglichkeit zur Darstellung der Spuren entlang eines Straßenverlaufs kombinieren würde, könnte was daraus werden. Das ist aber nicht nur eine Implementierungsfrage, sondern dazu müssten die Autoren vielmehr über ihren Schatten springen und ihr Taggingschema teilweise aufgeben bzw. anpassen. Die Möglichkeit, das Schema von http://wiki.osm.org/Lanes an komplizierteren Kreuzungen mit Relationen ähnlich denen, die dieses Plugin erzeugt, zu kombinieren, wäre möglicherweise eine Überlegung wert.
Schade das das Projekt OpenStreetMap und nicht OpenWorldMap oder ähnlich heißt, dann das wird von machen Mappern offenbar als OpenCarMap verstanden. Das Problem ist doch schon mal, daß das Datenmodell, nicht wie bei einem Auto-Navi-Hersteller speziell auf seine Zwecke beschränkt und optimiert sein darf. Hier schrieb ja schon mal jemand das da solche Sachen wie avg_speed=* neben maxspeed=* benutzt werden, um die Berechnung der Fahrzeit zu verbessern.
Dann mappen wir ja die Realität, wenn da eben Spuren sind, warum sollte man die nicht auch als Fläche erfassen? Ja, da braucht man hochauflösende Imagery, usw., also macht man eine Abstraktion der Spurfläche als Linie/Weg, wir wir es ja jetzt auch schon für die “Straße” und für Gebäudeumrisse durch Knoten machen. Das Gute ist, das die Linien, jederzeit durch ihre Flächen ersetzt werden können, wenn man bessere Luftbilder/Daten hat und wenn irgendwann mal wirklich jemand die Pfastersteine mappen möchte. 
Das x Spuren die Fahrbahn (oder eine bessere Bezeichnung für die nächst höhere Abstarktionsstufe) bilden, kann man als Relation darstellen, genauso, das z.B. diese Fahrbahn, die Bürgersteige und der linksseite Radweg zusammen die X-Straße sein sollen.
Natürlich ist der kombinierte Fuß-/Radweg auch nur die Anordnung zweier Spuren, die zusammen dann als Relation den “Fuß-/Radweg” bilden.
Einzelspuren sind auch die beste Lösung, gerade auch in Hinblick auf die Erweiterbarkeit. Den Spurwechsel kann man z.B. so darstellen, wie ich es schon z.B. hier und in den Folgeposts des Threads beschrieben habe.
Da ist dann lane=yes dafür da, die neuen Spuren von existierenden highway=* zu trennen, dann wird jeweils mit :forward|backward|left|right|all=yes/no angegeben, in welche Richtung die Spur (nicht) benutzen dürfen. Obiges Beispiel wäre z.B. die rechteste Spur einer Einbahnstraße.
Nettes Programm, läuft aber anscheinend auf Linux nicht, scheidet also aus. Schade.
Gemeint hatte ich aber sowieso eine im Web gehostete Simulation eines Auto-Navis.
Vorsicht! bei diesem Wegweiser (und bei vielen anderen auch) handelt es sich um einen “dynamischen Wegweiser”, das heißt, der Inhalt verändert sich je nach Verkehrssituation. Wenn man genau hinsieht, kann man auf der linken Seite horizontale Linien erkennen, das sind die Kanten der waagrecht angeordneten Prismen zum Wechsel des Bilds. In diesem Fall hat man das Glück, dass sich dadurch die Spurzuordnung nicht ändert. Das ist aber oft nicht so. Beispiele:
http://upload.wikimedia.org/wikipedia/commons/4/4e/Verkehrsleitsystem_Nuernberg_1.JPG
und
http://upload.wikimedia.org/wikipedia/commons/3/31/Verkehrsleitsystem_Nuernberg_2.JPG
In beiden Fällen ändert sich die Spuraufteilung. Wie gehen Navis damit um?
Hast du ein Android-Smartphone? Da läufts auch
Das ist ein grundsätzliches Problem, dem nur begegnet werden könnte, wenn diese beliebigen Spurzuordnungen über TMC auswertbar wären. Und woher soll das Navi z.B. wissen, dass gerade Spielwarenmesse ist. Da würde ich es bei der allgemeinen Richtung “Flugplatz;Messe;Stadion” belassen.
Aber da sind wir schon wieder in Spezialfällen, die wir im Auge behalten sollten, aber nicht als “conditio sine qua non” gelten lassen müssen.
Vorsicht, auch die genannten Richtungen “Flugplatz”, “Messe” und “Stadion” wechseln!
Man lässt sich bei dieser Wegweiser-Art leicht täuschen und denkt, nur der LED-Teil wäre variabel. Tatsächlich schalten aber auch die anderen Symbole und Texte mit um.
Auf diesem Video sieht man das Umschalten der “dynamischen Wegweiser” sehr gut:
http://www.nuernberg.de/internet/verkehrsplanung/verkehrsleitsystem.html
Interessant wirds ab Minute 5.
Ich hoffe immer noch das Routing irgendwann auf osm.org einzieht ( http://routing.apis.dev.openstreetmap.org/ ). Das duerfte dem routing relevanten tagging (z.B. turn restrictions, maxspeed, access tags) in OSM ein deutlichen Schub geben. Bislang war eine visualisierung eines features auf osm.org immer einer der besten motivatoren fuer mapper und dies waere das equivalent.
Dann koennte man auch ein “quasi Standard” etablieren in dem man bestimmte tagging Schemata in der routing engine von osm.org (aller voraussicht OSRM) unterstuetzt. Das duerfte dann auch allen anderen navi Herstellern nuetzen.
Ich denke Mapfactor Navigator Free kommt dem schon recht nahe. Die Software ist wohl die gleiche wie sie auch fuer kommerzielle Daten verwenden. Sie unterstuetzt also die ganzen netten features sofern der Konverter das mit macht und ich habe bislang den Eindruck das sie recht bemueht sind moeglichst viele der features in ihrem Konverter zu unterstuetzen.
Da Mapfactor Navigator free auch noch auf alten WinCE 4.2 Geraeten mit 400Mhz arm 11 Processoren noch recht passable laeuft, haben vermutlich ettliche Leute noch alte SatNavgeraete rumliegen, die sie einfach auf OSM umruesten koennen. Leider scheint diese Wiederverwertung von alten SatNav Geraeten mit aktuellen OSM Daten nicht sonderlich bekannt zu sein.
Lediglich die Konvertierungshaeufigkeit ist mit “lediglich” ein mal pro Monat fuer Mapper nicht so ideal. Aber fuer mapper (zum debugging) ist etwas webbasiertes wahrscheinlich ohnehin besser.
an Mapfactor hatte ich auch schon gedacht. Zumindest dem Anschein nach sind die am weitesten. Wenn deren kommerziellen Produkte auch diese netten Features haben, wären sie eigentlich sogar noch besser geeignet als ein anderer Navi-Hersteller, denn bei Mapfactor fängt man nicht bei 30% an sondern bei 85% mit den Erklärungen. Sie kommen mir nur etwas passiv vor. Sie nutzen OSM aber es gibt kein richtiges Feedback. Vielleicht sind die besser geeignet und man müsste nur etwas auf sie zugehen? Wenn sie sich einbringen würden, könnte da was rauskommen. Und einen LKW Freak, was ein Standbein von denen zu sein scheint, haben wir hier ja auch.
Routing auf osm.org wäre auf jeden Fall wünschenswert und würde es deutlich einfacher machen allfällige Probleme früh zu finden. Das wiederum gäbe einen Schub für das Routing-relevante Tagging. Dass Routen anders verlaufen, als man das erwartet, liegt oft an Problemen in den Daten (unverbundene Wege, fehlende/falsche Abbiege-Relationen/…).
Ob es OSMR wird, was mit tagesaktuell und seiner Schnelligkeit durchaus Vorzüge hat, bleibt meiner Meinugn nach offen, solange OSMR nur Car-Routing unterstützt.
Für OSM, das ja als Projekt eine Geodatenbank ist, sehe ich drei Hauptanwendungen:
Was mir noch auf osm.org fehlt sind Qualitätssicherungstools (QA) wie:
Das erste kann als Overlay realisiert werden und soll ja irgendwann auch in osm.org integriert werden.
Keepright und OSM-Inspektor bräuchten wahrscheinlich eigene Seiten, da sie eigene Switches und Detail-Informationen verwenden. Eine Integration in dem Sinne, dass man das gleiche Zentrum verwendet, wenn man zwischen den Karten und den QA-Tools hin und her wechselt wäre eine gute Sache.
Edbert (EvanE)
ach hört doch auf mit Automotive-Industrie, als ob die sich mit solchen Amateuren wie bei OSM abgeben würden…
Zum Routing schonmal gar nicht!
Teilweise richtig: Routing machen wir (Automotive Industrie) selbstverständlich selbst. Sonst wird die OSM Community als das geschätzt, was sie eben ist.
Es gibt in dem Projekt Anfänger/Amateure, weil ohne sie würde dieses Projekt nicht wachsen können. Dank der Regel und eines gut funktionierenden Selbstkontrollmechanismus ist die Community sehr erfolgreich und auch sehr wohl ein ernst zu nehmender Partner.
Ich bin neulich zufällig über Geographic Data Files (GDF) gestolpert, laut Wikipedia “ein von der Autonavigationsindustrie entwickeltes konzeptuelles und logisches Datenmodell mit Definition eines nicht binären Standard-Dateiaustauschformates für vektorisierte Kartendaten, im Speziellen für Straßenkarten.”.
Links: Wiki, Wikipedia, GDF 3.0 Documentation & Manual (PDF Downloads), GDF5.0 ISO Standard 14825:2011, Diplomarbeit mit Zusammenfassung GDF (S.41-55)
Navigation Data Standard (NDS) / Physical Storage Format (PSF) ist/wird wohl ein aktuelleres binäres Standard-Format.
Links: NDS Association, Artikel: Navigation Data Standard (NDS): Bald Industriestandard? (aus Talk ML)
Theoretisch wären doch in einem solchen Standard die Anforderungen der Navi-Hersteller definiert? Man könnte das OSM Modell validieren, ob alle wesentlichen Eigenschaften abgebildet sind und sich in das Format konvertieren lassen.
Die Frage ist allerdings, ob GDF überhaupt eine praktische Relevanz hat und noch auf dem aktuellen Stand der Technik ist. Und NDS sieht nach geschlossener Gesellschaft aus, das Format wird wohl eher nicht offen sein (da steht was von Lizenzierung)?
Gruß,
Norbert
Liest sich fast wie Navibauers-Hausformat-Spezifikation. 
Nicht nur theoretisch, da ist doch alles drin, was man sich so wünscht! Habe die GDF 3.0-Spec mal stellenweise schnell überflogen (kann also sein, das ich durch das schnelle checken mancher ER-Diagramme und Interpretation mit Nichtnachlesen Detailfehler drin habe), hier mal kurz die Hinweise zu OSM-Näherungen:
Das Hausnummernmodell entspricht etwa der associatedStreet-Relation.
Straßenschilder sind ein Objekt am Standort, das eine Beziehung zum Transportweg hat, die sieht in etwa aus wie http://wiki.openstreetmap.org/wiki/Relations/Proposed/Directional_node mit zusätzlichem “via”.
Vorwegweiser sind auch nur Schilder, die zusätzlich mit den jeweiligen Ortsnamen als Entität verlinkt sind.
Das Straßenmodell ist ein abgespeckte Version von meinem Vorschlag:
Auf Level 1 kommen die Straßen, als zusammengestzten Verkehrsweg, bestehend ausschließlich aus Richtungsfahrbahnen.
Auf Level 2 kommen die Richtungsfahrbahnen als Spurgruppen, wobei man nur lanes=, minlanes= und maxlanes=* an den gerichteten (Einbahnstraßen-)Weg setzt (wie alle diese Atrribute (maxspeed=*, etc.) als Relation des betroffenen Verkehrweges). Für den Wechsel gibt’s, wenn ich es richtig sehe, dann Relationen zu den Wechselbeziehungen zwischen zwei Punkten auf Level 2-Wegsegmenten.
Kreuzungen und Parkflächen sind “generelle Verkehrsflächen”, d.h. das man dort in beliebige Richtungen fahren kann. (Auf den ersten Blick imho armseliges Spurmodell! (Nachtrag: Man bildet die “Spurführung” durch Abbiegebeschränkungsrelationen zwischen den Übertrittspunkten nach.))
Einzelspurmapping wird nicht wirklich unterstützt, genausowenig, wie die Existenz des Fuß-/Radweges neben der Fahrbahn als Bestandteil der Straße (das währe dann logisch fortgestzt Level 3). Möglicherweise ist es wirklich sinnvoller die Übertrittspunkte zu mappen, als meine 4-Richtungen-Idee, die für das Meiste funktionieren sollte, aber möglicherweise nicht für komplex geformte Spurflächen. Alle Richtungen der generellen Verkehrfläche (evtl. z.B. Marktplätze) deckt ja :all= noch mit ab, für Überfahrten auf z.B. Fußwege zum Parken kann man z.B. sowas wie car:right=parking benutzen.
Vieles haben wir schon, wenn sicher nicht immer in datentechnisch optimaler Form.
Nachtrag 2: Adressinterpolation macht man mit einer Relation auf der Straße, die in etwa das beinhaltet, das bei OSM an die Linie getaggt wird, mit dem Unterschied, das man die Straß0enseite angibt und so den künstlichen Weg dafür nicht mehr braucht. Atrributrelationen auf der Richtungsfahrbahn geben wahlweile von rechts nach links bzw. von links nach rechts mittels einer Bitmap an, ob die jeweilige Eigenschaft für die Spur gilt oder nicht.
Das Flächenwechselproblem (z.B. man kann ja als Fußgänger/Radfahrer ja quasi immer auf die Straße wechseln) hat man da also durch Punktabstraktion der Übertrittspunkte aus der Welt geschafft, mag für Autonavigation gut genug sein, ist aber für OSM zu ungenau. Teilfahrbahntrennungen gibt es nicht, es gibt als Typen nicht physische gesetzliche Trennungen wie Markierungen und dann noch physisch überfahrbare (Bordstein) und nicht überfahrbare Trennungen ((Autobahn-)Mittelstreifen). Das “Straßenbahnproblem” (siehe Spurmapping-Thread) umgeht man dadurch, das der ÖPNV gar nicht erst auf die Spurebene runter geht, also nur auf Level 1 oder Straßenabstraktion stattfindet. Soll heißen, da muß man auf jeden Fall für OSM basteln und zwar mit Einzelspuren/Transportwegen, die Spec ist aber 'ne gute Vorlage für Sachen, die man noch so berücksichtigen sollte.
Ich habe meine Versuche mal wieder rausgekramt. Über’s Wochenende werde ich noch ein wenig daran schrauben. Weil es hier leicht OT ist, werde ich dann im Ursprungs-Faden
http://forum.openstreetmap.org/viewtopic.php?id=14710
darüber berichten und die mit JOSM erstellte *.osm-Datei sowie die lanestyles.xml, mit der die lanes eingefärbt werden, veröffentlichen.
Testgebiet war übrigens dieser Bereich der beiden Brücken in Freiburg:
http://www.openstreetmap.org/?lat=47.990212&lon=7.84619&zoom=18&layers=M
Als Hintergrund verwendete ich die Aerowest-Bilder dieses Bereiches.
P.S.: Der Testbereich zeigt auch schön den Missbrauch von highway zum lane-mapping 
GDF wird (noch) benutzt aber es ist ein Format, von dem man sich tatsächlich verabschiedet. NDS ist eine geschlossene Gesellschaft. Ich habe dort von Anfang an an der Definition der 3D Inhalte mitgearbeitet.
Für OSM kann völlig egal sein was NDS ist und wie dieses Format aussieht. Man sollte ganz einfach innerhalb der Community weiter überlegen, was macht sinn wenn man Routing machen möchte. Alle kochen nur mit Wasser 
GDF soll ja schon lange abgelöst werden…
Auch wenn alle nur mit Wasser kochen, kann man sich von GDF auch inspirieren lassen, um ein paar Probleme im OSM lösen zu können. Bzgl. Auto-Navigation sind für mich folgende Themen nicht zufriedenstellend im OSM-Modell gelöst (neben anderen):
Beides ist in GDF recht allgemein gelöst.
Ich sehe nur das Problem, dass eine ähnlich “mächtige” Modellierung in OSM für den durchschnittlichen OSM-Mapper eher abschreckend ist.
Das ist richtig und ich hatte da auch meine Zweifel.
Allerdings sehe ich nun in Polen dass einige wenige User mit richtigen Werkzeugen innerhalb relativ kurzer Zeit die Relationen für die Autobahnen, Primary und Secondary bearbeiten konnten.
Ich vermute, dass vieles wirklich von einem guten und durchdachtem Werkzeug abhängt.
Man könnte es zumindest testen.
Zu den Punkten 1 und 2: Stimmt… daran wollen wir arbeiten.
