logo       
Google Custom Search
    AddThis Social Bookmark Button
-->

Re: Verwaltungshierarchie mit Inkonsistenzen?: msg#00039

Subject: Re: Verwaltungshierarchie mit Inkonsistenzen?
Am Donnerstag, 20. Juli 2006 13:25 schrieb Martin Trautmann:
> On 2006-07-20 12:33, Thomas Mack wrote:
> >
> > Sorry, nein: die Ebene 6 ist die Gemeindeebene. Die Ortsebene ist
> > noch nicht sehr bevölkert.
>
> Ok - wir fallen hier immer wieder auf die Nase, was die Level bedeuten.
>
;-) Ja, aber jetzt merken wir es wenigstens... Wahrscheinlich fallen
einige frühere Mißverständnisse auf das Konto dieser Unklarheit zurück.


> > [...] dann halt mit dem Aufräumen
> > in geodb_locations (ich habe mich entschieden, Bundesländer etc. mit
> > dem loc_type POPULATED_AREA zu versehen, das eigentlich Orte
> > bezeichnet).
>
> Autsch, warum denn das auf einmal?
>
> Ich zitiere aus deiner .sql:
>  INSERT INTO geodb_type_names VALUES(100700000,'de','Ortschaft');

Oha, die geodb_type_names gehört zu den Relationen, die nie gepflegt
wurden und werden. Sollte ich wirklich mal ändern...

> und aus der constant.txt:
>  POPULATED_AREA        100700000
>
Das ist doch schön allgemein, daß man alles dort hineinpacken kann ;-)

>
> Du willst 1001* bis 1006* quasi aufgeben?
>
> Mal die ganz naive Frage: Warum laesst du's nicht wie gedacht und
> verwendest tatsaechlich die 100600000 "POL_DIVISION" / "Politische
> Gliederung" synonym zu lvl_6 und machst sie tatsaechlich zur
> Gemeinde-Ebene?
>
Weil es in geodb_locations nicht um Verwaltungsstrukturen geht, sondern
um Eintragstypen. Die Strukturen stehen schon in geodb_hierarchies drin,
wir brauchen sie nicht zu duplizieren.

Zweite Geschichte: was heute noch eine Gemeinde ist, kann morgen schon
ein simpler Ort sein. Dann müßten wir tatsächlich einen NEUEN Eintrag
mit einer neuen loc_id erzeugen, obwohl sich an dem Ort bis auf die
verwaltungsmäßige Zugehörigkeit nichts geändert hatte. Das ist nicht
Sinn der Sache.

Alternativ könnte man auch in geodb_locations die Gültigkeitsdaten
mit eintragen, und mehrere Einträge für ein- und dieselbe loc_id
erlauben. Aber im Grunde dupliziert es nur das, was eh schon in der
geodb_hierarchies drinsteht.

> Du hattest damals erklaert, ursaechlich sei die einfache Abfrage in der
> Ortssuche nach 100700000. Du opferst aber damit IMHO die sinnvolle,

Puuuh, nicht daß ich das jetzt verstehe...

> hierarchische Gliederung der opengeodb als solche, nur um die
> SQL-Abfrage zu vereinfachen.
>
Nein, die hierarchische Gliederung ist nicht die Sache der geodb_locations,
sondern - wie der Name schon andeutet - die geodb_hierarchies.

> Ich wiederhole wieder mal meinen Vorschlag
>
> #########################################################################
> ###  Vorschlag zur klareren Organisation der Verwaltungshierarchien   ###
>
> lvl geodb_type  GEODB        NUTS    Deutschland    AGS   Österreich   GS
> 1  100100000   CONTINENT            Erdteil              Erdteil
> 2  100200000   STATE                Staat                Staat
> 3  100300000   NUTS_I       I       Bundesland      2    Bundesland    1
> 4  100400000   NUTS_II      II      Regierungsbez.  3
> 5  100500000   NUTS-III     III     Kreis           5    Bezirk        3
> 6  100600000   POL_DIVISION         Gemeinde        8    Gemeinde      5
>
> #########################################################################
>
Und was spricht dagegen, 100100000 bis 100600000 in der geodb_locations
auf die 100700000 zu vereinheitlichen? Klar, es fehlt die Klartextinfo
in geodb_type_names, was level=3 oder level=7 bedeutet. Aber ansonsten
gibt es keinen Unterschied. Ganz im Gegenteil, man hätte sogar den Vorteil,
von Erdteilen bis zu "Gemeindeteilen" alles unter einem Typ abfragen zu
können.

> In Oesterreich gaebe es also nur lvl 3, 5 und 6.
> Fuer die Schweiz u.a. kann man's aehnlich organisieren.
>
Ja, das ist ja auch schon jetzt so. Vor allem sichtbar an Liechtenstein.

> 100600000 koennte also richtig mit Leben gefuellt werden - kurzfristig
> durch Verschieben aller Eintraege mit AGS von 100700000 nach 100600000.
>
> Ob und wie man die Verwaltungsgemeinschaften mit hineinbringt, ist noch
> unklar. Derzeit schweben sie zwischen lvl 5 und lvl 6:
>
> ###
> 5.5 500700000   NAME_VG              Amt/Verw.G.    (7)
> ###
>
Ja, das ist noch ein anderes Thema, was ich damals halt so gelöst hatte,
daß ich die VGs gar nicht in die Verwaltungsstrukturen mit übernommen
hatte, sondern nur als zusätzliches Attribut eines Ortes definiert hatte.
Und die definierte sich alleine über den text_type. Der Anwender muß
selber wissen, was es damit auf sich hat.

> >> Klassisches Problem ist hier weiterhin der Flaschenhals, dass nur
> >> Thomas Aenderungen eintragen und Releases machen kann. Bei Bedarf
> >> kann ich mal alle mir bekannten Unterschiede zur opengeodb
> >> heraussuchen.
> >
> > "Administratoren dringend gesucht!"
>
>  -v?
>
;-))))

Solange niemand da ist, der meine Tätigkeiten mit übernimmt, solange
bleiben sie an mir kleben, ohne daß ich ausreichend Zeit dafür hätte.

Wenn Du magst, kannst Du gerne auch "Administrator" beim Projekt werden,
und sinnvollerweise mir ein paar Aufgaben abnehmen.

Thomas


-- 
Mailingliste OpenGeoDB
Listenadresse: opengeodb-r1mDYR0DdAyzQB+pC5nmwQ@xxxxxxxxxxxxxxxx
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)



<Prev in Thread] Current Thread [Next in Thread>