nein, nichts. Bin nicht so der Source Tagger. Da ist nichts ausser landuse=farmland, meadow und vineyard sowie natural=scrub. Er meckert mit “Style for inner way equals multipolygon” nur wegen der inneren Landuse-Flächen (meadow und vineyard), nicht wegen natural=scrub. Ich verstehe das nicht, genau um landuse nicht zu stappeln, nutze ich doch ein MP
Edit: Achja, ist auch nichts geschacheltet wie farmland in vineyard in farmland.
Scheint daran zu liegen, dass diese drei landuse-Arten in JOSM den selben Stil verwenden (nämlich ein helles Grün). Insofern kann man’s wohl ignorieren (und bei JOSM als Bug eintragen).
Stimmt. Das eine farmyard, was ich ganz vergessen hatte und das anders ausgemalt wird, meckert er nicht an. Hat jemand Erfahrung darin, einen Bug bei JOSM zu eröffnen und mag das tun? Sonst lese ich mich da morgen mal ein.
mehr schlecht als recht habe ich mal nen (meinen ersten) JOSM Bug da eingetragen.
Das Problem ist, dass sich die Ringe - egal ob inner oder outer nicht berühren dürfen bzw. kein gemeinsames Teil haben dürfen. wurde sehr intensiv auf der ml diskussiert.
Die formal “richtige” Lösung ist eigentlich ganz einfach, wenn man das erstmal gefressen hat.
schau dir diese Lichtung im Wald mal an: http://www.openstreetmap.org/?lat=50.120669&lon=8.079261&zoom=18&layers=M
Ein Loch, gefüllt mit Wiese und Scrub. Wiese und Scrub sind separate MPs, die beide die SELBE Trennungslinie benutzen. Und der inner-ring vom Wald wird einfach aus den Rändern von Wiese und Scrub zusammengesetzt.
Multipolygon bedeutet wortwörtlich: ein Polygon, dass aus mehrenen ways besteht. mehr nicht.
Am besten mal aufmalen und drüber schlafen 
Gruss
Walter
grad noch nen fehler korrigiert: landuse=scrub → natural=scrub
gugsdu wiki:
http://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon#Sich_ber.C3.BChrende_innere_Ringe
Danach wär es doch auch in Wambachers Beispiel einfacher, den inner ohne tag als Loch (somit nix) zu lassen. In das Loch werden dann die scrub und meadow als neue Fläche (auch über vorhandene Knoten eingezeichnet ohne Bezug zu dem MP. Somit ist das nix-Loch mit etwas gefüllt, aber touching inner usw. gibt es nicht.
Und schon wäre ein MP vereinfacht bzw. vermieden 
P.S. für SunCobalt:
Ich lerne 
Edit: http://de.wikipedia.org/wiki/KISS-Prinzip
P.S. für Wambacher:
nach simple features definiert man ein MP leider anders. MP’s in OSM sind danach i.d.R. “nur” Polygone. Aber unsere Definitionen 
Hi Thomas,
packst Du den link hier noch rein (einfach weil ich bequem bin)
Danke im Voraus
Christoph
P.S. Das der JOSM Validator die Fehlermeldung vom Style und nicht vom Tag abhängig macht finde ich “interessant”
Genauso würde ich das auch machen, erscheint mir wesentlich logischer und einfacher als das Vorgehen in dem Beispiel von wambacher
Das sollte ja mein “Nach Bedarf” ausdrücken: Ob und wie man das Loch füllt, bleibt jedem überlassen - ja nach Komplexität und Tageslaune.
Aber spätestens dann, wenn das “gefüllte Loch” ebenfalls Löcher hat, sollte man ein neues MP aufbauen.
Ich hab das bei meiner Waldlichtung mal voll durchgezogen, damit -auch mir- die Technik klar wird.
Gruss
Walter
Touching inner Rings sind eine Warnung, die für Tools gedacht sind, die die OSM Daten auswerten.
Touching inner rings ist KEIN Fehler.
Programmieren können mit anhand der Warnung ihre Software besser checken.
so hatte ich
http://forum.openstreetmap.org/viewtopic.php?id=12089
verstanden.
Die im forum kursierenden Beispiele (das Wambacher Beispiel), touching inner rings zu vermeiden, finde ich vom Abbildevorgang her cool. Zuende gedacht gibt es keine überlappenden Wege, alle Landuses sind Relationen, die leere oder vorhandene Linien zusammenstellen, und mit inner und outer bewerten. Herrlich abstrahiert, damit ideal für uns Kartenzeichner (Kartenzeichnen ist nix anderes als Abstraktion).
Nur: bei den jetzigen Editoren (OK ich kenne nur JOSM), halte ich es für ungeschickt so zu verfahren. Die Abbildung “Ich habe einen Wald uns schneide eine Wiese und einen See raus (nehme touching inner rings in kauf)” ist viel nachvollziehbarer und einfacher zu editieren. Ungeschickt deshalb, weil wir so ein grossen Teil unserer Mapper “abhängen”.
Bei meiner immer grösser werdenden Aktion self intersecting osmi Fehlermeldungen zu bereinigen, bin ich auf Mapper gestossen, die kannten Multipolygone noch gar nicht, und waren froh, das ich ihnen erklärt habe, wie man Löcher in Flächen schneidet. Ok der Typ hätte ins Wiki schauen sollen. Hat er aber nicht, aber Daten hat er erfasst.
Wenn die Editoren den Mappern die Arbeit und das Grundverständnis abnehmen, und im Hintergrund so speichern, ist das ein gutes Datenmodell (müsste man sich nur noch über die Auswertbarkeit streiten). Wenn wir das allen Mappern “beibringen” wollen, ist es eben schwierig.
In der Theorie ist alles schön und einfach, aber es geht auch so:
http://www.openstreetmap.org/?relation=1447770
oder http://tools.geofabrik.de/osmi/debug.html?view=multipolygon&lon=8.65797&lat=48.45922&zoom=15&opacity=0.80&overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes .
Das MP landuse ist kaum zu erkennen, es gibt mehr “Fremdflächen”.
Ging mir genau so. An Relationen hab ich mich erst rangetraut als ich was mit Wanderwegen und ÖPVN machen wollte und an MPs für Flächen noch später. So ca 6 Monate nach meinem OSM-Start.
Die Anfänger-Hürde ist wirklich sehr hoch.
Gruss
Walter
“Am Anfang wusste ich noch nicht, wie man Ingdschenör schreibt und jetzt bin ich einer”
gerade zufällig hier gefunden:
“We are already talking about having a dedicated area datatype in API 0.7. This may well provide a native replacement for the current multipolygon relations, among other things (after all, relations are meant for metadata, not geometry; using relations for multipolygons is an ugly hack).”
Da erscheint die ganze Sache auf einmal in einem anderen Licht.
Gruss
Walter
Bisher gibt es aber keine andere Methode als Multipolygone, um Flächen zu erfassen.
Bis API 0.7 dürfte es sicher noch ein paar Jahre dauern.
…und wenn man auf zoom=12 rausfährt, wird das gesamte Ausmaß der Katastrophe sichtbar
Auch ein schönes Beispiel südwestlich von Bonn (selbst überschneidende Wege):
http://tools.geofabrik.de/osmi/debug.html?view=multipolygon&lon=8.65797&lat=48.45922&zoom=15&opacity=0.80&overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes
Edbert (EvanE)
Südlich von Bonn, dann hast du vermutlich den falschen Link in der Zwischenablage gehabt.
Aber südlich von Bonn gibt es keine Self Intersections mehr, da bin ich doch schon 3* drübergelaufen :).
Hier hat sich jemand Arbeit gemacht, wobei die Flächenbenennung wohl eher nicht in Ordnung sein dürfte:
http://tools.geofabrik.de/osmi/debug.html?view…
http://www.openstreetmap.org/?lat=52.8101&lon=8.0619&zoom=14&layers=M
Na ja, der Schwarzwald ist schon grob südlich von Bonn. Ich überlege schon eine Weile, ob ich diesen Bereich noch als zu meinem Aktionsradius gehörend definieren will
