RE: [PostNAS] gml_id in Länge 16 oder 32

"Jäger, Frank (KRZ)" F.Jaeger at KRZ.DE
Fre Nov 4 07:10:21 EDT 2011


Hallo,


> -----Original Message-----
> From: Ralf Suhr [mailto:Ralf.Suhr at itc-halle.de] 
> Sent: Friday, November 04, 2011 11:31 AM
> To: NAS Schnittstelle via ogr2ogr
> Cc: Jäger, Frank (KRZ)
> Subject: Re: [PostNAS] gml_id in Länge 16 oder 32
> 
> Hallo Herr Jäger,
> 
> die überlangen gml_ids stammen aus einer NBA.


Ja, ich kam ja drauf, weil ich zur Probe mal die Aktualisierung statt der Erstabgabe ohne Schema konvertiert habe.


> Die erweiterten Angaben sind meist mit dem Zeitpunkt identisch, ab dem das 
> neue Objekt gültig sein soll. 

Da wir den Sekundärbestand nur monatlich bekommen liegt das mit ziemlicher Sicherheit in der Vergangenheit.
Es käme mir weniger darauf an, den Untergangs-Zeitpunkt historischer Objekte rekonstruieren zu können.

Vielmehr möchte ich den *aktuellen Bestand korrekt darstellen*:

- als WMS
- für Navigation
- als Buchauskunft


> Die ersten 16 Stellen der gml_id sind identisch mit dem 
> Vorgängerobjekt.
> 

Das wurde durch die Felddefinition bisher so zurecht gestutzt.


> Ich kürze die gml_id immer auf 16 Stellen und speichere die 
> letzten 16 Stellen im Vorgängerobjekt als Endzeitpunkt der Gültigkeit.

Wenn man das *nicht* macht, sondern es so lässt, wie PostNAS es einträgt, 
passen dann die Verbindungen über "alkis_beziehungen" z.B.?

Wenn man es machen MUSS, um nach einer Aktualisierung wieder korrekte aktuelle Beziehungen zu haben:

 1. Warum macht es nicht der Konverter, Fehler?

 2. Wenn man es als Nachprozessierung zum Konverter tun muss:
    - Wie machen sie das? 
    - Können sie ihren Code dazu im SVN zur Verfügung stellen?


Mit freundlichen Grüßen
F. Jäger


> MfG
> Ralf Suhr
> 
> On Freitag 04 November 2011 11:15:31 Jäger, Frank (KRZ) wrote:
> > Kann jemand was zu den gml_ids sagen und wie die 
> Erweiterung mit Datum 
> > zu interpretieren ist?
>