Hallo liebe Community,
ich komme einfach an einem bestimmten Punkt nicht weiter. Es geht um die Multipolygonen Relationen die mir sehr zu schaffen machen. Ich habe ein Programm entwickelt welches gezielt Objekte aus einer OSM File entnimmt. Ich entnehme z.B. alle natural/water und natural/land Objekte und speichere diese dann ab. Solche Objekte können auch durch eine Relation näher definiert werden, so kann das Wasser als outer role definiert sein und ein Ausschnitt/Loch/Insel als inner role. Leider habe ich feststellen müssen das sich nicht jeder an diese Konvention hält und jeder sein eigenens Süppchen kocht.
Bsp.:
bei diesem bsp ist es einfach die objekte zu ermitteln da sie ordnungsgemäß einem Typ(water,land) zugeordnet sind und die Relation diese verknüpft. Leider ist das auch nur ein optimales Beispiel, es gibt anscheinend so viele unterschiedliche Möglichkeiten die Relationen zu definieren das ich einfach nicht mehr durchblicke. So habe ich Relationen gefunden die direkt einem Typ zugeordnet sind, also nicht erst durch die referenzierten Ways näher deklariert werden oder Relationen deren referenzierte Ways keinem Typ zugeordnet sind, also namenlos sind etc. Ich würde mich sehr freuen wenn wir das Ganze einmal durchsprechen können denn so komme ich einfach nicht weiter. Danke im vorraus.
ich habe hier nochmal ein beispiel aus dem ich nicht schlau werde…
für mich erfüllt diese Relation keinen Zweck da nicht angeben ist um was für Objekte es sich überhaupt handelt…wie gesagt, ich Blick einfach nicht mehr durch !
alle guten dinge sind drei…hier noch ein beispiel :
ich gehe davon aus das outer water oder riverbank sein kann bzw. beides den gleichen zweck erfüllt und inner keine bezeichnung hat da die Relation selber als water bezeichnet wurde…nur warum sollte jmd diese Relation aufstellen wenn doch alles water ist ???
Dein zweites Beispiel beschreibt ein Gebäude mit Innenhof. Tags macht man wenn möglich an die Relation daher das building=yes in der Relation. Der outer-Way beschreibt dann die Umrisse des Gebäudes, die inner-Ways dann die “Löcher” im Gebäudeumriss also Innenhöfe. Sieht man ja auch sehr schön, wenn man sich die Relation mal anguckt: http://www.openstreetmap.org/browse/relation/22220
Beim dritten Beispiel geht es um eine See mit Insel. Meiner Meinung nach könnten alle Tags des outer-Ways in die Relation.
gut, das zweite beispiel leuchtet mir nun ein…die Relation stellt also ein Gebäude dar, aber woher erkennst du das beim dritten Beispiel eine See mit Insel dargestellt wird. Das Wasser wurde deklariert, aber keine Insel oder sonstiges…
ich hab bei openstreetmap nachgeschaut…es handelt sich auch nur um wasser und keine insel
Wenn man sich Way 27296257 anguckt, dann scheint es sich eher um einen Fluss mit Insel zu halten (waterway=riverbank).
Nach meinem Verstaendnis ist dieser Way nicht ordentlich markiert: Wenn schon waterway=riverbank gesetzt ist, dann sollte da kein natural=water mehr stehen.
Fuer den einzelnen Way mag das ja noch egal sein, aber im Rahmen des Multipolygons wird das dann zu einem echten Fehler:
Da das multipolygon selber mit Tags markiert ist (ungleich den Tags am outer-Way), kann in diesem Fall nicht die Regel gelten, dass die Tags vom outer-Way auf die Relations-Flaeche anzuwenden sind. D.h. also hier wird einmal ein natural=water mit Ausschluss der Flaeche von Way 27296308 durch die Relation definiert. Zusaetzlich definiert Way 27296257 die komplette Flaeche (ohne Ausschluss) als natural=water und waterway=riverbank.
Offensichtlich waren hier zwei verschiedene Bearbeiter taetig, und der eine wusste nicht, was der andere macht.
Das ist letztendlich auch das Hauptproblem der Multipolygone: Fuer Gelegenheitsmapper koennen sie ganz schnell undurchschaubar kompliziert werden.
also stellt die relation (inner und outer) natural=water dar. meine applikation würde nämlich als bezug das tag aus der relation nehmen und die ways somit auch als water definieren
So wie sie z.Z. markiert ist stellt die relation (outer ohne inner) natural=water dar, und der outer-way stellt zusaetzlich waterway=riverbank dar. Ich bin mir ziemlich sicher, dass das so nicht gemeint ist. Aber das ist rein logisch das, was in der Datenbank steht.
Aufgrund des tagging-Fehlers am outer-Way siehst du wahrscheinlich auch keine Insel beim Renderer.
Bspw 3 ist einfach fehlerhaft getaggt. EDIT: wurde aber schon von FvGordon behoben.
Alles was an den Wegen getaggt ist, gilt für das Objekt, was der Weg darstellt.
Konkret: der outer-Way ist als Flussbett getaggt und wird als solches komplett blau. Dieses waterway=riverbank gehört an die Relation und das natural=water könnte man sich auch sparen., schadet aber auch nicht. Der outer-Way darf keine Tags haben.
gut das wir das nochmal diskutiert haben, ich hatte nämlich vor die multipolygonen relations aussen vor zu lassen, weil ich dachte das es reicht alle ways zu extrahieren. jetzt merke ich aber das auch ways ohne tags exisiteren können und diese erst durch einen relation näher bezeichnet werden kann. diese unbezeichneten ways wären nämlich einfach von meinem parser übersheen worden, da dieser nur ways mit tags speichern kann. ich hoffe meine überlegung ist richtig
deine letzte überlegung betr. ways ohne tags ist absolut richtig!
hintergrund ist zum einen, dass die maximale anzahl an knoten für einen weg auf 2000 begrenzt ist und zum anderen,
dass bei vielen polygonen der äußere weg aus teilen anderer wege besteht / bestehen kann, welche wiederum selbst
bestandteil anderer polygone mit anderen eigenschaften sind.
wenn nun ein äußerer weg z.b. einen see oder flußlauf beschreibt u. wegen der maximalen knötchenzahl aufgespalten werden muss,
müssen die flächentags von diesen elementen des polygons entfernt werden, da sie ja sonst selber “nichtgeschlossene flächen” darstellen
würden. (der validator meckert dann auch entsprechend…)
das ist also keine option sondern sollte schon so gehandhabt werden. andere tags wie z.b. source, note etc. können jedoch beibehalten werden.
dies empfiehlt sich sogar, da gerade neue mapper mit ways ohne tags u. multipolygonen erst einmal gar nichts anfangen können…
besteht der äußere weg eines polygons allerdings aus einem einzigen geschlossenen weg, (also auch max. 2000 nodes) können die tags auf dem
element / weg als auch der polygonrelation selbst sein, das beisst sich dann nicht. (allerdings müssen die tags dann auch übereinstimmen)
multipolygonrelationen sind schon so ein thema für sich…
Nur weil der Validator meckert, ist das noch lange kein Grund etwas entsprechend zu taggen. Wir mappen nicht fuer den Renderer und bestimmt auch nicht fuer den Validator. Entweder man ignoriert die warnung, oder man bringt dem Validator mal multipolygon-Relationen bei.
Davon wuerde ich wiederum strikt abraten. Die Tags, die die Multipolygon-Flaeche beschreiben gehoeren entweder alle in die Relation oder alle (einheitlich) an den outer-Way (mehrere outer-Ways sind auch moeglich und muss man entsprechend auch auswerten, sollte man m.E. beim Mappen aber vermeiden, um die Strukturen fuer andere mapper moeglichst einfach zu halten). Eine Mischform (ein Teil der Tags in der Relation, ein Teil der Tags an den outer-Way) ist weder durch die (verschiedenen) Definitionen der multipolygon-Relation gedeckt, noch duerfte es der Uebersicht foerderlich sein: Ein Way ohne jegliche Tags deurfte von Anfaenegrn eher als Teil einer Relation erkannt werden, als ein Way der nur einen Teil der fuer ihn bestimmten Tags enthaelt.
Das hat jetzt natuerlich nichts mit der Auswertung von multipolygon-Relationen zu tun sondern mit deren Erstellung. Aber oberste Regel dabei sollte immer sein: Keep it simple! Mit multipolygon-Relationen kann man syntaktisch korrekte aber unheimlich komplizierte Gebilde erzeugen, was in einem “Open” Projekt aber ein ganz schlechte Idee ist.
