[PostNAS] gml_id in Länge 16 oder 32

["Jäger, Frank (KRZ)"]

Hallo,
PostNAS kann sich aus den zu konvertierenden NAS-Daten selbst die Struktur der Zieldatenbank generieren. 

Das Ergebnis ist dann aber jedesmal unterschiedlich, anhängig von den aktuellen Dateninhalten.
Felder werden eventuell zu klein angelegt, es gibt keine Indices.

Für die auswertenden Programme wäre es zudem tragisch, wenn ab und zu bestimmte Tabellen gar nicht vorhanden sind statt einfach nur leer. Das würde zu Abbrüchen führen.

Ich habe daher ein SQL-Datenbankschema zusammen getragen, das mir meine Datenbanken vollständig generiert, bevor ich sie lade.
Dies stammt im wesendlichen aus Probemigrationen der Musterdaten RLP (Mustermonzel) ergänzt um Probemigrationen lokaler Daten (NRW). Es wurden immer Erstabgaben verwendet.

Es ist eine andauernde Fleißarbeit, diese Schema zu korrigieren und zu optimieren.

Die Fortführung/Auskunft arbeitet noch nicht fehlerfrei. Zwei aktuelle Probleme:

1.
Nach der zweiten monatlichen Fortführung eines Stadtgebietes hat ein GB-Blatt keinen Eigentümer mehr.
Die Relation "benennt" zwischen "Namensnummer" und "Person" ist nicht mehr da.

2.
Der Eigentümer des gleichen GB-Blattes (die Stadt) hat vor der Fortführung zwei Adressen. Die sind fast identisch, nur einmal ist "*straße" ausgeschieben und einmal mit "*str." abgekürzt.
Ich denke, das ist eine Korrektur gewesen. Die alte Version müsste eigentlich verschwinden.

Um die Buchauskunft so anzupassen, dass die alte Version der Adresse nicht mehr angezeigt wird, suche ich nach dem Feld, das mit anzeigt, dass die Adresse nicht mehr aktuell ist. Ich sehe aber keins  :-(
Beide Adressen scheinen gleichwertig mit Person verbunden zu sein.

Ich habe dann die Fortführungs-NAS-Daten mal so konvertiert, als wenn sie eine Erstabgabe wären und vorher keine Tabellen angelegt. Ich wollte mal schauen, welche Struktur dann daraus generiert wird.

Ergebnis: Das wichtige Feld "gml_id" mit dem z.B. die Buchwerks-Relationen verknüpft sind, hatte ich nach den o.g. Probemigrationen so interpretiert, dass es immer genau 16 Zeichen enthält.
Ich hatte es also mit "character(16)" angelegt (fix, nicht varying).

Aus der Fortführung sind nun auch Inhalte in "gml_id" mit 32 Zeichen Länge generiert worden.
Der ursprünglichen gml_id sind offensichtlich Datum und Zeit angehängt worden.

Könnte das ein Hinweis sein, auf einen "Untergang"? (historisch)
Werden ggf. mit gml_id in Länge 32 die Relationen korrekt fortgeführt? (die 2 Probleme oben)

Ich werde das testen mit einem angepassten Schema. Dazu muss ich aber den kommunalen Bestand komplett neu aufbauen, was eine Weile dauert.

Das ATKIS-Schema (nicht a*L*kis) "RP" im SVN verwendet auch 16stellige GML-Ids. Aber bei ATKIS spielt Buchwerk keine Rolle, oder?

Kann jemand was zu den gml_ids sagen und wie die Erweiterung mit Datum zu interpretieren ist?


PS
Ich bin dabei, die Buchauskunft um die Flurstücks-Historie zu erweitern. Auch dabei sind die Datenbank-Strukturen nicht optimal. Es gibt z.B. keine Verweise von einem aktuellen Flurstück auf seine Vorgänger.


Mit freundlichen Grüßen
Frank Jäger