[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