Hallo, Stefan Siegel wrote: > In München (Relationen 62428 und 62580) wurden die Grenzrelationen der > Stadtbezirke und Bezirksteile als Mitglied in die Relation der jeweils > übergeordneten Verwaltungsebene aufgenommen, so dass keine Liste von > IDs mehr separat verwaltet werden muss, und in JOSM hat man im > Reiter "Child Relations" eine sehr komfortable Übersicht über die > Verwaltungsstruktur. Ich finde diese Idee daher sehr gut und hilfreich.
Ich finde das nicht gut. Ein Multipolygon besteht aus einer Menge von Ways. Einige Multipolygone sind so gross, dass die Ways wiederum in Relationen zusammengefasst werden muessen. Die Unter-Relation tritt dabei also an die Stelle eines Ways, genauso wie man auch Wanderrouten aufteilt und so weiter. (Ich weiss nicht, ob das derzeit wirklich schon so gemacht wird, aber es ist zumindest der Plan - es faellt nicht schwer, eine Grenze vorzustellen, die so komplex ist, dass niemand gerne alle ihre Teil-Ways in *einer* Relation haben will.) Hieraus folgt, dass eine Relation, die Teil eines Multipolygons ist, grundsaetzlich erstmal als Teil eines aeusseren oder inneren Ringes dieses Multipolygons ausgewertet werden muss. Das geht mit diesen Muenchen-Relationen total in die Hose. Ich finde auch, dass OSM sich staerker auf Geodaten konzentrieren sollte. Wir sind keine Datenbank fuer Verwaltungshierarchien. Meine Praeferenz: 1. Verwaltungshierarchien in eine externe Datenbank und Links hinein nach OSM anhand des offiziellen Namens oder Gemeindeschluessels o.ae.; OSM kennt dann zwar den Umriss eines Landkreises, braucht aber nicht die Information zu speichern, zu welchen Land oder RegBez der gehoert. Wenn ihr das partout nicht wollt, dann 2. Verwaltungshierarchien durch ein *eigenes* Relationen-Netz abbilden. Also: Eine Relation, die lediglich die Geometrie eines Landkreises beschreibt. Dann eine *zweite* Relation, die "den Landkreis selbst" beschreibt. Diese zweite Relation kann dann lauter Zusatz-Infos haben: <relation id="x"> <tag k="name" v="Landkreis Trullala" /> <tag k="type" v="gebietskoerperschaft" /> <member role="capital" type="node" id="5" /> <member role="boundary" type="relation" id="72" /> <member role="verschwistert_mit" type="relation" id="192" /> ... </relation> Sowas in dieser Art, ein abstraktes Objekt also. Und wenn ihr das partout auch nicht wollt dann 3. Macht es in Gottes Namen so wie in Muenchen, aber gebt den Unter-Relationen eine Rolle, die erkennen laesst, dass es sich dabei nicht um einen Teil eines Polygonrings handelt. - Aber das ist wirklich die unsauberste Loesung von allen dreien. Bye Frederik _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de