[NAS] Lebt PostNAS noch?

[Jäger, Frank (KRZ)]

Hallo!

> -----Original Message-----
> From: nas-bounces at lists.osgeo.org 
> [mailto:nas-bounces at lists.osgeo.org] On Behalf Of krueger roland
> Sent: Friday, October 23, 2009 10:20 AM
> To: nas at lists.osgeo.org
> Subject: AW: [NAS] Lebt PostNAS noch?
> 
> Hallo Liste,
> 
> Mich interessiert auch wie der Stand bezüglich PostNAS ist 
> und wie es weitergeht.
> 
> Im Bundesland Brandenburg wird ALKIS im zweiten Halbjahr 2010 
> eingeführt. Ende 2010, Anfang 2011 werden also alle 
> potentiellen NAS-Nutzer in Brandenburg eine Schnittstelle 
> benötigen. 


Eigentlich doch schon eher, oder?
Man sollte sich vor der Umstellung darauf vorbereiten, damit man zum Zeitpunkt der Umstellung einsatzbereit ist.


... 
> Die Testdaten enthalten einen Bestandsdatenauszug und ein 
> NBA-Verfahren mit Erst- und Folgeabgabe.
> Gibt es schon Erfahrungen mit den Brandenburger Testdaten und PostNAS?
> 
> Mit freundlichen Grüßen
> Roland Krüger
> 
> Landkreis Ostprignitz-Ruppin
>


Mit Brandenburger Daten habe ich noch nicht getestet, nur mit NRW.
Die im März '09 ausgelieferte PostNAS 0.4 kann *keine* NBA-Daten verarbeiten.

Ich habe die Erfahrung gemacht, dass es ein großer Unterschied ist, ob man ein Testgebiet (Musterkarte o.ä.) konvertiert, oder ein komplettes Stadtgebiet. 

Der wesentliche Unterschied ist: Wegen der großen Datenmenge muss ein Stadtgebiet "gekachelt" ausgeliefert werden.
Warum das ein Problem ist, werde ich erläutern.

Durch die Integration von PostNAS in GDAL/OGR wird dessen "Verarbeitungslogik" übernommen.
Es ist an sich eine komfortable Funktion des Konverters, dass man sich nicht um das "Datendesign" des Zielformates kümmern muss. Man wirft dem "ogr2ogr" z.B. ein Shapefile für die Konvertierung nach PostGIS vor.
Die Struktur des Quellformates wird analysiert, z.B.: eine Liniengeometrie, ein Text- und ein Integer-Datenfeld.
Dann legt ogr2ogr automatisch die passende Tabelle in PostGIS an: Textfeld, Integerfeld und ein Geometriefeld mit dem Constraint "Liniengeometrie".

Die gleiche komfortable Automatik funktioniert auch bei der Konvertierung einer "Musterkarte" im NAS-Format nach PostGIS.
Es wird DIE Struktur angelegt, die für DIESEN Musterbestand benötigt wird.

Das Konzept scheitert aber bei großen gekachelten Beständen. Für den Konverter ist die ERSTE Kachel DER Bestand, der das Datenbankdesign des Zielformates bestimmt. Alle weiteren Kacheln sind Erweiterungen (-append) der Daten, die aber nichts mehr am Design ändern.

NAS hat (in den mir vorliegenden Daten) die Eigenschaft, dass in einer Kachel nur solche XML-Strukturen enthalten sind, die in dem abgedeckten Bereich tatsächlich vorkommen. Die "ersten" Kacheln (bei Sortierung nach Dateiname) haben zudem Randlage und enthalten also meist Wald oder landwirtschafliches Gebiet. Sobald dann eine Kachel auch Gebäudedaten liefert, fehlt die aufnehmende Tabelle dafür.

Meine Lösung: in einem iterativen Prozess habe ich verschiedene Kacheln jeweils "als erstes" verarbeitet. Die automatisch generierten Datenbankstrukturen habe ich gesammlt. Es werden nicht nur verschiedene Tabellen nach Bedarf angelegt, auch die maximale Feldlänge von Textfeldern wird durch die praktische Analyse bestimmt, nicht durch theoretische Vorschriften.

Durch manuelle Synthese der einzelnen DB-Schmata habe ich für meinen Bereich ein Datenbankschema erarbeitet, in das ich alle mir derzeit vorliegenden Kacheln einlesen kann.
Mit dem Schema lege ich die Datenbank an. Die erste Kachel wird dann bereits mit "-append" in die leere Datenbank eingetragen.

Sollten spätere Lieferungen längere Texte oder neue Objektarten enthalten, wird die Konvertierung abbrechen und das Schema muss zunächst nachgebessert werden.
Beim Einsatz in anderen Regionen wird es notwendig werden, weitere Tabellen einzupflegen: Weinberg, Tagebau, Hafen,  ...?

Für die gemeinsame Weiterentwickling von Views, Reports, Auskunfts-Programmen usw. wäre es wünschenswert, ein "MAX-D"-Datenbankschema zusammen zu tragen, das alle vorkommenden Inhalte aufnehmen kann.

Die beschriebene Generierung der Strukturen aus praktischen Daten macht den Konverter vermutlich relativ unempfindlich gegen verschiedenen Release-Stände. Es könnte sein, dass neue NAS-Relaese sogar ohne Umprogrammierung verarbeitet werden können.

Wegen der NAS-Besonderheit "gekachelte Abgabe" (Bereits der "Erstbestand" besteht aus mehreren Dateien) wäre aber eine andere Strategie notwendig:
A) Dynamisches Hinzufügen von Tabellen und 
   dynamisches Erweitern von Textfeldern 
 oder
B) Gesamt-Analyse eines Erstabgabe-Kachel-Satzes für die Festlegung des DB-Designs



Mit freundlichen Grüßen
F. Jäger