Danke erstmal für dein umfangreiches Feedback. Ich wage inzwischen zu hoffen, dass diese Linienbündel-Frage irgendwann doch mal befriedigend gelöst werden kann.
Sven Anders schrieb: > Am Dienstag, 30. Dezember 2008 12:43 schrieb Tobias Knerr: >> http://wiki.openstreetmap.org/wiki/Proposed_features/lane_and_lane_group > > Den Ansatz finde ich SEHR GUT. Aber ich denke wir sollten es irgendwie > schaffen, das wir nur eine Relation brauchen, das andere verwirrt nur. Bei der Frage "nur eine Relation" sind wir leider schon unterschiedlicher Meinung, was wohl auch daran liegt, dass für dich -- wie aus deinem Beispiel hervorgeht -- bei einer "voll erfassten" Straße sämtliche Spuren als eigener Way vorliegen. In meinen Augen dürften viele Straßen keine signifikant unterschiedlich verlaufenden Spuren erfordern. Sehr wohl sind aber für "Vollerfassung" Dinge wie unterschiedliche Oberflächenbeschaffenheit oder abweichende Geschwindigkeitsbeschränkungen relevant. Die würden jedoch bei Verzicht auf weitere Relationen zur Verwendung von Ways zwingen, weil weitere Tags sonst nicht anzubringen wären -- mit allen Nachteilen wie Problemen beim Verschieben u.ä. und einer überfüllteren Editor-Standardansicht. Auch finde ich ehrlich gesagt deinen Ansatz hier nicht wirklich leichter durchschaubar: > Relation 100 > type=lane_group > lane:+1=cycleway > lane:+2=footway > lane:-1=cycleway > lane:-2=footway > Relation 100 > type=lane_group > [evtl:Optional] > lane:+1=cycleway > lane:+2=footway > lane:-1=cycleway > lane:-2=footway > Members: > highway -> Way1 > highway_oposite -> Way2 > +1 ->Way3 > +2 ->Way5 > -1 -> Way4 > -2 -> Way6 Man kann bei dir eine Lane also sowohl als Way als auch als Tag einer Relation darstellen. Bei Tag-Darstellung nimmt man nur den lane-Value mit einem anderen Key, weiteres Tagging ist nicht möglich. Die Keys und Rollen sind dabei leicht unterschiedlich und zwingen dazu, die Numerierung (die ich eigentlich ohnehin eher unschön und umständlich finde) auch dann noch zu behalten, wenn man dank geordneter Relationen darauf verzichten hätte können -- denn sonst geht die Ordnung zwischen Membern und Tags verloren. Bei einer Modellierung per Relation ist die Sache doch recht klar: Eine Spur entspricht genau einem "primitiven" OSM-Objekt: Way oder Relation. Diese lassen sich in gleicher Weise mit Tags versehen und in gleicher Weise in die zusammenfassende Relation einbinden. Darüber hinaus halte ich die Auswertung in Programmen, gerade Editoren, -- zumindest aus der beschränkten Erfahrung mit meinem Prototypen fürs Lane-Plugin heraus -- für leichter, wenn man sich nur auf Member statt auf alternativ Member oder Tags beschränkt. Ways und Relationen stimmen hier in allen relevanten Eigenschaften (eigene ID, Tags) überein. Die Programmierfreundlichkeit sollte zwar nicht primäres Kriterium sein, ist aber nicht zu vernachlässigen, zumal sie auch darüber entscheidet, wie leicht der für umfangreichere Erfassung m.E. unabhängig vom Schema nötige Editoren-Komfort eingebaut werden wird. > Ein weiteres Problem sehe ich zur Zeit in größeren Straßen wie z.B. die > Amsinckstraße: > > http://www.informationfreeway.org/?lat=53.544206425744335&lon=10.019533225294216&zoom=17&layers=B0000F000F > > bzw. > > http://maps.google.de/?ie=UTF8&ll=53.54412,10.020009&spn=0.000527,0.001196&t=k&z=20 > > Versuch das mal abzubilden! Das Problem ist das wir ja schon zwei > highway=prinary (für jede Richtung) haben. Zwei-Highway-Straßen sind in der Tat ein gewisses Problem, und so etwas > highway -> Way1 > highway_oposite -> Way2 ist durchaus eine mögliche Lösung. Ich hätte der Einfachheit halber (Sonderfälle...) allerdings bislang daran gedacht, jede Lane nur einem der Highways zuzuordnen -- bei deinem Beispiel erscheint etwa der Grünstreifen in der Mitte als plausible Trennstelle. Geht der auswertenden Software damit Information verloren, an die ich bislang nicht gedacht habe? > == Was würde das für Renderer und Tools bedeuten? == > > * Beim drehen einer Straße müsste evtl. die Relation angepasst werden, aber > warum sollte jemand die Straßen drehen wollen.... Das ist ein wichtiger Punkt, an den ich bislang nicht gedacht habe -- solche Spuren gehören in der Tat zu den richtungsabhängigen Informationen. Tobias "Tordanik" Knerr _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de