[opengeodb] SQL-Script für hierarchies

Peter Wendorff wendorff at uni-paderborn.de
Die Apr 8 09:15:25 CEST 2008


Peter Wendorff schrieb:
> Weiter im Text, nachdem der erste Teil offensichtlich gelöst ist.
>
> Stand der Dinge also:
> - zu jeder loc_id existiert ein Datensatz in meiner erzeugten 
> hierarchies-Tabelle.
> - lvl1 ist jeweils auf -1 gesetzt (später hier NULL, aber im Moment 
> bleibe ich noch bei der alten Tabellendefinition)
> - das Feld level ist gesetzt entsprechend dem entsprechenden Wert aus 
> text_data
> - das zu level passende Feld id_lvl? (wobei ? eben durch den Wert von 
> level im Bereich von [1..9] zu ersetzen ist) ist entsprechend korrekt 
> gesetzt.
>
> Mein nächster Schritt ist, die Parents zu finden, die auf level 8 liegen 
> und entsprechend einen Nachfahren haben, der in der locations auf level 
> 9 sitzt.
> Also:
> [...]
>   
Hab das nochmal neu gebastelt, und komme auf die folgende Funktion, die 
mir immerhin einen Datensatz (loc_id 80627) korrekt setzt (und keinen 
falsch - auch ein Vorteil):

UPDATE geodb_hierarchies,
    geodb_textdata AS partOf,
    geodb_textdata AS isLevel
SET id_lvl8 = isLevel.loc_id
WHERE 1
AND partOf.loc_id = geodb_hierarchies.loc_id
AND geodb_hierarchies.level = 9
AND partOf.text_type = "400100000"
AND isLevel.loc_id = partOf.text_val
AND isLevel.text_type = "400200000"
AND isLevel.text_val = "8";


Dabei sind alle anderen Datensätze, die in meiner geodb vorhanden sind, 
auf fa-technik.adfc.de als gelöscht markiert, in meiner Datenbank aber 
eben noch vorhanden (s. Mail von gestern: mein Dump ist von gestern 
Abend, 20:00 Uhr) -> Martin???.

Ein Problem war offensichtlich das der Typen, also: die Ganzzahlen 
gehören in geodb_intdata - das sollte bald geändert werden (Ebene, Teil 
von, Einwohnerzahl, ungef. EWZ, Genaue EWZ, Höhenangabe (?), max. Höhe, 
min Höhe, durchschn. Höhe, Höhe an Ref.Pkt, Höhe an angeg. Koord.)

Meine Vorlesung geht jetzt los, ich bin also erstmal beschäftigt.

Gruß
Peter