[PostNAS] Antw: Re: Datentyp "Zeitpunktderentstehung"?

[Karsten Bleßmann]

Hallo,

hab an folgenden Stellen in der alkis_PostNAS_schema.sql die
Vereinbarungen für den "Zeitpunktderentstehung" auf varchar gesetzt:

554
571
638
1037
1153
1572

(simples Suchen ... und dann editiert) ... 

Import läuft jetzt ohne Warnungen bzgl. "Zeitpunktderentstehung" durch
aber es kommen noch Warnungen bzgl. der Postleitzahl :

Warning 1: Value '5610 ' of field
AX_Anschrift.postleitzahlPostzustellung parsed incompletely to integer
5610

Überall da, wo es vierstellige Postleitzahlen gibt (entweder alte oder
welche aus Österreich  ...?)

Seltsamerweise ist die "postleitzahlPostzustellung" aber auf varchar
gesetzt: (Zeile 1710!)

CREATE TABLE ax_anschrift (
	ogc_fid				serial NOT NULL,
...
1710:	postleitzahlpostzustellung	varchar,
	strasse				varchar,
	hausnummer			varchar, -- integer
...

wird die ax_anschrift noch irgendwo anders vereinbart???

Beste Grüße
KBL


>>> Jäger, Frank (KRZ)<F.Jaeger at KRZ.DE> schrieb am 28.01.2014 um 18:18
in Nachricht
<F2176AE4E9FFAF45BEA8D84DD6F4AF1A0C3E8E08 at skrzmxmbx02>:
> Hallo,
> das Feld "ZeitpunktDerEntstehung" wird - glaube ich - nirgendwo
benutzt.
> Die wenigen Einträge im Schema sind Relikte aus der Anfangszeit, als
das 
> Schema iterativ erarbeitet wurde.
> (Probekonvertierung in leere DB, dann die von PostNAS angelegten
Formate ins 
> Schema übertragen, ggf. Feldlänge erweitert, Kommentare hinzugefügt,
... 
> usw.).
> 
> In unseren NRW-Datenbanken sieht das derzeit so aus:
> 
> ax_flurstueck, character(10), gefüllt mit jjjj-mm-tt, abgeschnitten?
> ax_grenzpunkt, integer, Inhalt leer, aber keine Warnungen
> ax_historischesflurstueck**, Keine Objekte geladen
> 
> 
> Eine Methode, die Warnungen los zu werden, ist möglicherweise, dies
Feld in 
> ax_grenzpunkt zu löschen, also im SQL-Schema auszukommentieren. 
> Dann wird der Konverter es ignorieren.
> 
> Im Character-Format scheint das Befüllen ja zu funktionieren
(ax_flurstueck). 
> Eventuell sollte man das Feld noch verlängern und/oder als "character

> varying" anlegen, dann passt auch die Zeit noch hinein.
> 
> Um damit etwas anzufangen, z.B. in SQL-Vergleichs-Operationen, wäre
ein 
> Datenbank-Zeit-Format wahrscheinlich sinnvoll.
> Dazu müsste man einige Versuche starten.
> 
> Wie sie schon sagen, dauert das manchmal eine Weile. Und weil niemand
das 
> Feld bisher benötigt hat, hat sich noch niemand die Zeit dazu
genommen.
> 
> Wenn es dazu neue Erkenntnisse gibt, dann her damit. Dann baue ich
das in's 
> Schema ein.
> 
> Wenn aber niemand das Feld braucht, können wie das im Schema auch
komplett 
> auskommentieren um die Datenbank von unnötigen Daten zu entlasten.
> 
> PS
>   Generell habe ich den Eindruck, dass in den letzten Wochen etwas
Leben 
> in's PostNAS-Projekt kommt.
> Zwischenzeitlich war es doch sehr ruhig geworden ...
> 
> Mfg
> F. Jäger
> 
> 
>> -----Ursprüngliche Nachricht-----
>> Von: nas-bounces at lists.osgeo.org
[mailto:nas-bounces at lists.osgeo.org] Im
>> Auftrag von Karsten Bleßmann
>> Gesendet: Dienstag, 28. Januar 2014 17:32
>> An: nas at lists.osgeo.org 
>> Betreff: [PostNAS] Datentyp "Zeitpunktderentstehung"?
> 
> ...
> 
>> 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.
>> 
> 
> ...
> 
>> 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