2. Sitzung, 12.01.2026, 13:00-14:00 Uhr

2. Sitzung, 12.01.2026, 13:00-14:00 Uhr

5 Teilnehmende

Themen

1. Begrüßung und Vorstellung neuer Teilnehmer

2. Zugriff auf Arbeitsdokumente

3. Modellierung von Geodaten

4. Aufgaben

5. Folgetermin

1. Begrüßung und Vorstellung neuer Teilnehmer

Dennis Jan ist Geoinformatiker und neu im TA4-Team der GDKE bei NFDI4Objekcts. Er wird die Geodatendienste entwickeln, die auf den in dieser Schreibgruppe ausgearbeiteten Datenmodellen beruhen.

2. Zugriff auf Arbeitsdokumente

Es bestehen Zugriffsprobleme auf die gemeinsamen Arbeitsdokumente auf der N4O Cloud. Die betroffenen Personen klären mit ihrer eigenen IT-Abteilung, inwiefern diese Zugriffsprobleme dort gelöst werden können und erhalten die Dokumente bis dahin per E-Mail. Ggf. muss über eine alternative Möglichkeit der gemeinsamen Bearbeitung von Dokumenten nachgedacht werden.

3. Modellierung von Geodaten

Reiner Göldner hat sich seit der letzten Sitzung mit der Modellierung von Geodaten beschäftigt und stellt seine Rechercheergebnisse vor.

Folgende drei Standards sind bzgl. der Definition von Georeferenzen und Geometrien vergleichbar:

1. ISO 19107 Geographic Information – Spatial Schema
2. Simple Feature Access – Part 1: Common Architecture (SFA-CA)
3. INSPIRE (Protected Sites)

Aufgrund der guten Erreichbarkeit der Dokumentation wird der „Simple Feature Access“ (SFA-CA) bevorzugt (https://www.ogc.org/standards/sfa)

Es werden drei Verpflichtungsgrade unterschieden:

• „muss“: dieser Eintrag bzw. mindestens einer der direkt untergeordneten Einträge müssen unbedingt bedient werden

• „soll“: dieser Eintrag bzw. mindestens einer der direkt untergeordneten Einträge müssen bedient werden, wenn Daten verfügbar sind

• „kann“: dieser Eintrag muss nur bedient werden, wenn direkt übergeordnet ein „muss“ (bzw. „soll“) steht, das bisher noch nicht anderweitig bedient wurde

Koordinatenbezugssystem
Wir haben uns darauf geeinigt, EPSG-Daten zu verwenden. Dafür wird die Form EPSG:Nummer genutzt. EPSG Nummern können hier abgerufen werden: https://epsg.io/

Daneben sollte aber auch die Möglichkeit gegeben werden, etwas anderes einzutragen. Wir sollten daher neutral von Koordinatenbezugssystem sprechen.

Beispiel:

• Kulturerbe-Objekt
    ◦ Verortung (muss)
        ▪ Georeferenz (direkt, soll)
            • Koordinatenbezugssystem (muss)
            • Geometrie (muss)
                ◦ Geometrie_Punkt (kann)
                ◦ Geometrie_Linie (kann)
                ◦ Geometrie_Fläche (kann)
        ▪ Ortsnamen (kann)
            • separat gelistet
                ◦ Ort_Adresse (kann)
                ◦ Ort_AGS (Amtlicher Gemeindeschlüssel, kann)
                ◦ Ort_GeoNames (kann)
            • oder mit Typangabe (ggf. mehrfach)
                ◦ Ort_Typ („Adresse“, „AGS“, „Geonames“, …, soll)
                ◦ Ort_Name (Syntax entspr. Typ, soll)

Diskussion:

Punkt-, Linien- und Flächengeometrien

Diskutiert wird, inwiefern Punkt-, Linien- und Flächengeometrien getrennt oder zusammengefasst gehalten werden sollen.

Dazu wurden folgende pro und contra Punkte festgehalten.

Zusammenfassung der Geometrien (pro):

• Gemeinschaftliche Haltung der Geometrien ist konzeptionell einfacher

• Vorteil für Datenmodellierung auch über GIS hinaus (z. B. Nutzung in Graphdatenbanken)

• Einheitlicher Datenbestand kann den Austausch über verschiedene Plattformen hinweg erleichtern

• WFS-Dienste können gemischte Geometrien verarbeiten (z. B. Import in QGIS ohne zusätzlichen Verarbeitungsschritt)

Zusammenfassung der Geometrien (contra):

• Erschwert die Weiterverarbeitung in klassischen GIS-Systemen

• Die Visualisierung kann problematisch sein (z. B. Punktdarstellung für lineare Objekte wie Römerstraßen)

• Gefahr von Datenredundanz, wenn Objekte mehrere Geometrien besitzen (z. B. Punkt und Fläche)

• Mehrere Datenbestände (Punkt, Linie, Fläche) würden Updates komplexer machen

Trennung der Geometrien (pro):

• Bessere Nutzbarkeit in GIS-Anwendungen

• Bei vielen Institutionen gängige Praxis

• Jedes Objekt kann klar definierte Geometrietypen haben (z. B. obligatorischer Punkt, optionale Fläche/Linie)

• Mehr Nutzer:innen können die Daten direkt verwenden

Eine Entscheidung wird in dieser Sitzung nicht getroffen. Die Anwesenden einigen sich darauf diesbezüglich noch weiter zu recherchieren und die bestehenden Möglichkeiten abzuwägen. Tendenziell erscheint die Zusammenführung die modernere, zukunftweisende Lösung, die Getrennte Behandlung die pragmatischere und bisher gängigere Variante.

Adressen:

Bisher ist für die Angabe Adresse ein Freitextfeld vorgesehen. Zur Disposition steht der Vorschlag stattdessen drei Felder zu verwenden:

• Ort_Adresse (PLZ (soll), Ort (kann), Straße (kann), Hausnummer (kann) als CSV

• Ort_AGS (referenziert den Amtlichen Gemeindeschlüssel: Bundesland (2 Stellen, soll) + Regierungsbezirk (1 Stelle, kann) + Kreis (3 Stellen, kann) + Gemeinde (3 Stellen, kann)

• Ort_GeoNames (https://www.geonames.org/)

oder zwei Felder:

• Ort_Typ (alternativ für Ortsnamen: „Adresse“, „AGS“, „Geonames“, …, soll)

• Ort_Name (alternativ für Ortsnamen: Syntax entspr. Typ, soll)

Offene Fragen sind zum einen wie mit Mehrfachnennungen umgegangen werden soll, ein Problem, das auch bei anderen Feldern auftreten wird. Zu bedenken ist weiterhin, dass die Zuordnung verloren geht, wenn die Daten nur CSV-mäßig aneinandergehängt werden. Zentral ist, wie die Daten in den Fachinformationssystemen vorliegen und geliefert werden können. Beispiele, die auf potentielle Probleme aufmerksam machen, wären für die weitere Diskussion sinnvoll. Eine Kodierung scheint zwar durchaus sinnvoll, wahrscheinlich wird aber dennoch auch ein Freitextfeld benötigt, da sonst keine Daten geliefert werden können.

4. Aufgaben

• Andreas Puhl wird mit Kollegen von NFDI4Earth Kontakt aufnehmen, die in der NFDI die Experten bzgl. Geodaten sind

• Reiner überträgt seine Ausarbeitungen in die Excel-Tabelle des Kulturerbeobjekts

5. Folgetermin

Die nächste Sitzung findet statt am Montag, 9.2., 13 Uhr