RE: [NAS] Neue Version steht vor der Tür

[Jäger, Frank (KRZ)]

> -----Original Message-----
> From: nas-bounces at lists.osgeo.org 
> [mailto:nas-bounces at lists.osgeo.org] On Behalf Of Olaf Knopp
> Sent: Thursday, November 26, 2009 12:11 PM
> To: Entwicklung einer NAS Schnittstelle
> Subject: [NAS] Neue Version steht vor der Tür
...
> eine gute Nachricht: Die neue Version von PostNAS steht vor der Tür. 
> Frank Warmerdam hat die Erzeugung des kompletten 
> ALKIS-Schemas beim NAS-Import umgesetzt.
...
> 
> Als nächstes ist das NBA-Verfahren an der Reihe.
 ...
> Danke im voraus.
> Olaf Knopp
> 
> --


Hallo,
ich teste gerade die neue Version - ich habe sie mal fortlaufed 0.5 genannt - und will hier mal erste Erfahrungen berichten:

Ich habe gdal 1.7 und PostNAS als Quelle geladen und zusammen compiliert (07.12.2009).
System: Debian-Linux.
Datenbank: PostgreSQL 8.1.19/PostGIS 1.1
Ich verwende NAS-Daten des Kreises Lippe (NRW), GID 5.1.1.

Der Konverter legt sich das Datenbankschema selbst an, macht dabei aber einige Fehler.
Ich habe daher iterativ ein SQL-Schema erarbeitet mit dem ich vorab die Datenbank anlege.

Der Konverter legt alle Tabellen pauschal mit Geometriefeld und gist-Index an, auch solche, die keine Geometrie enthalten, z.B. aus dem Buchwerk. Man möchte also auf 'AddGeometryColumn' verzichten.
Dann ist die Tabelle aber nicht in der Metatabelle 'geometry_columns' verzeichnet.
Dann versucht der Konverter sie nochmal anzulegen.
Lösung: Dummy-Eintrag in 'geometry_columns', dann verwender der Konverter die vorhandene Tabelle auch ohne Geometriefeld.

Der Konverter verwendet verschiedene Geometrietypen je Tabelle. Er legt z.B. POLYGON an und versucht dann POINT darin zu speichern.
Lösung: Nach 'AddGeometryColumn' den Constraint manuell wieder löschen:
  ALTER TABLE [tabelle] DROP CONSTRAINT enforce_geotype_wkb_geometry;
Der Konverter schimpft dann immer noch (Warning), macht aber weiter.
Möglicherweise macht der Geometrie-Mix die spätere Auswertung schwierig.
Vorschlag zur Weiterentwicklung: Wenn ein Geometriefeld als MULTIPOLYGON angelegt ist und ein POLYGON darin gespeichert werden soll, dann könnte man auch eine zusätzliche Klammer um die Koordinaten machen und dann hat man formal ein MULTIPOLYGON mit einem Element.

Einige Felder werden zu klein angelegt. Die notwendige Feldlänge wird durch Analyse der Daten ermittelt. Entweder werden zu wenige Vorkommen analysiert oder es liegt daran, dass der zu ladende Bestand "gekachelt" ist und in der ersten Datei zufällig nur kurze Texte vorkommen. Ist das Feld zu klein, werden die Inhalte abgeschnitten. Eine Warnung wäre angebracht.

In der Datenbank fehlende Felder werden nicht gemeldet. Auch hier dürfte der Konverter ruhig Warnungen ausgeben.
Z.B. sind direkt nach der Umstellung ALK->ALKIS noch einige Elemente leer, die vielleicht später noch gefüllt werden.
Das werden wir nicht merken, wenn die Daten stillschweigend weggeworfen werden.

Das Feld "beginnt", das in jeder Tabelle vorkommt, enthält offensichtlich einen 'Timestamp' (Datum und Uhrzeit).
Es wird aber im Format 'character(20)' angelegt.
Ändert man das Feldformat auf timestamp (z.B. um damit rechnen zu können) dann lässt der Konverter es leer.
Legt man ein neues Feld als Timestamp an, kann man den Inhalt übertragen. Der Inhalt ist also formal gültig.

Das Feld "ax_flurstueck.rechtsbehelfsverfahren character(5)" enthält durchgängig den Wert 'false'.
Ändert man das Feldformat auf boolean, meldet der Konverter:
 ERROR:  column "rechtsbehelfsverfahren" is of type boolean but expression is of type integer
Aha, 'false' ist also ein Integer-Wert. Ich werde es mal mit integer versuchen ..


** NBA-Fortführung:

> Als nächstes ist das NBA-Verfahren an der Reihe

Entgegen der Aussage scheint die Aktualisierung tatsächlich schon zu funktionieren:
   /opt/gdal-1.7/bin/ogr2ogr -f "PostgreSQL" -append -update -skipfailures   ....

.. schluckt die Aktualisierungsdaten. Allerdings muss ich das Ergebnis noch prüfen.
Doch auch hier ein Vorschlag zur Weiterentwicklung:
Das NBA-Verfahren liefert auch Kacheln, in denen sich nichts geändert hat. Die xml-Datei ist nicht "leer" sondern enthält einen Header, aber eben keine geänderten Objekte.
Solche Dateien erzeugen eine Meldung (ogr2ogr listet alle seine Schnittstellen auf und behauptet, solche Daten nicht zu kennen) und setzt einen Exitcode 1 statt 0.
Wenn man mit dem Exitcode die Stapelverarbeitung steuern möchte (Abbruch bei Fehler), dann muss man solche Dateien vorher manuell aussortieren.
Da das eine normale NAS-Datei ist, sollte das nicht als Fehler aufgebauscht werden sondern kann mit der Warnung "keine Änderungen" abgehandelt werden.


** Beziehungen

Es gibt nun eine zentrale Multi-Verbindungstabelle "alkis_beziehungen" die alle möglichen anderen Tabellen über ihre jeweilige 'gml_id' verbindet.
Zur Darstellung einer Hausnummer muss man z.B. das Geometriefeld aus "ap_pto" mit dem Label aus "ax_lagebezeichnungmithausnummer" über die Tabelle "alkis_beziehungen" Joinen.
  WHERE ap_pto.art = 'HNR' AND alkis_beziehungen.beziehungsart = 'dientZurDarstellungVon';
Das klingt nicht sehr performant. Es muss wohl auch noch für jede denkbare Art von Beziehung ein View gebastelt werden.

Sollte man nicht (bei 1:N) die Tabellen direkt miteinander verlinken oder (bei N:N) jeweils 2 Tabellen über eine spezielle Verbindungstabelle. Foreign-Key-Contraints könnten die Integrität sichern.
Ein "zentrale" Verbindungstabelle, die für alle Joins in der Datenbank zuständig ist, ist mir suspekt.


** Laufzeit

Die NAS-Konvertierung dauert deutlich länger als die Konvertierung von EDBS des gleichen Gebietes.


** Kommunikation

Gibt es einen Bug-Tracker, in den ich meine "Vorschläge" eintragen kann damit sie den Entwickler erreichen? (GDAL-Projekt?)



Mit freundlichen Grüßen
Frank Jäger

KRZ Mi.-Ra./Li.