boundary vs multipolygon

Da stimme ich mit dir ueberein, aber meine Schlussfolegrung daraus ist eine voellig andere:

Eine multipolygon-Relation dient ausschliesslich dazu, um eine Flaeche zu definieren. Alles was darueber hinaus geht, hat in so einer Relation nichts zu suchen.

Fuer dein Beispiel mit dem Forsthaus und dem Wald bedeutet das, dass die Wladflaeche per multipolygon-Relation erfasst sein kann. Die logische Verbindung zwischen Forsthaus und Wald ist aber eine eigene Releation ganz anderen Typs, bei der die Waldflaechenrelation eines der Mitglieder ist.

Warum man hier in Deutschland aber meint, dass die Grenzen der Verwalltungsbezirke Flaechenobjekte sind, ist allerdings eine ganz andere Frage.

Damit man das Rad nicht immer wieder neu erfinden muss, geht es also nicht darum, dass man die multipolygon-Relationen aufblaeht, sondern stattdessen muss man sie als einzelnen Objekt begreifen, das wiederum Mitglied in anderen Relationen sein kann.

Und was das Weglassen des type=* angeht, so kann ich da nur Nop zustimmen. In vielen Faellen mag es zwar letztendlich ueberfluessig scheinen, aber es gibt auch genug Faelle, wo sich dadurch Missverstaendnisse einfach vermeiden lassen. Besser der Klarheit zu Liebe ein Tag mehr verwenden. (Das ist so aehnlich wie bei Programm-Code: Der beste Code ist nicht der, der mit am wenigsten Zeichen auskommt, sondern der, der (von Fremden) am einfachsten zu lesen ist.)

Gruss
Torsten

+1

Ausserdem werden die Relationen im Relationsfenster erst nach Typ und dann nach Name oder ref sortiert. Das hat durchaus seine Vorteile.

Gruß.,
ajoessen

aber andersherum beschränkt es auch wieder. Du kannst eben nicht type=public_transport und type=route setzen oder gar type=multipolygon und spätestens bei letzterem ist dann eh entscheidend welche anderen tags gesetzt sind.
Außerdem geht das Auswerten doch nach dem Prinzip ich suche mir alle relationen mit route=bus und schaue dann nur nach name oder ref. die weiteren Details interessieren eigentlich dann nicht. Ein anderer Auswerter schaut nur auf restriction=no_left_turn und sucht dann ob die Rollen from to via vergeben sind. Auch hier sind andere Details nicht von belang.

Das sollst Du auch nicht. Mehrere Aussagen => mehrere Relationen.

bye
Nop

Hallo Nop,

wo aber ist der Unterschied zwischen type=public_transport linevariant=bus oder type=route route=bus?

Abfrage: “Die administrativen Grenzen bitte, weil ich will 'ne schematische Karte machen.” Hilfe! Nein, ich wollte nicht Millionen von Gebäudeumrissen haben! So erst mal nen Kaffee kochen, bis der Renderer das die administrativen Grenzen rausgesucht hat…

Da der Auswertecode ja eh schon für Multipolygone verarbeiten kann, ist es kein Problem den noch mal für Grenzrelationen anspringen zu lassen. Und zum eintragen eines Forthauses im Wald brauche ich keine extra Relation!

Normalerweise bin ich weniger an der Grenzlinie interessiert als an der Fläche.

Das Interessante an der Bundesrepublik ist ja auch nicht die Grenze sondern der Inhalt.

Wenn du in der Nähe einer Grenze wohnst, interessiert die die Grenze als Weg (da ändern sich Gesetze/Sprache/Verkehrsregeln/…) und weniger die dadurch eingeschlossene Fläche.

Ich sehe das so:

  • Eine Grenze besteht immer zwischen zwei Objekten (die auch eine Fläche haben).
    Das sind im Prinzip Striche auf der Landkarte (Wege) also type=boundary/boundary_segment.
  • Die Umgrenzung eines Gebietes setzt sich aus allen Grenzen zu Nachbargebieten zusammen.
    Dafür kann man, wenn man unbedingt will, auch ein Multipolygon nehmen.
    Mitglieder sind die Grenzabschnitte zu jeweils einem Nachbarn.
  • Aua, Multipolygone wollen keine Relationen für die Grenzabschnitte, sondern einzelne Wege.
    Da sollte man mal in die Weiterentwicklung investieren, wenn man Multipolygone will.

Auf die Art und Weise könnte man die zwei Sichtweisen auf eine Grenze (lokal = Line/Trennung, großräumig = eingeschlossene Fläche) beide sinnvoll abbilden.

Edbert (EvanE)