Bei der (wieder einmal) intensiven Beschäftigung mit Multipolygonen sind mir - abseits der Geometrie - einige fragwürdige Verwendungen aufgefallen. Dazu ein paar hoffentlich hilfreiche Fragen und Beispiele (aus Österreich).
Grundsätzlich: eine Multipolygon-Relation [1] (MPR) statt eines Polygons (geschlossene Linie) braucht es a) wenn eine Fläche ein Loch hat b) wenn die Grenze der Fläche aus mehr als einer Linie besteht (im Weiteren nicht von Bedeutung) Tags an der Relation beziehen sich auf diese, Tags an den Innen/Außenlinien gelten unabhängig davon für diese Linien und können zusätzliche Flächen begründen [2]. 1. Macht jedes Objekt für sich allein betrachtet (aus der Datenbank abgefragt) Sinn? [2] leisure=park umfasst den ganzen Park inklusive Vegetation [3] und Einrichtungen. Wiese, Wald, Wasserflächen, Sportflächen (sofern allgemein zugänglich), Spielplätze, Toiletten, ev. auch Parkcafe etc. gehören dazu -> diese daher NICHT ausschneiden! (sonst besteht das Park-Objekt hauptsächlich aus Löchern). Objekte die sich gegenseitig ausschließen (See im Wald, Insel im Fluss, Fabrikgelände im Wohngebiet) -> MPR, wenn eines das andere umschließt. 2. Welches Flächen-Tag wohin - an das MPR, den Umriss oder ein separates Polygon (-> Wiki!)? amenity=school bezeichnet das Schulgelände [4], inkl. Gebäuden, Sportplatz etc. -> i.A. separates Polygon. Besteht die Schule nur aus einem Gebäude, und dieses hat einen Innenhof (Gebäude ist MPR): amenity am outer Ring (Umriss) -> Hof ist inkludiert, amenity an der Relation -> Hof ist nicht Teil des Schulgeländes. 3. Handelt es sich wirklich um die Fläche eines Objekts, oder die Gruppierung mehrerer Objekte? Flächen sollten nicht in einer MPR zusammengefasst werden, weil sie zufällig die gleichen Tags haben [5]: Mapper A erstellt eine MPR mit 10 Waldstücken, Mapper B eine mit 10 Wiesen, Mapper C verschränkt die beiden Relationen mit inner/outer-Beziehungen (das gibt's wirklich!). Besser: individuell als Polygone mappen, dann MPRs bilden wo nötig. Auf einem Gelände (z.B. Bauernhof, Wohnblock, Spital) stehen mehrere Gebäude. Diese werden als eine MPR mit outer-Ringen dargestellt (s.a. Punkt 1). Die Tags an der MPR gelten für alle Gebäude, somit müssen individuelle Tags (Adresse, Gebäudetyp,...) an die outer-Ringe, das MPR dient nur noch zur Gruppierung. Viel klarer: jedes Gebäude separat modellieren und auf eine gemeinsame Fläche (amenity, landuse) stellen (allenfalls noch mit place=*, name=* o.ä.). Die Flächen einer Streusiedlung werden in einer MPR (landuse=*, name=*) zusammengefasst. Nicht nur, dass in Mapnik jede Fläche den MPR-Namen trägt (vielleicht ändert sich das ja mal), müssen unterschiedliche landuses auf die outer-Ringe, wo sie im Widerspruch zur MPR stehen. Besser: jede Fläche separat mappen und anders zusammenfassen (Adressen; gemeinsames is_in=*; Polygon mit place=*, name=*). Übrigens: formal stehen die MPRs in Österreich gerade recht gut da, bis auf die in OSMI [6] gezeigten Probleme und Aufräumarbeiten nach der "old-style multipolygon"-Beseitigung [7]. Davon abgesehen sind die größten Themen aus meiner Sicht das Aufspalten von Monster-Relationen, Überlappungen (unvollständige/fehlende MPRs) und die Verfeinerung des Taggings (s.o.). Hoffentlich ist etwas für Euch dabei, bin schon gespannt auf Eure Kommentare, LG Wolfgang [1] https://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon [2] https://github.com/osmlab/fixing-polygons-in-osm/issues/26 (3. Eintrag von Jochen Topf) [3] https://wiki.openstreetmap.org/wiki/DE:Tag:leisure%3Dpark [4] https://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dschool [5] Dazu gab es kürzlich einen Kommentar von Frederik Ramm, den ich gerade nicht finde. [6] http://tools.geofabrik.de/osmi/?view=areas&lon=14.36719&lat=47.69424&zoom=8&overlays=duplicate_node,single_node_in_way,duplicate_segment,way_in_multiple_rings,intersection,intersecting_segments,ring_not_closed,role_should_be_inner,role_should_be_outer,inner_with_same_tags [7] http://area.jochentopf.com/old-style-josm.html _______________________________________________ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
