Markus schrieb: > Für mich als Laie sieht das ganz einfach aus: > die kleinere Fläche /überdeckt/ die Grössere. > […] > Dadurch könnte man sich doch die ganzen Konstrukte mit inner/outer und > +1/-1 ersparen? Das würde die OSM-Struktur für alle einfacher machen: > für Datensammler, für Renderer, für Anwendungsprogrammierer?
Es gibt aber gerade bei landuse oft den Fall, dass eine kleinere Fläche das landuse nicht ersetzt, sondern ergänzt – ein Parkplatz ist kein Loch im Gewerbegebiet, sondern Teil davon. Gilt auch für viele andere Dinge, nicht zuletzt auch für Gebäude. Natürlich gibt es andererseits aber auch echte Löcher in landuses, so dass man ohne Hilfe des menschlichen Bearbeiters wohl kaum eine zuverlässige Entscheidung treffen kann. Auch ohne diese Erwägung könnte man sich die beiden genannten Konstrukte wohl sich nicht ersparen. Layer braucht man immer noch für (zumindest manche) Brückenkonstruktionen o.ä. – dafür sind sie nämlich eigentlich da, nicht für Landuse-Render-Hacks –, Multipolygon zumindest für den Fall, dass man ein Loch in einem Objekt hat, das selbst keine Information trägt. Für Renderer- und Anwendungsprogrammierer bedeutet das: Die Regeln müssen trotzdem implementiert werden, nur eben die zusätzliche Einschlussprüfung auch noch. 3 Konstrukte statt 2 klingt nicht einfacher. Ich halte solche generellen „Liegt Polygon A in Polygon B“-Tests über alle potentiell in Frage kommenden Polygone auch (ohne es bisher programmiert zu haben) für weit aufwändiger als eine Relation, bei der ich die Teilnehmer bereits kenne, und daher weit weniger Objekte prüfen muss. Datensammler, die mit den komplexeren Fällen in Berührung kommen, müssen ebenfalls alle drei Techniken kennen, sie sparen sich natürlich ein wenig Tipp- und Klickarbeit bei den einfachen Fällen. Diejenigen, die wirklich profitieren könnten, sind Datensammler, die nur einfachere Informationen einbauen (also nicht mit komplexeren Fällen in Berührung kommen) und sich auch nicht mit der Struktur der von ihnen erzeugten Daten auseinandersetzen wollen. So etwas wäre aber m.E. wegen der zusätzlichen Lasten für Anwendungen sowieso nicht im Datenmodell richtig aufgehoben, sondern in den Editoren. Die können gerne die Fähigkeit haben, etwa automatisch Mulipolygon-Relationen zu erzeugen, wenn du oder jemand anderes das ergonomisch hinbekommst. Das verschiebt den Aufwand von Anwendungen auf Editoren, was angesichts dessen wünschenswert ist, dass hoffentlich weit mehr Anwendungen als Editoren geschrieben werden – ansonsten machen wir irgendwas falsch. ;-) Tordanik _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
