[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