Re: Verwaltungshierarchie mit Inkonsistenzen?

On 2006-07-24 15:47, Ingmar Loetzsch wrote:
>> > -- 7 Ortsobjekte, die gleichzeitig auf Level 6 und Level 7 stehen
>> 
>> naemlich welche?
> 
> Das ergab gerade die Abfrage, die ich hier wiederhole:
> 
> SELECT * FROM geodb_locations AS lc
> INNER JOIN geodb_hierarchies AS h1 ON h1.loc_id = lc.loc_id
> AND lc.loc_type <> 100800000 -- keine PLZ
> AND lc.loc_id > 0 -- keine Pseudoobjekte
> INNER JOIN geodb_hierarchies AS h2 ON h2.loc_id = h1.loc_id
> WHERE -- Vergleich eines Datensatzes mit sich selbst ausschließen. Hier 
> müsste ein Schlüssel her.
> (
>       (h1.level <> h2.level)
>       OR (h1.id_lvl1 <> h2.id_lvl1)
>       OR (h1.id_lvl2 <> h2.id_lvl2) OR (h1.id_lvl2 IS NULL AND h1.id_lvl2 IS 
> NOT NULL) OR (h1.id_lvl2 IS NOT NULL AND h1.id_lvl2 IS NULL)
>       OR (h1.id_lvl3 <> h2.id_lvl3) OR (h1.id_lvl3 IS NULL AND h1.id_lvl3 IS 
> NOT NULL) OR (h1.id_lvl3 IS NOT NULL AND h1.id_lvl3 IS NULL)
>       OR (h1.id_lvl4 <> h2.id_lvl4) OR (h1.id_lvl4 IS NULL AND h1.id_lvl4 IS 
> NOT NULL) OR (h1.id_lvl4 IS NOT NULL AND h1.id_lvl4 IS NULL)
>       OR (h1.id_lvl5 <> h2.id_lvl5) OR (h1.id_lvl5 IS NULL AND h1.id_lvl5 IS 
> NOT NULL) OR (h1.id_lvl5 IS NOT NULL AND h1.id_lvl5 IS NULL)
>       OR (h1.id_lvl6 <> h2.id_lvl6) OR (h1.id_lvl6 IS NULL AND h1.id_lvl6 IS 
> NOT NULL) OR (h1.id_lvl6 IS NOT NULL AND h1.id_lvl6 IS NULL)
>       OR (h1.id_lvl7 <> h2.id_lvl7) OR (h1.id_lvl7 IS NULL AND h1.id_lvl7 IS 
> NOT NULL) OR (h1.id_lvl7 IS NOT NULL AND h1.id_lvl7 IS NULL)
>       OR (h1.id_lvl8 <> h2.id_lvl8) OR (h1.id_lvl8 IS NULL AND h1.id_lvl8 IS 
> NOT NULL) OR (h1.id_lvl8 IS NOT NULL AND h1.id_lvl8 IS NULL)
>       OR (h1.id_lvl9 <> h2.id_lvl9) OR (h1.id_lvl9 IS NULL AND h1.id_lvl9 IS 
> NOT NULL) OR (h1.id_lvl9 IS NOT NULL AND h1.id_lvl9 IS NULL)
>       OR (h1.valid_since <> h2.valid_since) OR (h1.valid_since IS NULL AND 
> h1.valid_since IS NOT NULL)
>       OR (h1.valid_since IS NOT NULL AND h1.valid_since IS NULL)
>       OR (h1.date_type_since <> h2.date_type_since) OR (h1.date_type_since IS 
> NULL AND h1.date_type_since IS NOT NULL)
>       OR (h1.date_type_since IS NOT NULL AND h1.date_type_since IS NULL)
>       OR (h1.valid_until <> h2.valid_until)
>       OR (h1.date_type_until <> h2.date_type_until)
> )
> AND -- überlappende Zeiträume (Überlegung: Standardwert statt NULL bei 
> valid_since und NOT NULL setzen?)
> (
>       (h1.valid_since IS NULL AND (h2.valid_since IS NULL OR h2.valid_since 
> <= h1.valid_until))
>       OR (h1.valid_since <= h2.valid_until AND h2.valid_since <= 
> h1.valid_until)
> )
> ORDER BY h1.loc_id, h1.valid_since;

Und eine derart komplizierte Abfrage liefert keinerlei Resultate, die man
per copy/paste hier einfuegen koennte?

(Aus der Parallel-Mail:
:> Von daher waer's einfacher, fuer die nicht-SQL-Anwender allgemein, aber
:> auch fuer's spezielle Problem selbst mehr oder weniger auszugweise die
:> Daten zur Verfuegung zu stellen.
:
:Diesen Aufwand kann ich nicht betreiben. Mir ist nicht bekannt, in
:welcher Reihenfolge die Datensätze in den Textdateien stecken. Und was ist
:mit den komplizierten Abfragen, die über mehrere Tabellen gehen? Die
:Resultate kann man nur mit extrem hohem Aufwand durch Verweise auf
:Datensätze darstellen.


Wuerdest du diese sieben loc IDs nennen, so wuesste ich wenigstens, worum
es geht.

>> Schon bei historischen Daten wird's schwierig: Der Zusammenschluss zweier
>> Gemeinden hat fuer die Gesamtgemeinde dann mehrere parallel gueltige
>> Gemeindeschluessel.
> 
> Was bedeutet das? Unter "gültig" sein verstehe ich, dass die Daten an einem 
> bestimmten Tag gültig sind. Die alten Gemeinden in deinem Beispiel haben 
> einen gültigen und eindeutigen AGS bis zur Reform. Danach haben sie keinen 
> gültigen AGS mehr, weil sie gar keine Gemeinden mehr sind. Statt dessen gibt 
> es die neue Gemeinde, die ihrerseits ab dem Tag des Inkrafttretens der Reform 
> einen AGS hat, aber nicht davor.


Gemeinde A: AGS 12345678 bis 31.12.2003,
Gemeinde B: AGS 12345679 bis 31.12.2003,

dann Zusammenschluss in Gemeinde "B-A" mit AGS 12345680,
  ehem. AGS: 12345678 bis 31.12.2003 (Gemeinde A)
  ehem. AGS: 12345679 bis 31.12.2003 (Gemeinde B)

Neben Zusammenschluessen gibt's auch Gemeinde-Zerfledderungen, entweder wo
Gemeinden geteilt werden, oder aber wo z.B. das Dorf zu Gemeinde C kommt,
ein Grossteil der Flaeche aber zu Gemeinde D.


>> > Typ-3-Regel: Jeder PLZ-Bereich (loc_type 100800000) hat genau 2 Einträge 
>> > in geodb_textdata, einen mit text_type 500100000 (PLZ als Name) und einen 
>> > mit text_type 500100004. Ist das Zufall oder eine Regel vom Typ 1 oder 2?
>> 
>> Per Definition sollte es so sein. Ich selbst halte den Repraesentanten
>> fuer evtl. zufaellig und daher manchmal falsch gewaehlt - aber da dies
>> anscheinend offizielle Daten als Quelle verwendet, darf es nur einen
>> geben.
> 
> Das widerspricht der Erklärung von Thomas.
> 
> "Das ist mehr oder weniger Zufall. Man kann dort beliebig viele Daten
> angeben. Z.B. könnte man auch alle KFZ-Kennzeichen einfügen, die in
> dem Postleitzahlgebiet aktiv sind."

Ja, koennte man. Bisher hat man das noch nicht, von daher stimmt deine
Regel bisher.

Thomas ist der Scheff - er macht, was reinkommt, also ist sein Wort Gesetz
:-)

> Vielleicht kann man das etwa so präzisieren. Ein PLZ-Bereich hat genau eine 
> PLZ. Es ist zu klären, ob die PLZ eines PLZ-Bereichs vom Datum abhängig sein 
> darf, d. h., ob sich die Nummer eines PLZ-Bereichs ändern darf (würde ich 
> nicht zulassen). Zur Zeit hat jeder PLZ-Bereich eine alternative 
> Ortsbezeichnung (text_type 500100004). Wenn es erforderlich wird, davon 
> abzuweichen, muss man die Regel ändern. Weitere Informationen über die 
> PLZ-Bereiche werden zur Zeit nicht in geodb_textdata gespeichert.

So kann man das sehen. 


>> > Typ-2-Regel: Jeder PLZ-Bereich wird in geodb_hierarchies verwendet. Was 
>> > sind die Ausnahmen?
>> > 
>> > -- unbenutzte PLZ-Bereiche
>> > SELECT lc.loc_id, td1.text_val FROM geodb_locations AS lc
>> > INNER JOIN geodb_textdata AS td1 ON td1.loc_id = lc.loc_id AND 
>> > td1.text_type = 500100000 -- die Nummer des PLZ-Bereichs
>> > AND lc.loc_type = 100800000
>> > LEFT JOIN geodb_hierarchies AS h ON h.loc_id = lc.loc_id
>> > WHERE h.loc_id IS NULL;
>> > -- 89 Datensätze
>> > 
>> > Die Nummern der unbenutzten PLZ-Bereiche werden auch nicht in 
>> > geodb_textdata benutzt, wie das folgende Statement zeigt:
>> 
>> Beispiele?
> 
> Beispiele wofür? Das Statement zeigt - Fehlerfreiheit vorausgesetzt, dass in 
> geodb_textdata keine PLZ (text_type 500300000) verwendet werden, für die zwar 
> ein PLZ-Bereich existiert, dieser aber nicht in geodb_hierarchies verwendet 
> wird.

Beispiele fuer diese 89 Datensaetze. 

> Ich habe das entsprechende Statement geringfügig angepasst (nur Deutschland, 
> nur aktuelle Daten):
> 
> SELECT * FROM geodb_textdata AS td2
> INNER JOIN geodb_hierarchies AS h ON h.loc_id = td2.loc_id
> AND td2.text_type = 500300000
> AND h.id_lvl2 = 105 -- nur Deutschland betrachten
> AND td2.valid_until >= current_date
> INNER JOIN geodb_textdata AS td3 ON td3.loc_id = td2.loc_id
> AND td3.text_type = 500100000
> WHERE NOT EXISTS
> (
>       SELECT * FROM geodb_locations AS lc
>       INNER JOIN geodb_textdata AS td1 ON td1.loc_id = lc.loc_id AND 
> td1.text_type = 500100000 -- die Nummer des PLZ-Bereichs
>       AND lc.loc_type = 100800000
>       WHERE td1.text_val = td2.text_val
> )
> ORDER BY h.id_lvl2, td2.text_val;
> 
> Es liefert 17 Zeilen mit Dresden, Leipzig, Roitzsch u. a. Das ist etwas 
> übersichtlicher.

Naja - es gibt 33 Zeilen mit Leipzig, 29 mit Dresden usw. in der
opengeodb. Ohne genaue Kenntnis, auf welche locid sich deine 17 Zeilen
beziehen, hilft mir deine Aussage nicht viel weiter.

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