Der Luftbildmaler will sowas aber nicht ueber ein weiteres Tag am bestehenden Weg erfassen, sondern ueber einen eigenen Weg. Damit kann man letztendlich die Geometry genauer erfassen (wo genau zweigt die Spur ab, auf welcher Seite liegt sie, gibt es dazwischen noch irgendwelche Verkehrsinseln, wo genau sind die Ampeln, wo sind die Fussgaengerquerungen, usw.). Fuer die automatische Auswertung sind diese Extrawege aber ein einziger Alptraum, da sie zwar sehr praeziese die Geometry abbilden, aber die logischen Zusammenhaenge unwahrscheinlich verwirren. Fuer die Navigation ist solches Mikrotagging z.B. komplett unbrauchbar, da der Abstand zwischen den Elementen kleiner ist als die Genauigkeit des Navis => das Navi kann nicht entscheiden wo man sich gerade befindet.
Diese öfters geäußerte Aussage ist so nicht ganz vollständig. Für die Berechnung einer Route wären solche Spurinformationen nämlich durchaus zu verwenden. Auch bestimmte grafische Hilfen zum Einordnen könnte man auf dieser Basis erstellen. All diese Funktionen eines Navis leiden nicht unter der fehlenden Genauigkeit.
Worum es dir wohl eigentlich geht: Es ist mit GPS in der Tat nicht möglich, seine eigene Position verlässlich spurgenau zu bestimmen. Das hat aber nichts mit der Art des Taggings zu tun, sondern gilt unabhängig von unserem Datenmodell in OSM. Darüber hinaus ist denkbar, dass durch technologischen Fortschritt sogar diese Einschränkung weitgehend wegfallen wird, beispielsweise werden schon Bildverarbeitungssysteme für die Spurerkennung erprobt.
Mir ist klar, dass für viele Anwendungen ein beachtlicher Vorverarbeitungsaufwand nötig wäre, um als separate Ways eingetragene Spuren angemessen zu berücksichtigen. Ich habe allerdings noch keinen handhabbaren Vorschlag gesehen, der ohne eine solche separate Modellierung eine vollständige Wiedergabe der Straßengeometrie auch bei komplexeren Fällen als der Autobahnausfahrt erlaubt. Daher kann ich mir vorstellen, dass die Entwicklung darauf hinauslaufen wird.
Genaugenommen ist das Problem eher, dass man den Navis nicht vermitteln kann, wo ein Spurwechesel moeglich ist und wo nicht.
Angenommen man zeichnet die Abbiegespur als separaten Weg, der am Beginn der Spur von der normalen Strasse abzweigt. Wenn jetzt das Navi falsch entscheidet, ob man auf der Abbiegespur oder auf der normalen Strasse unterwegs ist (egal ob man abbiegen oder geradeaus fahren will), dann wird das Navi jetzt eine falsche Neuberechnung der Route anschmeissen und erst hinter der Kreuzung wieder brauchbare Informationen liefern.
Wenn man beim Tagging bereits auf derartige begrenzungen Ruecksicht nimmt, kann man sich das Leben in der Anwendung erheblich einfacher machen. (Ein paar Postings weiter oben hatte doch hier jemand erst gerade mangelnde Ruecksicht auf die Endanwenudung beklagt.)
Fein, dann koennen wir ja mit dem Erfassen anfangen, wenn es soweit ist. Denn vorher macht man sich damit das Leben ja nur unnoetig schwer.
Bei der Erfassung heute bereits zu beruecksichtigen, was die Zukunft irgendwann einmal vielleicht bringen wird, kann man als Argument fuer jeden beliebigen Unsinn nutzen.
Ich wuerde sogar soweit gehen zu behaupten, dass es haeufig praktisch unmoeglich sein wird. Fuer unser menschliches Gehirn ist es (meistens) eine Kleinigkeit bei einem Blick auf ein Bild zu erkennen, was dort wo abgebildet ist. Eine vergleichbare Erkennung automatisisert zu leisten ist beim heutigen Stand der Technik utopisch.
Ich denke schon, dass man das alles auch als gemeinsamen Weg erfassen koennte, bei dem ueber Zusatztags beschrieben wird, welche Spurgeometrie durch diesen Wegabschnitt repraesentiert wird. Das wird dann aber z.T. extrem kompliziert werden.
Meine Befuerchtung ist eher, dass die Luftbildmaler beim Datenerfassen den Loewenanteil leisten und durch diese Masse die Entwicklung bei OSM in eine suboptimale Richtung druecken. Nicht ohne Grund ist der haeufigste Satz in irgendwelchen Diskussionen “Wir mappen nicht fuer den Renderer.” Genau das ist es naemlich, was ein Grossteil der Mapper ausschliesslich tut, und der Rest von OSM muss dann sehen, was er aus den so gewonnen Daten an Informationen gewinnen kann.
Eine Loesung fuer dieses Zwiespalt koennte ich mir so vorstellen, dass man letztendlich in OSM beides erfasst: Eine Beschreibung der Objekte fuer die Anzeige im Renderer und ein abstrahiertes Modell fuer die automatische Datennutzung. Das widerspricht aber dem bisher heiligen Ansatz, dass jedes Objekt in der Wirklichkeit auch nur ein mal in der OSM-Datenbank auftauchen soll. Aber mit der stellenweise eingefuehrten Erfassung der Strassen als Falechen ist man ja bereits einen Schritt in diese Richtung gegangen.
Selbstverständlich ist es notwendig, den Zusammenhang zwischen separaten Spur-Ways herstellen zu können. Ohne diese Möglichkeit könnte ja wirklich niemand - weder ein Renderer noch ein Router - etwas damit anfangen. Diese Notwendigkeit macht alles natürlich noch etwas hässlicher, egal ob man jetzt Relationen, die schon öfters diskutierten Straßenflächen oder Tags zum Zusammenfassen nehmen will.
Auf talk-de hatten iirc die Leute vom Blindenrouting vorgeschlagen, Gehsteige als separate Ways zu taggen, weil damit die für ihre Anwendung nötigen Infos am besten auszudrücken wären. Nur als Beispiel für das Kernproblem bei der Orientierung an Anwendungsanforderungen: Es gibt nicht die Anwendung.
Für meinen Teil habe ich mir an diesem Thema schon mit eigenem Proposal samt JOSM-Plugin die Zähne ausgebissen…
Der Spurquerschnitt an einem Wegabschnitt sogar noch das kleinere Problem - da gibt es schon x Vorschläge, die allesamt funktionieren würden. Warum man überhaupt auf die Idee kommt, separate Ways zu benutzen: a) man kann leicht Tags ranhängen ohne mit Workarounds in der Art lane:left:5:surface=asphalt arbeiten zu müssen, und b) man könnte damit auf eine für den Mapper verständliche Weise darstellen, wo sich Spuren aufspalten, vereinigen, von der Straße lösen usw.
Punkt a ist jetzt nicht so wild, aber b - der Übergang zwischen den Wegabschnitten - ist mit Tags doch hart.
Das ist prinzipiell denkbar und sicher ein sinnvoller erster Schritt, schon weil so Konflikte abgemildert werden. Im Allgemeinen würde ich es allerdings bevorzugen, die Daten nicht doppelt abzulegen, sondern automatisch umzuwandeln. Eine robuste, frei verfügbare Tool-Pipeline, die etwa “Augentier-freundliche” OSM-Daten in abstraktere Repräsentationen überführt, würde Datennutzern unter die Arme greifen und könnte bis dahin übergangsweise nötiges Doppel-Tagging auf lange Sicht ablösen. Das setzt natürlich voraus, dass die gewünschten Infos überhaupt noch vorhanden und ohne Raten zugänglich sind.
Sofern möglich, sollte man immer die Realität abbilden (http://wiki.openstreetmap.org/wiki/DE:Good_practice) Das Problem ist da aber auch die begrenzte GPS-Auflösung, so das man selbst bei einem guten Empfänger Über 90% Positionswahrscheinlichkeit erst bei 6 m hat, was also ca. 2 Spuren sind. Aber wenn ich kann zeichne ich auch jeden noch so kleinen Fußweg und auch straßenbegleitende Radwege ein, weil die sind ja schließlich da. Nur ein kombinierter Fuß-/Radweg läßt sich auch bei reduzierten Genauigkeitsanforderungen nicht mehr weiter aufsplitten, außer man mittelt die Wege um den Track und trägt den Abstand per Hand ein, was ich aber nicht mache. Die Leute die jammern, weil ihr Routingkartengenerator es nicht schafft, die zusätzlichen Infos weg zu werfen, sind mir da egal, weil wegwerfen kann man immer und wenn die Programme es noch nicht können, dann werden sie es in Bälde sicher lernen müssen.
Ja, man könnte alles auch an den Weg hängen, nur ist das dann weder schön, noch vernüftig wartbar oder bei key:subkey:subbubkey:poperty=value dann bald nicht mehr automatisiert in vernüftiger Zeit auswertbar. Das Problem ist, daß man oft Baumstrußturen und Beziehungen hat und man die im Moment nur über Relationen abbilden kann, weshalb ich da auch eine entsprechnden Vorschlag für die API 0.7 gemacht habe. Solange man die Objekte noch sinnvoll einzeichnen kann, ist das Filtern der bessere Weg, wenn nicht, fängt man dann an, sich aus Relationen und dessen Eltern-Kind-Beziehungen einen Baum zusammen zu bauen, der dann zwar die Realität gut abbildet, aber wenn man da eine Weile angebaut hat, unter Umständen recht komplex und damit wartunsunfreudlich wird, man abgesehen, daß man überhaupt erst mal Relationserfahrungen braucht.
Ja, genau man erfaßt die Daten in komplexerer Form mit allen nötigen Infos und dann müssen da Programme sie passend für Renderer und die Router umwandern, weil wegwerfen kann man ja eben immer noch, wenn man die Daten erst einmal erfaßt hat.
Und wie kennzeichnest du die strassenbegleitenden Extrawege, damit die Programme wissen, welche Wege sie wegzuwerfen haben?
Und wie machst du kenntlich, dass man an jeder Position vom Fussweg auf die Strasse bzw. andere Strassenseite wechseln kann?
Jemand, der behauptet mit separat eingetragenen Fusswegen ein besseres Routing fuer Blinde hinbekommen zu koennen, dem unterstelle ich jetzt erstmal, dass er das in der Praxis noch nicht ausprobiert hat. Genau wie bei der Fahrradnavigation ist das Problem, dass ein Navi unterwegs einfach nicht sicher aufloesen kann, ob man auf der Fahrbahn oder auf einem Seitenweg (welchem?) ist. Das wird zwar haeufig klappen, aber bei nicht optimalen Empfangsbedingungen (Haeuserschluchten) oder nach Abzweigungen ist das einfach illusorisch.
Und auch fuer die Blindennavigation sollte es mit dem Routing deutlich einfacher gehen, wenn man eine Strasse mit Zusatztags fuer die Seitenwege hat, als wenn man die Seitenwege einzeln ohne logische Verbindung zur Fahrbahn hat.
Mal zurück zur Abbiegespur:
Was haltet ihr davon, den Straßenabschnitt, zu dem diese Spur parallel geführt gehört, mit einem tag turn-lane=yes zu versehen, der über eine Relation ähnlich “restriction” mit dem way des entsprechenden link-/junktion-ways verbunden wird?
Renderer könnten das auswerten, indem sie die Straße etwas breiter zeichnen und analog zu oneway=yes z.B. einen schrägen Abbiegepfeil darauf setzen.
Die Spur ist “vorhanden” in der Realität - sie könnte/sollte also auch “gemapped” werden wie ich finde. Und als “turn-lane=yes” ist sie ja als eine “besondere” zu erkennen und auszuwerten - und erlaubt das “hin und herwechseln”, kann also nicht “verwechselt” werden mit den anderen Spuren.
Renderer können damit dann schonmal was anfangen.
Auch bin ich mir nicht so sicher ob Renderer (derzeit) wirklich die Realität 1:1 abbilden müssen. Wenn ich von der Autobahn A6 auf die A659 wechseln will Richtung Mannheim dann möchte ich eigentlich nur gerne sowas wie “rechts abbiegen auf die Abbiegespur und dann links halten” hören. Ob es da 2, 3, 4 Spuren gibt vor mir wäre erstmal nicht soooo wichtig - Hauptsache ich weiß “in etwa” wo ich “als nächstes” hinmuß, wird ja nur links, geradeaus oder rechts sein können (in DE wohl eher nur links/rechts). Und wenn die Abfahrt komplexer ist (3 mal wechseln oder sowas) würde es mir auch reichen danach zu hören “nun rechts abfahren auf die … Richtung …” und danach “nun links fahren auf die … Richtung …”. Wäre jedenfalls mein Gedanke dazu noch gerade.
@de_muur: Tja, genau das ist das Problem. Vermutlich wird man es mit Relationen lösen müssen oder das Datenmodell von OSM in eine geeignete Richtung weiterentwickeln.