[PostNAS] Datentyp "Zeitpunktderentstehung"?

[Karsten Bleßmann]

Hallo allerseits,

bin seit ein paar Tagen dabei eine PostNAS-Installation für
Brandenburger NBA-Daten einzurichten. Eckdaten: Ubuntu 12.04, Server,
Postgres 9.1, gdal selber compiliert ... etc. NBA-Daten mit
Voll-Historie (also Erstabgabe und dann Updates ...)

- hab den Trunk gezogen und die Scripts wie vorgesehen eingerichtet
(OSUser=DBUser, DB anlegen mittels der Scripte etc.)
- nix *hist ... sondern *kill, war so voreingerichtet (Die
Historisierung probier ich mal aus, wenn ich Zeit hab ...)
- soweit wie es ging nix geändert ... ausser:
- Änderungen: Replace 25832 | 25833 in allen Files (auf der Shell)
- konv_batch so umgebaut, dass *.gz-Files verarbeitet werden:

schnipp --> 
  for zipfile in *.gz ; do 
    	echo " "
    	rm ../temp/*.xml
    	echo "*********"
   	echo "* Archiv: " $zipfile
	cp ${zipfile} ../temp
    	gunzip ../temp/${zipfile}  
    	# Es sollte nur ein XML-File in jedem ZIP-File stecken, aber es
geht auch anders.
    	for nasdatei in ../temp/*.xml ; do 
<--- schnapp

Ergebnisse:
- Ersteinrichtung klappte (also die leere Datenbank zusammenbauen)

folgendes Problem:

- Einlesen liefert tausende Warnungen in der Art:

Warning 1: Value '2001-01-01, 12:00:00' of field
ax_grenzpunkt.zeitpunktderentstehung parsed incompletely to integer
2001.

Soweit wie es aussieht gibts keine Fehler ... (der bricht aber bei 1000
das Protokoll ab)

Lustigerweise gibt es reihenweise zeitpunktderentstehung = INTEGER ...
ist so in der alkis_PostNAS_schema.sql vereinbart, aber seltsamerweise
nicht bei allen Objekten (???)

z.B:

CREATE TABLE ax_grenzpunkt (
	ogc_fid					serial NOT NULL,
	gml_id					character(16),
... blah blah  ...
	name					varchar[],
	zeitpunktderentstehung	integer,
	relativehoehe			double precision,
	CONSTRAINT ax_grenzpunkt_pk PRIMARY KEY (ogc_fid)
);

Das Einlesen läuft noch (blöderweise braucht das ja immer gleich ein
paar Stunden ...)

Frage: 
- Kann ich die Warnings ignorieren? 
- Warum sind teils "zeitpunktderentstehung" mal als varchar, mal als
varchar[10] und mal als Integer vereinbart??
- macht es Sinn, die Typen zu ändern? oder fliegen einem dann die Daten
bei den weiteren Schritten um die Ohren?

Bedanke mich jetzt schon!

Beste Grüße
KBL