[Talk-de] Gebäude, Grundstücke und Institutionen
Wolfgang Hinsch
osm-listen at ivkasogis.de
Di Sep 10 09:35:20 UTC 2013
Am Dienstag, den 10.09.2013, 01:28 +0200 schrieb Martin Koppenhoefer:
> Am 10. September 2013 00:57 schrieb Gerhard Hermanns <
> gerhard.hermanns at uni-due.de>:
>
> > Ein schönes Beispiel sind meiner Meinung nach Universitäten mit mehr als
> > einem Campus. Alles folgt einer verschachtelten Logik, die ich mit der
> > site-Relation abbilden kann: Die Uni besteht aus mehreren Campi, ein
> > Campus hat mehrere Gebäude und Parkplätze, die Parkplätze haben Frauen-
> > und Behindertenplätze, mehrere Gebäude haben einen gemeinsamen,
> > übergeordneten Namen, in den Gebäuden sitzen Institute oder die Mensa usw.
> > Hier kann ich dann auch einzelne Nodes für die Einrichtungen verwenden,
> > wenn ich nichts anderes habe. Dadurch, dass ich sie in die Relation
> > packen kann, werden sie in einer Auswertung trotzdem als zur Uni gehörig
> > erkannt.
> >
>
>
> für das allermeiste braucht man da allerdings keine site-Relation, das sind
> Fälle die man weitgehend mit Polygonen lösen kann: pro Campus eines, der
> Rest sind dann weitere unabhängige Objekte, räumlich innerhalb des Campus'
> und daher automatisch zugehörig. Das einzige, was man dann mit einer site-
> (oder auch multipolygon-) Relation als zusammengehörig modellieren muss
> sind die einzelnen Campi. Einen node mit entrance=yes/main kann man z.B.
> auch ohne Relation setzen.
>
> Wenn man anfängt, jeden Parkplatz (und schließlich jeden Papierkorb und
> jede Parkbank) in die Site-Relationen einzutragen, obwohl er auch schon
> räumlich auf dem Campus-Gelände liegt, dann wird man über kurz oder lang
> ein paar Dinge vergessen, d.h. es wird unübersichtlich und fehlerträchtig,
> und man kann sich letzten Endes doch nicht auf die Relation verlassen.
>
> Man kann sicherlich für alles eine site-Relation anlegen und tolle Rollen
> etc. vergeben, aber solange es auch ohne geht sollte man das unbedingt so
> machen, weil Relationen zusätzliche Komplexität einführen und tendenziell
> schnell mal kaputt gehen bzw. nicht erweitert werden (Beispiel: ein Mapper
> fügt etwas zur Karte hinzu, übersieht aber die site-Relation und nimmt das
> daher nicht mir rein), um so mehr, als nicht jeder mit JOSM arbeitet ;-)
>
-1
Es ging darum, nicht nur die Uni zu erfassen, sondern auch die einzelnen
Bestandteile der Uni den Fachbereichen etc. zuzuordnen. Spätestens dann
wird das Multipolygon gewöhnungsbedürftig, da hier ein Haufen
Multpolygone übereinander gelegt werden muss.
Im Übrigen ist auch ein Multipolygon nichts anderes als eine Relation.
Multipolygone sollten hauptsächlich benutzt werden, um räumliche
Gegebenheiten darzustellen. Für die Darstellung organisatorischer
Konstrukte ist die Site dem Multipolygon überlegen, weil sie alle Arten
von Objekten einbinden kann, Hierarchien relativ einfach und logisch
abgebildet werden können und beim Rendern weniger fehleranfällig sind.
Ein Multipolygon kann vom Renderer leichter missverstanden werden.
Gruß, Wolfgang
Mehr Informationen über die Mailingliste Talk-de