Dieses Anwesen: http://www.openstreetmap.org/browse/node/310819829
besteht im Augenblick aus einem Punkt.
Zum großen Teil ist es von einer Mauer umgeben.
Wie verfahre ich, wenn ich dem Anwesen eine Fläche zuordnen möchte? Muss ich die gesamte Mauer nachzeichnen? Oder gibt es die Möglichkeit, Teile der Mauer zu nutzen?
Beispielsweise so: ich bastele mir eine Relation mit allen benötigten Teilen, drücke den Knopf “wandele Relation in einen Weg”, und schreibe die fehlenden Tags dazu (area=yes, name =Kartause Marienau, wikipedia=de:Kartause Marienau, weitere?). Gibt es diesen Knopf?
Wieder MP statt landuse. Wenn dort ein “neuer” aus guten Willen Acker oder Wiese einfügen will, bricht wieder das MP zum Fehler.
Laut Luftbild bietet sich doch an:
Das MP forest beidseitig an der Straße und dann um das Kloster mit Wiese und Acker zu führen und landuse für Acker, Wiese, Klostergelände zu nutzen. Damit entfällt das inner und der forest kann ein natural als Fläche werden.
Etwas weiter westlich könnte das MP forest sogar entlang der Straße aufgelöst und zu natural als zwei Flächen gewandelt werden.
Leider wird auch uneinheitlich einmal als landuse und dann wieder als MP gemappt.
Danke!
Aber weiß der Renderer, dass es sich um eine Fläche handelt? Sollte nicht das Attribut “area=yes” hinzugefügt werden?
Nochmals zu meiner Eingangsfrage: wäre das Ergebnis (nicht der Weg dorthin) nicht einfacher, wenn der Multipolygon durch eine einfache geschlossene Linie ersetzt würde?
Ja natürlich. Aber es gibt hier auch eine Gruppe Mapper, die lieber alles mögliche zu Relationen verarbeiten. Das ist somit letztendlich eine Geschmacksfrage, die jeder für sich selbst entscheiden muss. Relationen, die nur aus outer bestehen, sind meiner Meinung nach unnötig kompliziert - wenn Inseln im Umring liegen aber unvermeidlich.
Wenn der Multipolygon korrekte Rollen hat und der Graph fehlerfrei ist, ist die Extraktion der einzelnen Ringe trivial.
Die topologische Prüfung, wie die Ringe geschachtelt sind und ob sich die Ringe schneiden, ist etwas kniffliger. Wenn Du aber von Multipolygonen ohne “inner” ausgehst und die Korrektheit der Ringe einfach annimmst (das machst Du bei Ways ja auch), entfällt diese Prüfung.
Bei den wenigen Millionen Multis, die wir zur Zeit haben, wäre auch die Wandlung aller Multis in eine kanonische Form (Ring nach Ring nach Ring, zuerst die outer, dann die inner) eine Kleinigkeit. Die könnten dann noch einfacher ausgewertet werden. Übrig blieben maximal 1000…2000 Multis, die händisch gefixt werden müssten.
Lästig ist, dass die Datenbank die Integrität der Multis nicht durchsetzt.
Und beim jetzigen Datenbankmodell auch nur mit einem unschön komplexen Trigger durchsetzen könnte. Dann dürften aber die Editoren nur noch korrekte Multis hochladen – um das aber zu prüfen, brauchen sie alle enthaltenen Ways – das will man nicht wirklich, wenn man zufällig die Grenzrelation für Europa angefasst hat. Es sei denn, man erlaubt inkrementelle Updates auf Objekten. Man öffnete da eine Büchse Würmer :-/
Vielleicht kommt ja mal in API N der neue Objekttyp “Area”, der die "way[area=yes]” und die “relation[type=multipolygon]” vereinheitlicht.
M.E. sind Relationen durchaus sinnvoll, nur warum muss ein MP=forest aus ways (Straßenstücke) gebildet werden? Die Straße geht doch über die Wiese oder durch den Wald oder zwischen der Wiese und dem Waldrand.
Eine Wiese, ein See, ein Wald(stück), ein Forsthaus werden als Fläche erfasst und können als Relation (Forstrevier …) zusammengefasst werden. Da kann dann noch der Jagdanstand, die Hütte, der Waldweg(auch als area=yes) integriert werden.
(Vielleicht findet sich auch eine Lösung für die *Insel im See *…)
