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?
>