Am 23.01.2012 03:50, schrieb Stephan Wolff: > >> * Wie gruppiert man die zusammengehörigen Ways? > > Warum ist das ein Problem? Welche Anwendung funktioniert nicht? Auch > bislang sind zwei Fahrbahnen einer Straße nicht gruppiert.
Ein paar Beispielanwendungen, die vielleicht nicht unmöglich, aber nur umständlich umsetzbar sind: * Ansage des Zielstraßennamens durch eine Navigation. (Bisher werden aus diesem Grund ja alle Tags, die für die Gesamtstraße gelten, an beide Fahrbahnen kopiert.) * Lückenloses Rendering der Straßenfläche. Eine Linie fester Breite für jede Spur zu zeichnen, zwischen denen dann wegen der mangelnden Präzision beim Einzeichnen zwangsläufig Lücken klaffen oder die sich gegenseitig überlappen, entspricht nicht meiner Vorstellung einer ansprechenden Darstellung. >> * Wie editiert man es mit einfacher gestrickten Editoren? > > Gerade eine Lösung ohne Relationen und ohne Tags mit komplizierter > Syntax sollte doch jeder Editor beherrschen. Jeder sicher nicht. Schon mal einen mobilen Editor gesehen? Eine Eingabemaske für die Tags mit "komplizierter" Syntax ist leicht umzusetzen. Filigrane Way-Geflechte wird man damit nicht editieren können. Ich würde das nicht mal mit Potlatch schaffen (bin aber auch kein erfahrener Potlatch-User). >> * Wie sehen die Algorithmen auf Anwendungsseite aus, die daraus z.B. >> eine vorzeigbare grafische Darstellung produzieren? > > Das ist keine Frage des Datenmodells und hängt sehr von Zweck und den > Möglichkeiten des Renderers ab. Das ist sehr wohl eine Frage des Datenmodells. Solange ich für ein Way-Segment eine geordnete Liste der Spuren habe oder ermitteln kann, ist es machbar, die Spuren mit ihren Spurtrennern (durchgezogene oder gestrichelte Linien etc.) und überlappungsfrei zu visualisieren. Einfach deshalb, weil man die Position der Grenzen zwischen zwei Spuren dann exakt berechnen kann. Ja, es hängt *auch* von den Möglichkeiten des Renderers ab, und Mapnik käme mit Komma-Tags wahrscheinlich gar nicht direkt klar. Das ist aber nur eine behebbare Eigenschaft eines konkreten Renderers. Der Unterschied zu Einzelways ist, dass ich bei denen auch in der Theorie keine Lösung wüsste, die mich zufrieden stellt. >> Und bei [2] beispielhaft der Nord->Süd-Way: >> lanes:layout = right , straight , straight , left > > Ist damit ein besseres Renderergebnis möglich? M.E. ja. Man kennt oder schätzt die Breite der Spuren und kann die Ansatzpunkte für die Grenzen zwischen Spuren über eine Verschiebung um diesen Wert entlang der Senkrechten auf dem Straßenway berechnen. Ich gebe zu, dass es eine komplexere Aufgabe ist, bei dieser Darstellung den Übergang zwischen zwei oder mehr Ways an einem gemeinsamen Knoten angemessen darzustellen. > Wenn sich ein Mapper in die schwierige Syntax eingearbeitet hat, sind > tag-basierende Lösungen zweifellos schneller zu erstellen. "Den Wert für jede Spur von links nach rechts durch Kommas getrennt aufschreiben. In der Straßenmitte statt Komma ein | nehmen." Findest du das ernsthaft eine schwierige Syntax? > Die Einzelspurlösung ist durch nachfolgende Mapper m.E. viel einfacher > mit dem Luftbild abzugleichen. Sobald der Editor eine Visualisierung der tag-basierten Lösung anbietet, ist auch dort ein optischer Abgleich mit dem Luftbild möglich - ohne die Nachteile der Einzelspurlösung in Kauf nehmen zu müssen. Ein Editor-Tool, das die Nachteile der Einzelspurlösung in ähnlicher Weise abmildern könnte, fällt mir hingegen nicht ein. > Bei komplexen Kreuzungen wie [2] hat die tag-basierende Lösungen bis zu > 30m Abweichung vom realen Verlauf der Abbiegespur. > Das Aufwand-Nutzen-Verhältnis lässt sich nicht pauschal bewerten. Wenn du den realen Verlauf tatsächlich benötigst, ist die tag-basierende Lösung natürlich weniger nützlich. Es hängt letztlich eben von den Ansprüchen ab, die man an die Lösung stellt. Gruß, Tobias _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
