[PostNAS] Kachelweise fehlende Gebäude

Jäger, Frank (KRZ) F.Jaeger at KRZ.DE
Mi Dez 11 09:27:41 PST 2013


Hallo,
der Fehler wurde weiter eingekreist. Ich bin SO vorgegangen:

Ich habe die Trigger-Function "update_fields_beziehungen()" mit einer Fehlerbehandlung versehen.
Wenn der erste UNION über alle Tabellen die "gml_id" keiner Tabelle zuordnen kann und NULL liefert, dann wird auf das Einfügen von "von_typename" und "beginnt" verzichtet. Der vor dem Einfügen notwendige SELECT mit einem NULL-Inhalt war das, was die Protokoll-Meldung erzeugt hat.
Man erhält also nun Zeilen in der Tabelle "alkis_beziehungen", in denen diese Felder leer bleiben, daran kann man die betroffen Fälle ermitteln.
Aber es wird wenigstens eine Zeile eingefügt. Vorher brach das Einfügen ab.

Nebenbei: Die zweite Monster-Union habe ich auskommentiert. Das Ergebnis ist davon abhängig, ob der Beziehungs-Partner zu dem Zeitpunkt schon geladen wurde, ist also nicht vollständig. Man kann also nix damit anfangen. Die Konvertierung wird ohne dies UNION-Select schneller.

Mit der neuen Trigger-Function habe ich die ganze Stadt neu geladen. Ich hatte die zarte Hoffnung, dass der "Domino-Effekt" ausbleibt und nur die wirklichen Problemfälle nachher fehlen. Ich wurde bitter enttäuscht! Es fehlen immer noch 1042 Gebäude, was man nun aber einfach ermitteln kann. 

Durch Vergleich der "alkis_beziehungen" mit leerem "beginnt" kann man sehen, dass die Zeilen in "ax_gebaeude" zu den 1042 Objekten komplett fehlen.

Die Analyse einiger fehlender Gebäude durch mich und das Katasteramt verlief negativ, alles unauffällige Teile. Das war nicht zielführend.
Anders ausgedrückt: Die werden nicht konvertiert, obwohl sie fehlerfrei sind.

Ich hatte da einen Verdacht ...
Mit meinen Helfern "bash", "grep" und "sed" habe ich analysiert, welches "ax_gebaeude" in welcher Zeile der betroffenen 8 NAS-Dateien steht und diese Information mit in die Datenbank geladen. Durch Abgleich mit "ax_gebaeude" war eindeutig nachzuweisen, dass alle Gebäude bis zu einer Stelle in der Datei geladen wurden und alle "ax_gebauede" danach jeweils fehlten.
Dann habe ich mir das jeweils erste fehlende Gebäude-Objekt dazu angesehen. Als Gemeinsamkeit fiel mir auf, dass diese Gebäude jeweils ein "gml:CompositeCurve" enthalten.

Daraus folgt die neue Arbeitshypothese:

- "gml:CompositeCurve" kann PostNAS nicht vertragen
- Dies erzeugt die Meldung ''Invalid exterior ring"
- Dann passiert etwas, was nach meiner Einschätzung ein grober Programmfehler sein muss:
  Es wird bis zum Ende der Datei kein weiteres Objekt der gleichen Objektart/Layer (ax_gebaude) mehr verarbeitet, obwohl die folgenden Objekte wieder eine verträgliche Geometrie haben. So kommen die "fast leeren Kacheln" zustande. Es sind darin nur die Gebäude enthalten, die in der NAS-Datei vor der "gml:CompositeCurve" gestanden haben.

Dies müsste im PostNAS Quellcode gesucht oder als Bug an das GDAL-Projekt gemeldet werden.

Mfg
F. Jäger


> -----Ursprüngliche Nachricht-----
> Von: nas-bounces at lists.osgeo.org [mailto:nas-bounces at lists.osgeo.org] Im
> Auftrag von Jäger, Frank (KRZ)
> Gesendet: Montag, 9. Dezember 2013 18:47
> An: Mailingliste (nas at lists.osgeo.org)
> Betreff: [PostNAS] Kachelweise fehlende Gebäude
> 
> Hallo,
> mir macht derzeit ein Fehler zu schaffen, der hier in einer von 14 Gemeinden
> auftritt. Es gibt dort rechteckige Gebiete, in denen fast keine Gebäude
> vorhanden sind. Die rechteckigen Gebiete entsprechen jeweils dem Inhalt
> einer Datei des NBA-Verfahrens.
...

> Im Protokoll sieht das so aus:
> 
> Zunächst wird wenige Male gemeldet:  "Invalid exterior ring" - leider ohne
> Bezug auf ein konkretes Objekt oder die Art der Invalidität.
> 
> Sobald ein Objekt fehlt, scheitern das Einfügen andere Objekte. Es wird
> massenhaft protokolliert:
...
> Es sind immer die Beziehungsarten "zeigtAuf" und "hat" betroffen.
> 
> Die Trigger-Funktion hat die Aufgabe das Objekt einer Beziehung in vielen
> Tabellen zu suchen und den Namen der Tabelle in
> "alkis_beziehungen.von_typename" und "alkis_beziehungen.zu_typename"
> nachzutragen.
> 
> Es ist wohl eine Art Kettenreaktion. Wenn erst mal ein Objekt fehlt, dann
> passt nix mehr zusammen.
> Das - wegen dem  "Invalid exterior ring" ? - fehlende Objekt wird nicht
> gefunden, darum bricht die Function ab. Damit scheitert das Einfügen des
> Objektes selbst. Dadurch wieder andere ... ?
> Ein punktueller Fehler breitet sich so in der Fläche aus.
> 
> Mit Beginn der nächsten Kachel ist das meist vorbei, bis wieder so ein "Invalid
> exterior ring" kommt.
...
> 
> Mit freundlichen Grüßen
> Frank Jäger
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 7618 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.osgeo.org/pipermail/nas/attachments/20131211/3688b5b4/attachment.bin>


More information about the NAS mailing list