[Talk-de] Verwaltungsgrenzen Deutschland

Frederik Ramm frederik at remote.org
Fr Mär 19 10:11:43 UTC 2010


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




Mehr Informationen über die Mailingliste Talk-de