So wie bei der Lizenzdiskussion? “Sag ja oder verschwinde!”
weissnich,
ajoessen
OT on:
Unter http://forum.openstreetmap.org/viewtopic.php?pid=209019#p209019
habe ich mich unter anderem auch schon mal darüber ausgelassen 
OT off:
Mindestens dieses Thema hier erfordert einfach die Zusammenarbeit von Mappern, Datenbank-Gurus und Entwicklern von Routern und ein gesundes Maß an Kompromissbereitschaft mit Fokus auf eine für alle praktikable Lösung.
Sollst auch mal recht haben, das hatte ich nicht ordentlich gelesen.
Wenn wir aus allen anderen Gruenden jeweils die Wege teilen, dann halte ich es fuer eine ziemlich dumme Idee, bei einer weiteren Wegeigenschaft dieses Verfahren aufzugeben und ploetzlich etwas voellig neues einzufuehren. Alle anderen Tags koennte man auch per Relation an die Wege haengen. Aber wuerde dann da noch irgend jemand durchblicken?
Das ganze soll ja auch nicht nur per JOSM-Plugin bedienbar sein, sondern muss auch ohne spezielle Benutzeroberflaeche noch verstanden werden koennen.
=> Ein Grund mehr, warum man nicht ein Beispiel-JOSM-Plugin fuer die Bewertung eines Tagging-Schemas heranziehen sollte.
Gruss
Torsten
Die Idee, Menschen und Güter mit Hilfe von damp- oder motorbetriebenen Fahrzeugen zu befördern , wurde anfangs auch als dumme Idee abgetan und hat sich doch durchgesetzt 
Welches Relationskonstrukt in OSM wird ohne Hilfmittel in Potlatch, JOSM usw. angelegt und von allen verstanden?
Das Tagging-Schema ergibt sich aus dem proposal und wird anhand dessen bewertet. Das Plugin setzt das Tagging-Schema anwenderfreundlich um. Beides ist sicher ausbaufähig, kann aber auch in Folge einer genaueren Betrachtung verworfen werden. Kommen wir zu dem Ergebnis, dass das Proposal unbrauchbar ist, macht das Plugin auch so keinen Sinn mehr.
Für mich zeigen alle drei oben genannten und mit Plugins hinterlegten Proposals lediglich, dass für die verschiedenen Ansätze eine technische Unterstützung des Mappers bei der Eingabe möglich ist (und auch bei der Komplexität Sinn macht).
Und fuer mich zeigt das, dass diese Vorschlage einfach schon von sich aus zu kompliziert sind. Wenn die Laenge der Spuren nicht in einer Relation versteckt werden, dann braucht man dafuer auch kein extra Hilfswerkzeug.
Die exakte Beschreibung einer Kreuzung mit 7 Strassen mit jeweils 9 Spuren wird zwar immer kompliziert werden, ist zum Glueck ja aber nicht der Normalfall. Wenn in 99% der Faelle ein Konstrukt von einem durchschnittlichen Mapper nicht mehr ohne Hilfsmittel ueberblickt werden kann, dann ist das fuer OSM kein brauchbarer Ansatz.
Gruss
Torsten
Die Welt ist nun einmal kompliziert. Nur weil dein Gehirn ständig vereinfacht und filtert kannst du dich überhaupt auf das wesentliche konzentieren. Das andere Personen andere Dinge wesentlich finden unterscheidet die Menschen. Damit wird das Modell dann aber leider auch kompliziert. Wenn es aber ein Hilfsmittel gibt mit dem man das ganze visuell drastellen kann, so kann man wie bei OSM 3D entweder probieren oder besser gleich noch wysiwyg zusammenklicken. Wer sagt denn das ÖPNV Relationen mit den ganzen Metarelationen einfach sind? Dennoch gibt es eine Gruppe von Mappern die sich damit beschäftigen und das auch auswerten.
Gleiches gilt übrigens für TMC.
Somit belasse ich es bei dem bisherigen Meinungsaustausch zu diversen plugins und proposals, der wohl in diesem Stadium keine Lösung erkennen lässt, und bringe deine berechtigte Frage wieder nach oben:
Also vielleicht nochmal die Probleme zusammenfassen!
Wir wollen gerne Spuren erfassen. Die einen für den ästetischen Aspekt (visuell) die anderen für gezieltes Routing.
Die Praxis bisher jede Straße eine Linie wenn keine bauliche Trennung (Sperrflächen doppelte Linie etc.)
Sie wird durch gute Luftbilder teilweise unterlaufen in dem jede Spur zu einer Linie wird.
Dies ist für alle Seiten unbefriedigend denn:
-
Routinganweisungen werden so gut wie unmöglich
-
Routing wird durch einen riesengroßen Routinggrafen unnötig erschwert (Rechenzeit)
-
Spurwechsel Spurerkennung nach heutigem Stand nicht abbildbar.
-
optisch sieht die Sache auch nicht besser aus. Da mehrer Straßen übereinander gezeichnet werden.
Lösungsversuche?
Straßen als Flächen erfassen. Damit wäre die Optik jedenfalls stark verbessert. Außerdem könnte Fuß- und Radwege sowie Parkstreifen einfach dargestellt werden.
Für das Routing ist das aber keine Lösung. Hier gabs den Vorschlag von Tags am Weg Relationen am Weg und schließlich auch Linie je Richtung (rechts mitte geradeaus) oder gar für jede Spur aber nicht als highway=*
Vielleicht können die einzelnen Verfechter Ihrer Lösung in zwei bis 4 Zeilen nochmal die Vorteile ihres Ansatzes herausstellen.
Auch aus Flächen lässt sich ein Routinggraph errechnen und der muss nicht zwangsweise viel komplexer sein als jetzt. Auch könnte man ja beides (also Linie und Fläche erfassen). Aber beides löst wieder nicht das Spurenproblem beim Routing. Ich befürchte fast, dass das, was wir wollen, mit aktueller Navisoftware nicht machbar ist. Zumindest für Onlinerouter könnten aber Relationen, die die Spuren (sei es nun als Fläche oder Linie) zusammenfassen, helfen.
Ich würd gern für die Beispiele ein Foto einer etwas komplexeren Kreuzung einfügen, was darf denn als Quelle benutzt werden?
EDIT:
Hab grade gesehen, jemand hat ein weiteres Beispiel eingefügt. Vielleicht können die Ersteller der Alternativen dort vervollständigen?
Ich kann halt Gedanken lesen.
Aber es ist klar, dass in diesem Beispiel mein Schema (Alternative B) abschreckend wirkt, da die Werte für lane_matching so lang sind. Da hilft es nichts, dass sie viel genauer sind als die Alternativen und im Ggs. zu diesen ein zuverlässiges Routing (auch für Fußgänger) ermöglichen. Vielleicht sollte man die Routinginfos für Fußgänger in ein anderes Tag auslagern bzw. auf eine gewisse Intelligenz des Routers vertrauen (der z.B. wissen muss, dass man auf einem Gehsteig oder Radweg umkehren kann, und als Normalfall annehmen kann, dass man an einer Ampel von jedem Gehsteig auf jeden anderen wechseln kann).
Ich denke, dass das die eigentlich entscheidende Frage ist: Was will man alles in einem Spurschema erfassen?
Ich denke (z.Z.), dass ein Schema um so besser ist, je mehr Informationen man damit kartieren kann. Das sieht natuerlich weniger uebersichtlich aus als ein Schema, dass nur ein Bruchteil der Informationen darstellen kann.
Insofern kann man die verschiedene Vorschlaege eigentlich nur sehr schwer vergleichen. Statt einfach ein Bild einer Kreuzung als Vorlage zu nehmen, bei dem jeder Vorschlag was anderes mapped, muesste man vielleicht besser klar definierte Einzelfaelle zur Unterscheidung nehmen, wo der Rest gezielt ausgeblendet wird.
Gruss
Torsten
Generell ist es so, das man die Realität doch das getrennte Einreichnen eines Mapfeatures am besten beschreiben kann. Weil irgendwann kommt dann früher oder später eine ungewöhnliche Abbiegespur und das war es dann mit grobschlächtigen Tags wie “links” und “halb rechts”, etc. Eben genau aus diesem Grund gibt es ja auch die “ein Objekt - ein Mapfeature”-Regel. Das gilt übrigens genauso für die straßenbegleitenden Fuß-/Radwege, usw. Damit sollte dann klar sein, das wenn man Abbiegespuren haben möchte, diese dann auch getrennte Objekte sein sollten.
Jetzt kann man darüber diskutieren, ob man die (Abbbiege)spuren nun als Linienbündel oder als Flächen in OSM abbildet. Wenn man aber bedenkt, das man die Vereinfachung von Flächen auf Linen bisher ja nur gemacht hat, weil die Genauigkeit des GPS/Luftbildes zum genauen Einzeichnen als Fläche nicht ausreicht, sollte man die Spuren auf Grund der beseren Realitätswiedergabe aus Flächen einzeichen, weil offenbar reicht ja die genauigkeit jetzt aus, sonst würde man sich doch nicht überhaupt mit dem Tagging der Spuren abgeben. oder man zeichnet doch nur Linienbündel, weil man zwar grob die Spuren, aber nicht genau deren Grenzen erkennen kann. Das wäre dann der alte Kompromiß, dismal eben nur eine Ebene (Spur statt Straßenabstraktion) tiefer. Wenn man die als Flächen an eine linienförmige Straße hängt, dann bräuchte man zusätzlich noch eine Relation die den Anschluß and die linienförmige Straße beschreibt.
Das ist doch alles nur eine Frage der Datenvorverarbeitung für das Routingprogramm. Wenn die Spuren alle mit von der Straße (highway=*) unterscheidbaren Tags versehen sind, kann man die in der Vorverarbietung doch leicht so zurechtfiltern, das von z.B. mehr als einer Abgiegespuren in die gleiche Richtung einfach nur noch eine Verbindung für den Routingraphen übrig behalten wird, womit sich das Komplexitätsproblem dann mehrheitlich in Luft auflösen dürfte.
Hallo allerseits,
hurdygurdyman hat mich auf die hier tobende Diskussion aufmerksam gemacht und gefragt, ob ich meine (hoffentlich vielen und tiefgehenden :P) Überlegungen beisteuern möchte, die ich während der Entwicklung der turn-lanes-Proposal angestellt habe. Wie ich ihm bereits mitgeteilt habe, kann ich als einfacher Informatiker mit begrenztem Einblick ins Verkehrsingenieurswesen keine neuen Erkenntnisse beisteuern. Was ich beisteuern kann sind ein paar banale Feststellungen.
Bei OpenStreetMap handelt es sich um eine kollaborative Anstrengung Geodaten unserer Welt zu erfassen und der Allgemeinheit zur Verfügung zu stellen. Die Hoffnung ist, dass alle durch das gegenseitiges Geben und Nehmen profitieren. Auch wenn Vollständigkeit, Richtigkeit und Präzision das ultimative Ziel sind, so sind diese noch einen weiten Weg entfernt. Heute ist das Ziel die Diskrepanz zwischen den erfassten Daten und der Wirklichkeit soweit und schnell es geht zu minimieren. Um 1990 geisterte ein Paper mit dem Titel “Worse is Better” durch die Software-Engineering Welt. Es verbreitete die Idee, dass es besser ist jetzt etwas suboptimales zu haben, als auf ewig dem Heiligen Gral hinterherzujagen.
In der Einleitung meines Vorschlags schreibe ich “[a]t some point lanes will (hopefully) [be] mapped as individual ways or areas […]”. Einen Weg oder gar eine Fläche pro Spur zu haben ist der Heilige Gral, ein fantastischer Traum. Meiner Einschätzung nach sollte die erste Priorität sein den Detailgrad auf Teufel komm raus zu steigern. Wenn es später strikt mächtigere Modelle gibt um Spuren zu erfassen, so kann man Daten aus dem Modell von heute in das neue übertragen. Eines Tages wird es sich dabei vielleicht auch um eine Fläche pro Fahrstreifen handeln.
Ein paar Dinge zu meinem Proposal und dem zugehörigen Plugin: (Mein) Ziel war es, das Einpflegen der Spurinformationen so einfach wie möglich zu gestalten. In diesen Aspekt ist wirklich viel Arbeit geflossen. Dafür wurde aber ein wesentlicher Kompromiss gemacht, der hier zurecht angeprangert wurde: Längenangaben in Tags.
Da man die Länge einer Spur relativ bequem durch eine Art Drag-n-Drop manipulieren kann, ist eine andere Lösung nicht ohne weiteres möglich. Theoretisch könnte man jedes mal einen Knoten erzeugen um den Anfang der Spur zu beschreiben, aber man könnte den alten nicht ohne Weiteres löschen.
Ebenfalls zurecht kritisiert wurde die Tatsache, dass nur Abbiegespuren abgebildet werden können. Natürlich war das genau das angepeilte Ziel, aber hier wird ja nach einem mächtigeren Modell gesucht.
Ich erkenne die genannten Schwächen meines Vorschlags im Rahmen dieser Diskussion an. Nichtsdestotrotz finde ich, dass es zusammen mit dem bestehenden lanes-Tag eine fürs erste akzeptable Lösung ist. Nichtzuletzt weil das Erfassen der Daten durch das Plugin so einfach ist. Der Quellcode des Plugins ist Open-Source unter der GPL, wobei ich ihn bei guter Begründung auch gerne unter einer liberaleren Lizenz weitergeben würde. Ich für meinen Teil würde mich freuen, wenn jemand ein benutzerfreundliches Plugin für ein komplexeres Fahrstreifenmodell schreiben würde.
Abschließend möchte ich unterstreichen, dass es sich bei obigen Feststellungen um meine bescheidene Meinung handelt. Die hier zu fällende Entscheidung sollte von Leuten getroffen werden, die tiefer mit dem OSM-Projekt verstrickt sind als ich. In diesem Sinne werde ich mich aus der weiteren Disussion heraushalten, sofern es keine rein technischen Fragen gibt.
Das was du vor hast, ist in etwa so, als wenn du deinen Heimatort auf Grund der “Einfachheit” als Punkt mappst und dann ein Plugin schreibts, um passende Tags für die Repräsentation der Häuser, Straßen, etc. hinzuzufügen.
Einfach ist ein Modell, dann, wenn man es, egal mit welchem Editor, als Mensch nachvollziehen und bearbeiten kann. OSM setzt ja auf die manuelle menschliche Pflege von XML-Tags, wenn man nicht wollen würde, das menschen die Berabeiten, dürften wir nur noch irgendwelche Frontends zur Bearbeitung der Geodaten benutzen.
Was ist denn das Problem dabei, wenigstens die Spuren als Linien zu mappen? Weil wenn man die dieses Detail der Realität drin haben möchte, kann man es ja auch gleich richtig machen. Spätestens bei der Datenverarbeitung muß man ja sonst eh künstlich die Spuren erzeugen, wobei dann solche Krämpfe dabei herauskommen wie z.B. die --make-cycleways-Option von mkgmap. Da gibts dann schöne gerade Linien neben der Straße, die mit der Realität meist genau Nichts zu tun haben.
Äh, du hast dir das Plugin und die Videos einmal angeschaut? Den Vergleich versteh ich jetzt nicht…
[IRONIE]Ich hab meinen Mechaniker gefragt, ob man nicht einen Motor bauen könnte, der nur aus einem Teil besteht, damit ich ohne Probleme daran rumschrauben kann…[/IRONIE]
Komplizierte Sachverhalte lassen sich nun einmal nicht einfach darstellen.
Wegen dem Routinggraphen vielleicht?!
Hauptsache es sieht schön aus… Aber Navigation kannst du dann auch vergessen… Ziel verfehlt… Meine Meinung…
Wieso, das hast du doch halbwegs verstanden, siehe deine Aussage:
Halbwegs deshalb, weil ein Modell eine begrenzte und überschaubare Menge an Varianten ohne Probleme abbilden kann. Oder überschaust du alle Varianten die in der Realität vorkommen, um ein für alle passendes Modell bauen zu können? Außerdem sammeln wie geographische Objekte in einer Datenbank und da läßt sich ein linienförmiges Objekt mit einem bestimmten Verlauf und einer bestimmten Länge nun mal am besten als Weg erfassen.
Extra für dich wiederhole ich hier noch mal meine Argumentation von oben:
Fazit: Man muß es auch mit z.B. Potlatch, Merkaartor, usw. bearbeiten können.
Was ist an einer Linie mit passenden Tags denn so kompliziert? Das stellt doch eine wie auch immer geartete Spur ausreichend genau da!
Ich habe das obige Posting zum Thema Routinggraph gelesen.
Ich habe die Argumentation versucht zu verstehen.
Wieso soll man da die Navigation vergessen können? Meine Argumente hab ich ja schon in den Vorpostings angeführt.
Die Antwort auf deine Frage steht auf den vorangehenden 7 Seiten dieser Diskussion. Da hat man wenig Lust, sich nochmal mit deinen Argumenten auseinanderzusetzen.
Bzgl. der geforderten Einfachheit stimme ich allerdings mit dir ueberein. Nur weil es halt sehr komplizierte Faelle gibt, bei denen zwangslaeufig auch das Mapping kompliziert wird, heisst das nicht, dass das Mapping von einfachen Faellen auch kompliziert sein muss.
Gruss
Torsten
Ja, ich geb ja zu, ich hab die vorherigen Seiten nur mal schnell durchgesehen und leider habe ich beim Überfliegen der so mal geschätzt 90% Diskussion über wenig taugliche Vorschläge in Form von Zusatztags, übersehen, das es auch schon min. einen zum Einzelmapping gab. Das ist definitiv der bessere Ansatz für das Problem, weil wenn man es sich eine Weile überlegt, ist doch schon alles da:
highway=*
lanes=*
oneway=yes
maxspeed=*
damit kann man fast alles taggen. Für die Spur mit Doppelnutzung und Sperrlinien habe ich dann noch:
barrier=other_direction oder barrier=contraflow (abstrakte Barriere in Form des Gegenverkehrs in der Mitte der doppelt genutzten Spur)
barrier=street_marking (Barriere in Form von Markierungen, kurz vor dem Ende der Spur)
Naturlich kann man die Spuren die mit Sperrlinien enden in die entsprechenden Richtungen optional auch ganz weglassen.
Das war es erst mal was ich gerade so schnell gesehen habe, ich seh das noch mal genau durch ob noch fehlen sollte.
Ich denke, wir müssen hier unterscheiden nach
- Verwendbarkeit der Daten für Renderer als geografische Information
- Auswertbarkeit zum (vorausschauenden) Routing
An diesem Spagat scheitern wohl die meisten Ansätze, zumal auch noch der Anspruch besteht, in dem Schema das gesamte Linienbündel incl. bus, tram, footway und cycleway sowie aller möglichen Trennungen dazwischen erschlagen zu wollen. Und dann soll das alles auch noch für den Mapper transparent und ohne Tools erfassbar sein
Warum konzentrieren wir uns nicht auf das Thema dieses threads “Routing und Spurmapping”, welches in der Masse der Fälle nur Straßen (und selten auch Radwege) betrifft. Mir ist eine Lösung für 80-95 % der Fälle lieber als für 100 % keine Lösung.
P.S. In diesem Sinne möchte ich auch benshu danken, dass er sich hier gemeldet hat