[PostNAS] [PM] PostNAS 0.8 - Fehlersuche

[Jäger, Frank (KRZ)]

> -----Ursprüngliche Nachricht-----
> Von: nas-bounces at lists.osgeo.org [mailto:nas-bounces at lists.osgeo.org] Im
> Auftrag von Jürgen E. Fischer
> Gesendet: Montag, 15. September 2014 18:31
> An: NAS Schnittstelle via ogr2ogr
> Betreff: Re: [PostNAS] PostNAS 0.8 - Datenbank-Schema
> 
...
> 
> ....   Wir haben allerdings auch kaum Fortführungen



Hallo Jürgen,
in Niedersachsen steckt das NBA-Verfahren wohl noch in den Anfängen, aber bei uns ist das eigentlich schon der Normalfall.

Die Daten des Katasteramtes Minden-Lübbecke aus unserem Verbandsgebiet werden doch im Auftrag der Wasserverbände "Große Aue" und "Weserniederung" durch Norbit konvertiert.
Oder irre ich mich da?  Machen die Wasserverbände die Konvertierung inzwischen selbstständig?

Ich höre da irgendwie nie etwas davon.
Als die NBA-Verfahren neu aufgesetzt wurden, habe ich euch benachrichtigt; keine Antwort.

Für die unten folgende Frage habe ich mal die Daten auf dem Filetransfer-Server für Minden abgeglichen. Ich habe festgestellt, dass von den wöchentlichen Lieferungen für Minden 2 Abgaben gefehlt haben.
Wieso beschwert sich da niemand? Merkt das keiner?

Die nächtliche Verarbeitung auf den ibR-David-Servern läuft unzuverlässig. Es kommt oft vor, dass wir das morgens manuell nachholen müssen.
Einer der letzten Schritte in der Verarbeitungsreihenfolge ist die (kaskadierende) Abgabe der NBA-Verfahren.
Kaskadierend ist das, weil die NBA-Verfahren für weitere Kunden nicht aus der primären DHK abgegeben werden sondern aus der sekundären DHK.
Die primäre DHK wird nur für die EQKs also die Fortführungen benutzt. Die ändert sich also ständig. Nachts wird das per NBA in die sekundäre DHK synchronisiert.
Daraus wird tagesaktuell aber im Laufe des Tages nicht veränderlich die Auskunft betrieben. Auch die Kacheln für die Karte werden daraus  generiert.

Die NBAs für Gemeinden, Land und das Kreis-GIS werden alle aus der sekundären DHK geholt (NBA vom NBA, daher kaskadierend).

Der nächtlich Workflow kopiert das nicht nur in den Ordner der Gemeinde auf dem FT-Server (File-Transfer) sondern auch in den Ordner des Wasserverbandes. Darauf hat Norbit eine Leseberechtigung. 
Beim manuellen Nachverarbeiten des nächtlichen Workflow wurde offensichtlich 2mal vergessen, die Daten für Minden auch in den Ordner des Wasserverbandes zu kopieren.
Das habe ich gerade nachgeholt.

Minden bekommt wöchentlich, andere Gemeinden bekommen monatlich

Alle Gemeinden bekommen bei uns die Abgabeart 1000.
Nur Minden bekommt auf eigenen Wunsch die Abgabeart 3100 (Vollhistorie).

Bei der letzten Erstabgabe, die nach dem Server-Umzug notwendig war, wurde auf Anraten von ibR die Erstabgabe auf 1950 zurück datiert um auch wirklich ALLE historischen Objekte zu bekommen. Die Erstabgabe enthält also noch keine Objekte. Die sind alle in der ersten Aktualisierung.


Doch nun zu meinem eigentlichen Anliegen.

Für Minden und ein paar andere Gemeinden können wir also auf die gleichen Daten zugreifen. Das ist eine gute Basis um bei der Fehlersuche gezielt einzelne verdächtige Objekte zu benennen.
Ich habe Minden mit der Struktur PostNAS 0.8 und dem Historie-Trigger konvertiert. Der Kill-Trigger kann die Updates aus Abgabeart 3100 ja nicht vertragen.

Nun habe ich über den View "fehler_hausnummer_mehrfach_verwendet" einige Redundanzen gefunden. Es gibt Gebäude und auch Flurstücke zu den u.a. Adressen, die mehrfach enthalten und nicht beendet sind.
Die gml_id ist in den ersten 16 Stellen jeweils identisch, der angehängte Timestamp unterscheidet sich jedoch.

Ich denke bei dem jeweils älteren Objekt fehlt der endet-Eintrag. Ist das ein Fehler im Trigger?

Da wir die gleichen Daten zur Verfügung haben, möchte ich dich bitten, mal in deinem Bestand nachzuschauen, ob dort der gleiche Fehler auftritt.
Die redundanten Gebäude sind zu finden unter folgenden Adressen in Minden:

Bismarckstraße 21, 23. 25, 27, 29
Fasanenstraße 9
Gelindeweg 6a, 36
Hahler Straße 222, 224, 226
Hardenbergstraße 29, 32
Martinikirchhof 5
Moltkestraße 2
Ringstraße 64, 66, 66a, 68, 68a
Robert-Koch-Straße 4
Denkmalstraße 4, 6, 8


Das habe ich gesucht mit:

CREATE OR REPLACE VIEW fehler_hausnummer_mehrfach_verwendet 
AS 
 SELECT l.gml_id, l.gemeinde, l.lage, l.hausnummer,
        count(g.gml_id) AS anzahl_gebaaeude
   FROM ax_gebaeude g
   JOIN ax_lagebezeichnungmithausnummer l 
     ON "substring"(l.gml_id::text, 1, 16) = ANY (g.zeigtauf::text[])
  WHERE g.endet IS NULL AND l.endet IS NULL
  GROUP BY l.gml_id, l.gemeinde, l.lage, l.hausnummer
 HAVING count(g.gml_id) > 1;

CREATE OR REPLACE VIEW fehler_gebaeude_zu_mehrfach_hsnr 
AS 
  SELECT f.gemeinde, f.lage, k.bezeichnung, f.hausnummer,
         g.gml_id, g.beginnt
  FROM ax_gebaeude g
  JOIN fehler_hausnummer_mehrfach_verwendet f
    ON substring(f.gml_id::text, 1, 16) = ANY (g.zeigtauf)
  JOIN ax_lagebezeichnungkatalogeintrag k
    ON f.gemeinde=k.gemeinde AND f.lage=k.lage
    WHERE g.endet IS NULL
  ORDER BY f.gemeinde, f.lage, f.hausnummer, g.gml_id;

MfG
Frank
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 7599 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.osgeo.org/pipermail/nas/attachments/20140917/873b81ba/attachment.bin>