ich mache mir gerade ein paar gedanken über die datenstrukturen, also node, way und relation. ich möchte nämlich aus einer osm datei ein ekarte generieren. hierzu schreibe ich einen eigenen renderer. nodes und ways erklären sich für mich von selbst. meine verständninsprobleme habe ich mit den relations. es gibt diese etablierten relations : boundary, multipolygon, restriction, route, enforcement. ich brauche für mein programm höchstens multipolygon zu verwenden, da die restlichen relations für meinen kartenanzeige uninteressant sind. was ich jetzt nicht ganz verstehe, muss ich die multipolygon relations reinnehmen um die karte korekt anzuziegen oder ist das nur ein feature um löcher zu generieren ? wäre nett wenn mich mal jmd aufklärt der vllt schon damit gearbeitet hat.
Ja, die gehören dazu. Größere Polygine werden auch aus Multipolygonen zusammengesetzt. Oder wenn es für ein Routing besser wäre.
wenn man also multipolygon relations weglässt könnte man keine insel in der mitte eines sees zeichnen, weil die eine fläche die andere überdecken würde ?
Richtig, das Multi-polygon sorgt dafür, daß in der Insel im See nicht See und Insel übereinander liegen. Und natürlich auch bei See im Wald, Lichtung im Wald, usw.
Ein Teil der Sachen gehen auch ohne Polygon, eine Insel liegt immer über dem Meer. Und ein See müßte immer das oberste sein.
Aber oft geht das nicht und dann sind es die Multi-Polygone die das lösen.
Eine der wenigen Ausnahmen sind z.B. Häuser im Stadtgebiet. Für die soll das Stadtgebiet nicht in ein riesen-Multi-Polygon umgewandelt werden.
Moin,
nö, so kann man das wiederum auch nicht behaupten.
Es steht Dir natürlich frei, für jedes - in sich geschlossene - Element mathematisch-geometrisch zu ermitteln, ob es innerhalb eines anderen liegt - und dann erst entsprechend zu zeichnen.
Multipolygone vereinfachen es in diesem Fall halt nur.
Und bei in sich geschlossenen Objekten, die aus mehreren Rand-Elementen gebildet werden, wüßte man sonst halt gar nicht, dass sie zusammen ein in sich geschlossenes Objekt bilden - obwohl, auch das könnte man ja durch Zusammensetzen der entsprechenden Elemente herausfinden. 
Alles nur eine Frage des Aufwandes - oder eben der Vereinfachung.
Ungefähr so, wie ein Lego-Bausatz - man bekommt ihn auch ohne Anleitung richtig zusammen - irgendwann …
Gruß
Georg
Genauer gesagt dienen multipolygon-Relation in erster Linie dazu, um Flaechen mit Auschluessen zu definieren. Also quasi ringfoermige Flaechen, die im Inneren einen Bereich haben, der nicht zur Flaeche dazugehoert, aber vollstaendig von der Flaeche umschlossen wird.
Das mit dem Ueberlagern von Flaechen ist zwar der haeufigste Fall, wo einem der Bedarf fuer ein entsprechendes Konstrukt auffaellt, ist eigentlich aber schon missverstaendlich. Denn See und Insel liegen ja nicht uebereinander, und sollten dann so auch nicht in der Datenbank erfasst sein. Das sit also nicht nur ein Problem fuer die Anzeige im Renderer, sondern alleien schon einfragte der datenbeschreibung.
Ein klareres Beispiel als der See ist vielleicht ein Innenhof von einem Gebaeude. Rundherum ist das Gebaeude (building=yes), aber im Innenhof ist kein Gebaeude mehr und auch sonst nichts, was man sinnvoll erfassen kann. Mit einem einfachen Polygon kann man nur den aeusseren Umriss des Gebaeudes erfassen. Dazu traegt man dann ein weiteres Polygon fuer die Innenkannte ein und verbindet diese beiden ueber die multipolygon-Relation.
Ein Multipolygon fuer Haeuser im Stadtgebiet ist uebrigens logisch falsch. Die Haeuser gehoeren ja zum Stadtgebiet dazu und sind keine Ausnahmen vom Stadgebiet.
Gruss
Torsten
da ich waldflächen, wasserflächen etc darstellen muss, werde ich die multipolygon relations zwangsweise mit reinnehmen müssen
nö, so kann man das wiederum auch nicht behaupten.
Es steht Dir natürlich frei, für jedes - in sich geschlossene - Element mathematisch-geometrisch zu ermitteln, ob es innerhalb eines anderen liegt - und dann erst entsprechend zu zeichnen.
wäre sicherlich möglich, nur stelle ich mir das problematisch vor zu bestimmen welches objekt dann das innere/äußere darstellt.
danke für eure antworten
darf ich mich hier mal dranhängen…
Exemplarisch:
Ein Reiterhof als area ist in OSM bereits vorhanden…Karte ringsum jungfräulich und landuse ringsum wird im nachhinein erfasst bzw. darüber gelegt…verwendet man Multipolygon…so weit ok.
Eine größere Area landuse ist in OSM bereits vorhanden und man möchte jetzt den Reiterhof als area dort innerhalb integrieren…verwendet man hierbei auch die Relationen oder liegt der neu erfasste Reiterhof jetzt “darüber” und man benötigt keine Relation ???
Die Reihenfolge der Erfasung ist der Datenbank vollkommen egal.
Und loese dich am besten mal von der “darueber” Vorstellung sondern stelle dir die Farge: Gehoert die Innere Flaeche als Teil zur aeusseren dazu, oder definiert sie eine Ausnahme von der Gesamtflaeche. Im letzteren Fall ist eine Relation zwingend erforderlich, im ersten Fall ist die Darstellung mit “darueber” und “daruter” alleine Sache des Renderers.
Gruss
Torsten
wenn Du Dich nicht ran traust, tagge es trotzdem “drüber”. Wenn es jemand stört, wird er/sie/es ändern. Die Regel ist ja ziemlich klar (kleiner Landusefläche vor größere Landusefläche). Die Renderer kommen damit auch problemslos klar - auch wenn das kein Argument sein darf 
Wenn man sich die gleiche Frage bei einem Parkhaus in einer Fußgängerzone stellt, wird einem sofort klar, daß es ohne Multipolygon nicht geht.
Ist das Parkhaus überirdisch, ist ein “großes Loch” in der Fußgängerzone.
Ist das Parkhaus unterirdisch, ist ein “kleines Loch” in der Fußgängerzone. (Nur der Eingang)
Dem stimme ich voll zu.
Nur möchte ich ergänzen, dass “landuse” etwas Besonderes ist. “landuse” gibt nur den allgemeinen Charakter eines Gebietes an und man braucht daher nicht unbedingt Löcher für kleine Ausnahmen. “landuse” hat sozusagen eingebaute Löcher. In ein Gebiet mit “landuse=industrial” kann man m.E. ohne Weiteres eine Unternehmervilla auf einem Werksgelände eintragen ohne ein Loch zu machen. Die Renderer wissen, dass “landuse” nur eine allgemeine “Hintergrundangabe” ist.
Weide