[PostNAS Suite] Anforderung mehrere Importe in einem Schema zu unterscheiden und Projekt-Bereiche mehrfach zu importieren

Mo Jun 17 00:51:28 PDT 2024

Hallo Frank, hallo Jürgen,

vielen Dank für eure Überlegungen zu dem Thema und Entschuldigung für 
die späte Antwort.

zur Frage: Was soll denn mit den in einem Schema gesammelten Daten 
passieren/möglich sein?
Es geht in dem Projekt vor allem um Eigentümerinformation zu Flurstücken 
und diese im Zeitraum von mehreren Jahren. Es soll transparent sein, wer 
der Eigentümer ist und ob sich Flurstücke verändert haben. Das Vorgehen 
via Fortführungsdatensätze ist aber nicht umsetzbar, weil die Daten 
nicht immer in dieser Form geliefert werden können.

Es geht um eine DSGVO-konforme Datenhaltung all der im Projekt bezogenen 
ALKIS-Eigentümer-Daten in einer Datenbank aus der heraus der jeweils 
aktuelle Stand und ggf. relevante Änderungen seit Erstbezug in eine 
Arbeitsdatenbank überführt werden sollen. Aus der ALKIS-DB soll ablesbar 
sein, in welchen Gebieten wann bereits Daten bezogen wurden.

> Dem könnte man auch noch aus dem Weg gehen, indem man das "endet" der
> "älternen" auf das "beginnt" des Nachfolgers setzt.
Dies wäre eine Lösung und auch die von dir beschriebene Suche via 
räumlicher Überschneidung.

> Bundesweit gibt es auch noch das Problem der unterschiedlichen
> Koordinatensysteme (EPSG:25832 vs EPSG:25833).
Ja das stimmt.

Alternativ könnte der Import in separate Datenbanken oder Schemata 
erfolgen. Der Import verschiedener Stände ist weiterhin eine 
Anforderung.

Viele Grüße

Astrid Emde

Am 2024-06-05 17:52, schrieb Jürgen E. Fischer via NAS:
> Moin Astrid,
> 
> On Wed, 05. Jun 2024 at 08:21:14 +0200, Astrid Emde (WhereGroup) via 
> NAS wrote:
>> Hintergrund: Es sollen Planungen für unterschiedliche, kleine Gebiete
>> (bundesweit) erfolgen. Dabei wird immer nur ein kleiner Bereich 
>> betrachtet.
>> Zu diesem Bereich werden im Abstand von einigen Monaten neue 
>> ALKIS-Daten
>> angefordert (nicht via Fortführung, sondern komplett) und ebenfalls
>> importiert. Die alten Stände sollen dabei erhalten bleiben. Die Stände
>> sollen via Zeit-/Datumsstempel oder ID unterscheidbar sein. So können
>> Änderungen verfolgt werden.
>> 
>> Das bisherige NorGIS ALKIS Import bietet bisher nicht die Möglichkeit, 
>> dies
>> umzusetzen, weil doppelte gml_ids-ignoriert werden oder zu Fehlern 
>> führen.
> 
> Jedes Objekt hat ohnehin schon seine Lebensdauer mit beginnt und endet. 
>  Bei
> den aktuellen Objekten ist nur noch das Ende offen.  Das "endet" 
> bekommte man
> normalerweise mit Replace oder Update bei Fortführungen.  Mehrere 
> Versionen
> eines Objekts mit gleichem gml_id ohne "endet" sollte es normalerweise 
> nicht
> geben.
> 
> Und Objekte mit dem gleichen "gml_id" und dem gleichen "beginnt" 
> sollten
> identisch sein.  Und nur die führen zu Fehlermeldungen.
> 
> Der Fehlermeldung dazu kann man allerdings mit "Duplikate ignorieren" 
> aus dem
> Wege gehen.  Identische Objekte sind somit erstmal kein Problem.
> 
> Das dient aber eigentlich nur dazu es zu ermöglichen unabhängige
> Einzellieferungen gleicher Aktualität importieren zu können.  Darin 
> gibt
> es normalerweise auch doppelte Datensätze, selbst wenn sich die 
> Bereiche nicht
> räumlich überschneiden (AX_Bundesland, Gemeinde, Personen uvam.).
> 
> Hat man allerdings verschiedene Aktualitäten, kann es dazu kommen, dass 
> man
> mehrere Versionen des gleichen Objekts (gml_id) mit unterschiedlichen 
> Ständen
> (beginnt) hat, die aber alle noch kein "endet" haben und demnach alle 
> aktuell
> scheinen.
> 
> Dem könnte man auch noch aus dem Weg gehen, indem man das "endet" der
> "älternen" auf das "beginnt" des Nachfolgers setzt.  Dann hat man zwar
> möglicherweise nicht die richtige Lebendauer (weil einem Zwischenstände
> fehlen), aber zumindest nicht mehr mehrere aktuelle.
> 
> Was man allerdings schlecht in den Griff bekommt, ist, wenn Objekte 
> durch andere
> Objekte ersetzt werden (etwa weil Flurstücke aufgeteilt oder 
> zusammengelegt
> werden).  Dann gibt es keinen Konflikt, den man mit gml_id und 
> beginnt/endet
> greifen und lösen kann.   Für Flurstücke könnte man immerhin noch nach
> räumlichen Überschneidungen suchen und damit feststellen, was nun 
> aktuell ist.
> Es gibt aber auch Objekte ohne eigenen räumlichen Bezug oder solche bei 
> denen
> eine Überschneidung kein Hinweis auf einen Fehler ist.
> 
> Bundesweit gibt es auch noch das Problem der unterschiedlichen
> Koordinatensysteme (EPSG:25832 vs EPSG:25833).
> 
> Was soll denn mit den in einem Schema gesammelten Daten 
> passieren/möglich sein?
> 
> 
> Jürgen
> 
> _______________________________________________
> NAS mailing list
> NAS at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/nas

-- 
Mit freundlichen Grüßen

Astrid Emde
GIS-Consultant

***********************************************************
FOSS Academy Sommerschule: Kompaktkurs zum Aufbau einer GDI
02.-06. September 2024, Präsenzveranstaltung in Bonn
https://www.foss-academy.com/kompaktkurse
***********************************************************

   Astrid Emde
   WhereGroup GmbH
   Eifelstraße 7
   53119 Bonn
   Germany

   Tel: +49(0)228 90 90 38 - 22
   Fax: +49(0)228 90 90 38 - 11

   astrid.emde at wheregroup.com
   www.wheregroup.com

   Meinen PGP Public-Key können Sie unter pgp.mit.edu herunterladen:

https://keys.openpgp.org/vks/v1/by-fingerprint/01F8152D36FC07C25EADDE86C5084ACC1C287CCB
   Signierte und/oder verschlüsselte Nachrichten sind sehr willkommen

   Folgen Sie der WhereGroup auf twitter:
   http://twitter.com/WhereGroup_com

   Geschäftsführer:
   Olaf Knopp, Peter Stamm
   Amtsgericht Bonn, HRB 9885
-------------------------------
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : 0x1C287CCB.asc
Dateityp    : application/pgp-keys
Dateigröße  : 1574 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.osgeo.org/pipermail/nas/attachments/20240617/1716c32f/attachment.key>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 228 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.osgeo.org/pipermail/nas/attachments/20240617/1716c32f/attachment.sig>