[Talk-de] Verwaltungsgrenzen Deutschland

Kai Krueger kakrueger at gmail.com
Fr Mär 19 13:46:38 UTC 2010


On 01/-10/-28163 08:59 PM, Frederik Ramm wrote:
> 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.

+1

>
> 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.)

Es verursacht wohl auch jetzt schon probleme fuer die renderer, da die 
relationen nicht mehr zu interpretieren sind, da es nicht zum 
etablierten schema passt und auch logisch weder zum Typ boundary noch 
multipolygon passt. Ich kann mich zwar nicht mehr errinern, was genau 
das Problem ist, aber es wurde auch letztens auf IRC diskutiert und wie 
es Probleme fuer die Anwendungen verursacht. Zum Teil ist es das Problem 
von Osm2Pgsql, das die "role=" derzeit wohl ignoriert. Aber einige der 
Beispiel hatten noch nicht mal eine "role=" sodass es ohnehin nichts 
nuetzen wuerde.

>
> 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:

Das sehe ich eigentlich nicht so. Die information ist durchaus relevant 
und nuetzlich fuer OSM, es muss halt nur in einem tagging schema sein, 
das auch funktioniert.

>
> 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.

Wieso laesst sich die Information eigentlich nicht aus den bestehenden 
Daten ermitteln. Vermutlich sind z.B. alle deutschen bundeslaender 
inerhalb der Grenzen der Bundesrepublik. Vorausgesetzt man hat korrekte 
Polygone fuer die Bundeslaender und fuer Deutschland, laest sich die 
Verwaltungshierarchie einfach z.B. per PostGIS berechnen.

OSM ist eine geo _spatial_ Datenbank, der spatial Teil sollte bei der 
Auswertung also auch beruecksichtigt werden und nicht zusaetzlich durch 
manuelle verlinkung fehlertraechtig ersetzt werden.

>
> 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>

Dies macht von den alternativen noch am meisten Sinn.

>
> 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.

Nein, bitte nicht wenn es irgenwie zu vermeiden geht. Aber eine 
entsprechende Rolle ist nun wirklich das minimum.

>
> Bye
> Frederik
>
>

Kai




Mehr Informationen über die Mailingliste Talk-de