Muster Datendokumentation und - rawi

Raum und Wirtschaft (rawi)
Murbacherstrasse 21
6002 Luzern
Telefon 041 228 51 83
Telefax 041 228 64 93
[email protected]
www.rawi.lu.ch
Datendokumentation und Nachführungskonzept (Mustervorlage)
Thema / Datensatz: __________________________________________
Projektnam
e
Dateiname
Dateipfad
Vorlage für Datendokumentationen und Nachführungskonzepte
Muster_Nachfuehrungskonzept
I:\geo\Datenmodelle\Vorlagen\Muster_Nachfuehrungskonzept.docx
Status
Stand
Version
Autor
in Arbeit
genehmigt
01.05.2014
4.2
ma, ms
in Prüfung
in Vernehmlassung
Muster Datendokumentation und Nachführungskonzept
Inhaltsverzeichnis
1
EINLEITUNG....................................................................................................................... 4
2
BESCHREIBUNG DES DATENSATZES ............................................................................ 5
2.1 Thema / Datensatz ........................................................................................................................ 5
2.2 Gesetzliche Grundlagen ................................................................................................................ 5
2.3 Zweck der Nachführung ................................................................................................................ 5
2.4 Ersterfassung / IST-Zustand .......................................................................................................... 5
3
DATENMODELL ................................................................................................................. 6
3.1 Tabellarisches Datenmodell (Objektkatalog) ................................................................................ 6
3.2 Entitätenblockdiagramm .............................................................................................................. 6
3.3 Konzeptionelles, systemneutrales Datenmodell in INTERLIS ....................................................... 6
3.4 Richtlinien ..................................................................................................................................... 6
3.5 Grundlage, Erfassung und Status betreffende Metadaten ........................................................... 7
Grundlage- und erfassungstechnische Metadaten ................................................................ 8
4
GRUNDLAGEN UND ALLGEMEINE GRUNDSÄTZE ........................................................ 9
4.1 Technische Spezifikation ............................................................................................................... 9
4.2 Topologieregeln .......................................................................................................................... 10
4.3 Erfassungsrichtlinien ................................................................................................................... 10
5
ABLAUF DER NACHFÜHRUNG ...................................................................................... 11
5.1 Einleitung .................................................................................................................................... 11
5.2 Organisatorisches Nachführungsdiagramm ............................................................................... 11
5.3 Technischer Arbeitsablauf .......................................................................................................... 12
6
SCHNITTSTELLE IN ZENTRALE RAUMDATENBANK (ZRDB) ...................................... 12
7
VISUALISIERUNG UND VERÖFFENTLICHUNG ............................................................. 13
7.1 Darstellungsmodell ..................................................................................................................... 13
7.2 Nachführung Metadatenbank .................................................................................................... 13
7.3 Vorgaben für Veröffentlichung ................................................................................................... 13
8
ANHANG I: Datenmodelle ............................................................................................... 14
8.1 Tabellarisches Datenmodell (Objektkatalog), Bsp. Vernetzung IST (Auszug) ............................. 14
8.2 Entitätenblockdiagramm, Bsp. Schutzverordnung ..................................................................... 15
8.3 Konzeptionelles, systemneutrales Datenmodell, Bsp. INTERLIS ................................................ 18
9
ANHANG II: Namenskonventionen ................................................................................. 22
9.1 Grundlage.................................................................................................................................... 22
9.2 Nomenklatur für Feature Classes und Shape-Files ..................................................................... 22
4.2 / 01.05.2014 /ma
Seite 2 von 59
Muster Datendokumentation und Nachführungskonzept
9.3 Nomenklatur für Attribute, Attribut-Aliase und Attribut-Domänen .......................................... 23
9.4 Nomenklatur für Tabellen ........................................................................................................... 28
10 ANHANG III: Liste der von Datenbanken reservierten Feldnamen............................... 30
11 ANHANG IV: Topologieregeln......................................................................................... 43
11.1 Nachbarschaft – Angrenzen – Gebietseinteilung ....................................................................... 43
11.2 Koinzidenz ................................................................................................................................... 43
11.3 Konnektivität ............................................................................................................................... 44
11.4 Abzuleitende Regeln für den Aufbau von GIS-Datensätzen ....................................................... 44
11.5 Problematik Kreisbögen .............................................................................................................. 45
11.6 Genauigkeit (vgl. auch Kap. 4.1) ................................................................................................. 45
11.7 Topologieregeln nach ESRI (Beispiele) ........................................................................................ 46
12 ANHANG V: Erfassungsrichtlinien ................................................................................. 52
13 ANHANG VI: Flussdiagramme ........................................................................................ 53
13.1 Organisatorisches Nachführungsdiagramm, Bsp. NICHT-ÖREB-Daten....................................... 53
13.2 Organisatorisches Nachführungsdiagramm, Bsp. ÖREB-Daten .................................................. 54
13.3 Technischer Arbeitsablauf, Bsp. Erfassung Strassenachsen ....................................................... 56
14 ANHANG VII: Darstellungsmodell .................................................................................. 57
15 Anhang VIII: Die wichtigsten Vorgaben nochmals in der Übersicht ............................ 58
15.1 Einstellungen für Arc GIS (siehe auch Kapitel 4.1): ..................................................................... 58
15.2 Vorgaben Nomenklatur (siehe auch Anhang II): ......................................................................... 58
Änderungskontrolle
Version Datum
Name / Stelle
Bemerkungen
2.0
01.02.2012
Marius Menz, geo
Erstellt
3.0
27.03.2012
Marius Menz, geo
Freigegeben
4.0
15.03.2013
Marius Menz, geo
Freigegeben
4.1
07.03.2014
Marius Menz, geo
Anpassungen
4.2
07.03.2014
Marius Menz, geo
Ergänzung Nomenklatur
4.2 / 01.05.2014 /ma
Seite 3 von 59
Muster Datendokumentation und Nachführungskonzept
1 EINLEITUNG
Das vorliegende Dokument dient als Vorlage zur Erstellung einer Datendokumentation inkl.
Datenmodell und Nachführungskonzept für einen Geodatensatz bzw. ein Thema mit
mehreren Geodatensätzen.
Datendokumentationen sind unabdingbar, um die Aktualität, Vollständigkeit, weitgehende
Fehlerfreiheit, problemlose Austauschbarkeit sowie lange Haltbarkeit der Geodaten
sicherzustellen und zu gewährleisten, dass sie unter Einhaltung dieser hohen Qualitätsansprüche über Map-Services einer breiten Öffentlichkeit bedenkenlos zur Verfügung
gestellt werden können.
Durch das Instrument der Datenmodellierung wird für jeden Datensatz eine eindeutige
Struktur festgelegt und die Bedeutung von Inhalten definiert. Datenmodelle sind ein Teil der
Datenbeschreibung (Metadaten). Eine sorgfältige Modellierung vereinfacht die
programmatische Nutzung und ist eine wichtige Voraussetzung für die
Wiederverwendbarkeit und die nachhaltige Nutzung von (Geo)-Daten. Die nachträgliche
Anpassung von Datenmodellen ist oft mit der Anpassung des Programmcodes verbunden
und kann daher hohe Kosten verursachen.
Für kantonale Geodaten, die in der zentralen Raumdatenbank ZRDB publiziert werden und
insbesondere für Geodatensätze, für welche Verknüpfungen zu anderen Datensätzen
vorgesehen sind, ist ein explizites Datenmodell zu verwenden bzw. zu erstellen. Wird die
Datenmodellierung extern in Auftrag gegeben, müssen nebst zentralen applikationsspezifischen Belangen auch Anforderungen der zentralen Raumdatenbank ZRDB
berücksichtigt werden.
Die Erstellung von Datenmodellen erfolgt idealerweise in Arbeitsgruppen mit GISFachleuten. Im Falle von Konzerndaten muss ein Datenmodell von der Abteilung
Geoinformation abgenommen werden.
Das vorliegende Dokument wendet sich sowohl an kantonsinterne Projekt-Mitarbeiterinnen
und -Mitarbeiter, als auch an externe Büros, die im Auftrag des Kantons Geodaten erfassen
und folglich Geodatendokumentationen erstellen müssen. Das Dokument soll und kann die
umfangreichen Dokumentationen der Softwarehersteller und die vielfältige Fachliteratur
nicht ersetzen. Es soll Mindestkriterien aufzeigen und zu einem Qualitätsbewusstsein
beitragen, ohne das eine nachhaltige Verwendung von Geodaten nicht gewährleistet ist.
Das Vorgehen bei der Ersterfassung eines Geodatensatzes ist hier nicht vollständig beschrieben. Ein solches wird meist im Rahmen von Projekten abgehandelt.
Die hier aufgelisteten Vorgaben sind für Konzerndaten zwingend einzuhalten.
Kapitel 2 bis 7 sind je nach Datensatz individuell auszugestalten. Ab Kapitel 8 (Anhang)
finden sich dazu ausgewählte Beispiele.
4.2 / 01.05.2014 /ma
Seite 4 von 59
Muster Datendokumentation und Nachführungskonzept
2 BESCHREIBUNG DES DATENSATZES
2.1 Thema / Datensatz
Kurzbeschrieb der Daten in Prosa, Verweis auf Metadaten / Metadatenbank (falls bereits
Einträge vorhanden sind).
2.2 Gesetzliche Grundlagen
Auflistung der relevanten Gesetze
2.3 Zweck der Nachführung
Erläuterungen, weshalb der Datensatz nachzuführen ist
2.4 Ersterfassung / IST-Zustand
Ersterfasser, Datum, Stand (Aktualität), Vollständigkeit, Massstabsbezug, Perimeter,
Qualität (falls nicht bereits in Metadatenbank vorhanden), Abhängigkeiten zu anderen
Datensätzen (z.B. des Bundes etc.). Ggf. Besonderheiten erwähnen, falls das Vorgehen bei
der Ersterfassung von demjenigen der Nachführung abweicht.
4.2 / 01.05.2014 /ma
Seite 5 von 59
Muster Datendokumentation und Nachführungskonzept
3 DATENMODELL
Eine saubere und nachvollziehbar dokumentierte Datenstruktur ist eine wesentliche
Voraussetzung für eine hohe Datenqualität. Die erhobenen Daten sind einerseits
tabellarisch zu beschreiben (i.d.R. mit UML- oder Entitätenblockdiagramm, siehe Kapitel
3.2), bei sehr einfach strukturierten Datensätzen zumindest mit Themen- und Attributliste,
(sog. Objektkatalog: siehe Kapitel 3.1), anderseits durch das systemneutrale Datenmodell
in INTERLIS (bei ÖREB-Daten zwingend; siehe Kapitel 3.3).
Beim Erstellen des Datenmodells sind zwingend die vorgegebenen Namenkonventionen
einzuhalten. Diese sind in Anhang IV detailliert beschrieben. Zu beachten gilt es auch, dass
einige Feldnamen nicht zu verwenden sind, da sie von ORACLE, ACCESS oder INTERLIS
reserviert sind. Die nicht zu verwendenden Feldnamen sind in Anhang VII aufgelistet.
3.1 Tabellarisches Datenmodell (Objektkatalog)
Ein Datenmodell dieser Art ist nur für einfache Datensätze mit nur einem Thema und ohne
Beziehungen zulässig. Ein Beispiel dazu findet sich in Kapitel 8.1.
3.2 Entitätenblockdiagramm
Bei umfangreichen Datenmodellen kann im Entitätenblockdiagramm auf die Auflistung der
Attribute verzichtet werden, im Objektkatalog sind sie jedoch vollständig aufzuführen. Ein
Beispiel dazu liefert Kapitel 8.2.
3.3 Konzeptionelles, systemneutrales Datenmodell in INTERLIS
Erstellung eines INTERLIS-Datenmodell ist für ÖREB-Datensätze zwingend. Ein Beispiel
dazu findet sich in Kapitel 8.3.
3.4 Richtlinien
Grundsätzlich ist darauf zu achten, bei der Erstellung von Datenmodellen nur folgende
Datentypen zu verwenden:





Datum: Tag.Monat.Jahr
Datum/Zeit: Tag.Monat.Jahr Stunden:Minuten:Sekunden
Text: Zeichenkette alphanumerischer Symbole (Länge ist zu definieren, max. 255)
Festk.-Z n: Festkommazahl mit n Stellen
Gleitk.-Z n,m: Gleitkommazahl mit n Stellen, davon m nach dem Komma (Bsp.: 3.456:
Gleitk.-Z = 4,3)
 Polygon: Geometrietyp Fläche (INTERLIS: surface, area)
 Polyline: Geometrietyp Linie
 Point: Geometrietyp Punkt
Bei Geodaten, welche ausschliesslich verwaltungsintern und mit ESRI-Produkten erstellt
werden, können die Datenmodelle mit folgenden (ESRI-spezifischen) Datentypen definiert
werden:
 Long Integer: Ganzzahl zwischen -999‘999‘999 und 9‘999‘999‘999
 Short Integer: Ganzzahl zwischen -999 und 9999 (das „Minus“ benötigt in gewissen
Datenformaten ein zusätzliches Zeichen)
 Double: Gleitkommazahl
 Text: Zeichenkette alphanumerischer Symbole (Länge ist zu definieren, max. 255)
 Date: Datumsfeld
 Date/Time: Datumsfeld mit Zeit
 Geometry: Geometrietyp (ESRI: point, line, polygon, multipoint)
4.2 / 01.05.2014 /ma
Seite 6 von 59
Muster Datendokumentation und Nachführungskonzept
Weitergehende Informationen sind u.a. zu finden unter:
http://resources.arcgis.com/de/help/main/10.1/index.html#//003n0000001m000000
Nachfolgende Tabelle stellt die ESRI-spezifischen den allgemein formulierten Begriffen
gegenüber und erläutert sie anhand von Beispielen.
Allgemeine Definition
Definition in ESRI
Beispiele
Ganz-Z: n <=3
Short Integer
7841 oder -345
Ganz-Z: n < 10
Long Integer
678543
Ganz-Z: n > 9
Double
234654765987
Gleitk-Z: n,m
Double
456.876
Datum
Date
24.08.1970 [TT.MM.JJJJ]
Datum/Zeit
Date
24.08.1070 15:30:00 [TT.MM.JJJJ HH:MM:SS]
Text: n
Text (n)
WAHR
Short Integer
Domäne mit Ausprägungen 0 / 1 (0=nein, 1=ja)
GUID
Text (38)
{55fa59f6-2a4b-4990-ac0d-afb39e128d8b}
Polygon
Polygon (SHAPE)
Polyline
Polyline (SHAPE)
Point
Point (SHAPE)
Bei der Verknüpfung von Datensätzen ist als Primary Key (Schlüsselfeld) ein Feld des Typs
„Long Integer“ oder ein GUID (bzw. UUID, vgl. Kapitel 9.3) zu verwenden (empfohlen bei
Vergabe durch Applikation). Es wird zudem empfohlen, für jedes Objekt einen eindeutigen
Identifikator zu vergeben.
Nachführungsattribute, also Informationen zum Erfasser, zum Zeitpunkt der Erfassung,
Änderung, Löschung von Feldern oder Attributen sind ebenfalls aufzunehmen.
Für codierte Werte müssen Codelisten (sog. Domänen) definiert werden (vgl. Kapitel 8.1).
3.5 Grundlage, Erfassung und Status betreffende Metadaten
Nachfolgende Attribute und Domänen beschreiben die Grundlagen, die Erfassung sowie
den Status von Daten. Diese "Metadaten" müssen nicht für alle Datensätze vollständig
abgefüllt werden, im Falle der Verwendung sind sie jedoch genau auf die hier spezifizierte
Weise zu schreiben.
4.2 / 01.05.2014 /ma
Seite 7 von 59
Muster Datendokumentation und Nachführungskonzept
Grundlage- und erfassungstechnische Metadaten
Feldname
Alias
Feldtyp
Bemerkung
BASENAME
Bezeichnung
Grundlage
Text: 100
Bezeichnung der Grundlage
BASEKIND
Art Grundlage
Ganz-Z:
3
Art der Grundlage als codierte
Liste BASEKIND
BASECOM
Bemerkung
Grundlage
Text: 255
Bemerkungen zur Grundlage
BASESCALE
Massstab
Grundlage
Ganz-Z:
8
Massstab der Grundlage als
codierte Liste BASESCALE
BASEORIG
Herkunft
Grundlage
Text: 100
Herkunft, Verfasser der
Grundlage
BASEDATE
Datum
Grundlage
Datum
Erstellungsdatum der
Grundlage
CREAKIND
Art Erfassung
Ganz-Z:
3
Erfassungsart der Geometrie
als codierte Liste CREAKIND
CREAPREC
Genauigkeit
Erfassung [m]
Gleitk.-Z:
3,2
Erfassungsgenauigkeit in
Metern
-99.99 = unbekannt
CREACOM
Bemerkung
Erfassung
Text: 255
Bemerkungen zur Erfassung
CREABY
Erstellt durch
Text: 50
Name erstellende(s) Person /
Büro
DATEOFCREA
Datum Erstellung
Datum
Erstellungsdatum des Objekts
CONTPERS
Kontaktperson
Text: 255
Name, Adresse, E-Mail,
Telefon
CONTDATE
Datum Kontakt
Datum
Datum des Kontaktes
CHNGCOM
Bemerkung
Änderung
Text: 255
Bemerkungen zu Änderungen
CHNGBY
Geändert durch
Text: 50
Name der ändernden Person
CHNGWHY
Grund Änderung
Ganz-Z:
3
Grund der letzten Änderung als
codierte Liste CHNGWHY
DATEOFCHNG
Datum letzte
Änderung
Datum
Datum der letzten Änderung
am Objekt
DATEOFGEOM
Datum
Geometrieänderung
Datum
Datum der letzten Änderung an
der Geometrie
Die zugehörigen codierten Listen sowie Metadaten zum Status finden sich in Anhang
II sowie in Kapitel 4.2 des GIS-Handbuchs.
4.2 / 01.05.2014 /ma
Seite 8 von 59
Muster Datendokumentation und Nachführungskonzept
4 GRUNDLAGEN UND ALLGEMEINE GRUNDSÄTZE
4.1 Technische Spezifikation
Die Verwendbarkeit, aber auch die Genauigkeit von Geodaten hängt unmittelbar von der
Verwendung des korrekten Bezugssystems bei der Datenerfassung ab. Die folgenden
Spezifikationen zum Koordinatensystem und zur Tolerance / Resolution sind zwingend
einzuhalten.
Tabelle Koordinatensystem (Spezifikation ESRI)
XY Coordinate System
CH1903 LV03
Geographic Coordinate System
GCS_CH1903
Datum
D_CH1903
Spheroid
Bessel_1841 (6377397.155, 6356078.9628181886,
299.1528128)
Prime Meridian
Greenwich (0)
Angular Unit
Degree (0.017453292519943299)
Projection
Hotine_Oblique_Mercator_Azimuth_Center
False_Easting
600000
False_Northing
200000
Scale_Factor
1
Azimuth
90
Longitude_Of_Center:
7.439583
Latitude_Of_Center
46.952406
Linear Unit
Meter (1)
Tabelle Tolerance / Resolution (Spezifikation ESRI)
Tolerance
0.0004 m
XY Resolution
0.00005 m
Ausserdem ist anzugeben, in welcher Genauigkeit (z.B. ab AV, ÜP, Orthophoto) und in
welchem Massstab die Daten erhoben und welche Hintergrundinformationen verwendet
werden. Grundsätzlich dienen der Übersichtsplan 1:10'000 und die Daten der Amtlichen
Vermessung als Referenz für die Digitalisierung von Geodaten. Zur visuellen Kontrolle sind
das digitale Oberflächenmodell (DOM-AV) oder das Orthophoto zu verwenden. Wo sinnvoll
können die Landeskarten 1:25'000 eingesetzt werden.
Abweichungen von diesen Einstellungen müssen begründet sein und in der Projektdokumentation und den Metadaten festgehalten werden.
4.2 / 01.05.2014 /ma
Seite 9 von 59
Muster Datendokumentation und Nachführungskonzept
Tabelle Erfassung
Erfassungsgrundlage
AV, ÜP, Orthophoto, Koordinatenübernahme etc.
Erfassungsmassstab
z. B. 1: 5’000
abgeleitet von
z.B. Vektor 25
Als Richtlinie für die Erfassungsgenauigkeit gilt die nachfolgende Tabelle:
Für die Erfassung
relevanter Bereich
Massstab
Minimaler Abstand
Ziel*
Erfassung**
Referenzgrundlage
zwischen Vertices °
1:65'000
1:10'000
1:25'000
1:10'000
Übersichtsplan
~ 10m
1:10'000
1:2'000
AV
1:5'000
1:2'000
~ 3m
1:2'000
1:2'000
(Bodenbedeckung,
Parzellen)
1:500
AV
AV
AV
*
Zielmassstab
Massstab des vorgesehenen kartographischen Produkts. In
kantonalen Projekten sind gängige Zielmassstäbe 1:65'000
(ganzer Kanton A0-Ausdruck), 1:25'000, 1:10'000, 1:5'000,
1:2'000.
**
Erfassungsmassstab
Für den Detaillierungsgrad ausschlaggebender Massstab
°
Minimaler Abstand zwischen
Vertices
Es müssen so viele Vertices gesetzt werden, um die Form
eines Objekts im vorgesehenen Erfassungsmassstab korrekt
zu charakterisieren.
4.2 Topologieregeln
Mit dem Begriff Topologie wird eine Reihe räumlicher Integritätsregeln umschrieben, die
das Verhalten räumlicher Objekte und Objektklassen beschreiben. Bei der Erzeugung von
GIS-Datensätzen ist darauf zu achten, dass die Topologie unter Beachtung dieser Regeln
aufgebaut wird, so dass ein fehlerfreier und konsistenter Datensatz entsteht.
Die Grundsätze zur Topologie sind in Anhang IV beschrieben. Kapitel 11.7 geht speziell auf
Topologieregeln ein, die mit ESRI definiert werden können. Ausserdem enthält es eine
Matrix, wo für Linien sowie Polygone die für einen bestimmten Datensatz definierten
Topologieanforderungen festgehalten werden können.
4.3 Erfassungsrichtlinien
Typische Erfassungsprobleme und deren angestrebte Lösung sollen beschrieben sowie
bildlich dargestellt werden (Beispiel siehe Anhang V).
4.2 / 01.05.2014 /ma
Seite 10 von 59
Muster Datendokumentation und Nachführungskonzept
5 ABLAUF DER NACHFÜHRUNG
5.1 Einleitung
Bereits im Rahmen der Ersterfassung muss definiert werden, in welcher Periodizität die
Daten künftig nachzuführen sind bzw. wie mit laufenden Änderungen umzugehen ist. Das
Beispiel in nachfolgender Tabelle dient zur groben Übersicht, der detaillierte Ablauf der
Nachführung wird weiter unten beschrieben.
Perimeter Datenformat
Datenherr
Nachführungsrhythmus
Zonenplan
Kanton
LU
Gemeinde x
Verantwortlich
für Nachführung
Sporadis
ch
1 Jahr
Halbjahr
Quartal
Monat
wöchentli
ch
laufend
Bezeichnung
INTERLIS 1
Planungsbüro
5.2 Organisatorisches Nachführungsdiagramm
Der Organisatorische Ablauf der Datenerfassung mit entsprechenden Zuständigkeiten ist
anhand eines Diagramms (siehe Kapitel 8.1 sowie 8.2) nachvollziehbar darzustellen. Jeder
Arbeitsschritt und alle involvierten Stellen müssen klar ersichtlich sein. Die einzelnen
Objekte im Diagramm sind durchzunummerieren und in der Folge mit ein paar Sätzen zu
beschreiben, ggf. ergänzt mit weiteren Abbildungen oder Screenshots.
Folgende Arbeitsschritte sind im Normalfall zu erläutern (die kursiv dargestellten Punkte
kommen nicht in jedem Fall zur Anwendung, die Punkte g und h sind vor allem bei ÖREBDaten zu beachten):
a) Auftragserteilung
Intern oder extern, allenfalls Vertragserstellung nötig.
b) Datenbezug
Bezug der Originaldaten vom Datenherr bzw. –Verwalter. Auf einem Daten-Lieferschein ist
festzuhalten, wann welche Datensätze bezogen wurden (Name, Version, Format, Datum,
Perimeter).
c) Durchführung
Ausführung des Nachführungsauftrages unter Berücksichtigung der Vorgaben dieses Dokuments sowie der allgemeinen Regeln des Projekt- und Qualitätsmanagements.
d) Datenprüfung inhaltlich
Inhaltliche Datenprüfung durch die zuständige Dienststelle, ggf. „Korrekturschlaufe“.
e) Datenübergabe an die Abt. Geoinformation (geo)
Die Daten sind der Abteilung Geoinformation des rawi in einem definierten
Dateiübertragungsmedium (CD-ROM, Upload Geoshop, FTP) und Format zu übergeben.
Zusätzlich zu den Geodaten sind jeweils zu definierende Beilagen mit den wichtigsten
Metadaten als PDF abzuliefern.
f) Datenprüfung GIS-technisch
4.2 / 01.05.2014 /ma
Seite 11 von 59
Muster Datendokumentation und Nachführungskonzept
Die Prüfung der Datenmodellkonsistenz und der Topologie ist mit geeigneten
Prüfprogrammen vorzunehmen, der Prüfprozess ist zu beschreiben und zu dokumentieren.
g) Öffentliche Auflage mit Rekursfrist
Vor allem bei ÖREB-Daten relevant, bei übrigen Geodaten oft unnötig.
h) Genehmigung / Beschwerdeverfahren
Ablaufdiagramm mit Beschwerde“schlaufe“ (vgl. Kapitel 13.2)
i)
Zahlung veranlassen
j)
Originaldaten zurückfordern bzw. zurückgeben gem. Datennutzungsvertrag
k) Abgeleitete Produkte erstellen
Welche? Durch wen? Bis wann?
5.3 Technischer Arbeitsablauf
Der Technische Ablauf der Datenerfassung ist anhand eines Diagramms nachvollziehbar
darzustellen. Die einzelnen Objekte im Diagramm sind durchzunummerieren und in der
Folge mit ein paar Sätzen zu beschreiben, ggf. ergänzt mit weiteren Abbildungen oder
Screenshots.
Anhang V zeigt als Beispiel auszugsweise das technische Vorgehen bei der Erfassung von
Strassenachsen.
6 SCHNITTSTELLE IN ZENTRALE RAUMDATENBANK (ZRDB)
Falls die Schnittstelle in die ZRDB vom Standard abweicht, ist diese hier detailliert zu
beschreiben. Diese Beschreibung beinhaltet allfällige Modelltransformationen und Datenprüfungen. Es muss auch die verwendete Software mit Versionsangabe aufgeführt werden.
4.2 / 01.05.2014 /ma
Seite 12 von 59
Muster Datendokumentation und Nachführungskonzept
7 VISUALISIERUNG UND VERÖFFENTLICHUNG
7.1 Darstellungsmodell
Darstellungsrichtlinien sollen beschrieben werden. Diese beinhalten zumindest die
Symbolisierungen und Farbwerte. Ein Beispiel dazu findet sich in Anhang VI.
7.2 Nachführung Metadatenbank
Neueintrag bzw. Aktualisierung in der Metadatenbank erfolgt zurzeit intern in der Abt.
Geoinformation (geo). Die nötigen Angaben müssen vom Datenherrn bzw. –Produzenten
geliefert werden.
Falls Metadaten automatisiert nachgeführt werden sollen, hat hier ein Hinweis zu erfolgen
(mit Angabe des Nachführungsrhythmus).
7.3 Vorgaben für Veröffentlichung

Definition der Berechtigungen: Welche Datensätze sollen welchen Nutzern des
LUCAT, Geoportals oder fachspezifischen Applikationen zur Verfügung gestellt
werden?

LUCAT: Erstellung von Einzel- oder Gruppenlayern oder allenfalls Integration in
bestehenden Gruppenlayern?

Geoportal: Neuerstellung einer Onlinekarte oder Integration in bestehende
Onlinekarte?

Applikation: Integration in bestehende Fachapplikation?

GIS-Datenshop: Berechtigungsstufen gemäss GeoIV des Bundes zuweisen: A
(öffentlich), B (beschränkter Zugang) und C (kein Zugang). Bei Bedarf müssen
Berechtigungen auf Stufe Felder definiert werden.
In nachfolgender Tabelle sind die zutreffenden Punkte anzukreuzen:
Name
Datensatz
ID*
LUCAT
Onlinekarte Applikation GIS-Datenshop
Berechtigungsstufe
Einzellayer
Grouplayer
A
B
C
A
B
C
A
B
C
A
B
C
* ID Geobasisdaten (kantonsrechtlich) des Kantons Luzern
4.2 / 01.05.2014 /ma
Seite 13 von 59
Muster Datendokumentation und Nachführungskonzept
8 ANHANG I: Datenmodelle
8.1 Tabellarisches Datenmodell (Objektkatalog), Bsp. Vernetzung IST
(Auszug)
Ökoflächen – Landwirtschaftliche Kulturflächen
Dateiname: VKUKTLU0_PY
Name
GEO_00100644001
Alias
Typ
ELEM_ID
Objektnummer
Geometry
(Polygon)
Double
GBPER_CODE
Double
PRZNUMMER
Code GrundbuchPerimeter
Parzellennummer
LZCODE
Landwirtschaftliche Zone
Long Integer
SHAPE
Grösse
Domäne
(Codeliste)
50
Double
VKU_LZCODE
Erläuterung der Attribute:
ELEM_ID
Fortlaufende Nummer, eindeutig pro Gemeinde. Die Objektnummern werden vor Abschluss
des Projekts von der Projektträgerschaft vergeben, damit eine fortlaufende Nummerierung
möglich ist.
BFS_NR
Gemeinde-Nummer des Bundesamts für Statistik (BfS)
GBPER_CODE
Code des Grundbuch-Perimeters
PRZNUMMER
Grundstück-Nummer
LZCODE
Landwirtschaftliche Zone: Landw. Produktionszonen und Sömmerungsgebiete
Domäne
VKU_LZCODE
Code
Beschreibung / Werte
31
Talzone
41
Hügelzone
51
Bergzone
99
unbekannt
4.2 / 01.05.2014 /ma
Seite 14 von 59
Muster Datendokumentation und Nachführungskonzept
Die Beschreibung der Domäne (im Arc Catalog „Code Description“ genannt) sollte nicht
länger als 100 Zeichen sein.
Der Objektkatalog kann mit zusätzlichen Spalten ergänzt werden, beispielsweise um
Einheiten oder Toleranzen festzulegen.
Ein Datenmodell dieser Art ist nur für einfache Datensätze mit nur einem Thema sowie
ohne Beziehungen zulässig. Komplexere Datensätze sind gemäss 12.2 und 12.3 zu
beschreiben.
8.2 Entitätenblockdiagramm, Bsp. Schutzverordnung
Weitere_Linien
Objekt  Schutzverordnung
mc
1
Schutzverordnung
Perimeter Schutzverordnung
1
m Objekt  Schutzverordnung
Geometry: Polyline
ID_SVO
LINIENTYP
NAME_SVO
Geometry: Polygon
TYP_SVO
ID_SVO
RRB_DATUM
SRL_NR
INKRAFT_DT
RECHTSSTAT
1
MASSSTAB
BEMERKUNG
Zonierung
Objekt  Schutzverordnung
Geometry: Polygon
mc
Legende
ZONE_SVO
Kursive Schrift: optionale Eingabe
ZONE_STARD
Gelb: uwe definiert und füllt
Tabelle
ZON_GRUPPE
Grün: geo definiert und füllt
Tabelle
ZON_BESCHR
Assoziationstypen für Tabellen
4.2 / 01.05.2014 /ma
Seite 15 von 59
Muster Datendokumentation und Nachführungskonzept
Tabelle A Tabelle B
Beziehung
1
1
einem Objekt aus der Tabelle A ist genau ein Objekt aus der
Tabelle B zugeordnet
1
c
einem Objekt aus der Tabelle A ist ein oder kein Objekt aus der
Tabelle B zugeordnet
1
m
einem Objekt aus der Tabelle A sind mehrere (mindestens aber
ein) Objekte aus der Tabelle B zugeordnet
1
mc
einem Objekt aus der Tabelle A sind mehrere, ein oder kein Objekt
aus der Tabelle B zugeordnet
Kombiniert man eine Assoziation mit einer Gegen-Assoziation, so ergibt sich die Beziehung
zwischen den betrachteten Tabellen.
Bei umfangreichen Datenmodellen kann im Entitätenblockdiagramm auf die Auflistung der
Attribute verzichtet werden, im Datenkatalog (siehe folgende Seite) sind sie jedoch
vollständig aufzuführen.
Felddefinitionen:
Tabellen / Felder
Alias
Feldtyp
Grösse
Bedeutung / Inhalt
ID_SVO
SchutzverordnungsNummer
Short
integer
4
Eindeutige Nummer
Schutzverordnung
NAME_SVO
Name Schutzverordnung
Text
150
Name der Schutzverordnung
RRB_DATUM
Datum RRB
Date
8
Datum d.
Regierungsratsbeschlusses
SRL_NR
Nummer syst.
Rechtssammlung
Text
16
Nummer der syst.
Rechtssammlung
INKRAFT_DT
Datum der Inkraftsetzung
Date
8
Datum der Inkraftsetzung
RECHTSSTAT
Rechtsstatus
Text
50
Rechtsstatus wie ‚in Kraft’,
Entwurf’, ‚Auflage’, ‚Beschwerde
hängig’ usw.
MASSSTAB
Massstab
Long
integer
16
2'000, 5'000; 10'000, .. (als Code:
1, 2, …)
Schutzverordnung
4.2 / 01.05.2014 /ma
Seite 16 von 59
Muster Datendokumentation und Nachführungskonzept
Perimeter Schutzverordnung
Objekt 
Schutzverordnung
Verweis auf Tabelle
SHAPE
Geometry
(Polygon)
16
Flächengeometrie (Polygon)
Zonierung
Objekt 
Schutzverordnung
Verweis auf Tabelle
SHAPE
Geometry
(Polygon)
16
Flächengeometrie (Polygon)
ID_SVO
SchutzverordnungsNummer
Short
integer
4
Eindeutige Nummer
Schutzverordnung
TYP_SVO
Schutzverordnungstyp
Short
integer
4
Schutzverordnungstyp wie Pflanzenschutzgebiete, grosse Seen
usw.
ZONE_SVO
Zonierung
Short
integer
4
Legendentext zur Beschriftung
(z.B. Naturschutzreservat)
ZONE_STARD
Standardzone
Short
integer
4
Legendentext > keine
Beschriftung, für Farbgebung;
nach neuer Legen-denstruktur
(z.B. Naturschutzzone)
ZON_GRUPPE
Zonengruppe
Long
Integer
16
Gruppen-Zugehörigkeit einer
Zone (z.B. Naturschutzzone);
optional (nicht bei grossen Seen)
ZON_BESCHR
Zonenbeschreibung
Text
255
Weitere Spezifikationen > muss
noch definiert werden
Weitere_Linien
Objekt 
Schutzverordnung
Verweis auf Tabelle
SHAPE
Geometry
(Polyline)
16
Liniengeometrie (Polyline)
ID_SVO
SchutzverordnungsNummer
Short
integer
4
Eindeutige Nummer
Schutzverordnung
LINIENTYP
Linientyp
Text
50
Legendentext zur Beschriftung
(Feldweg / Fussweg /
4.2 / 01.05.2014 /ma
Seite 17 von 59
Muster Datendokumentation und Nachführungskonzept
Trampelpfad)
Die Domänen wurden hier aus Platzgründen weggelassen, sie sind analog 8.1 zu
ergänzen!
8.3 Konzeptionelles, systemneutrales Datenmodell, Bsp. INTERLIS
TRANSFER Baulinien_Kanton_Luzern;
MODEL Baulinien_LU_02
!! Version 2.0 vom 22. Juni 2009
!!
!! Ersteller: Andreas Heini
!! Datum: 10. Februar 2005
!! Aenderungen: Mario Schaffhauser
!! Datum1: 7. Juli 2005
!! Aenderung: Fredy Staedler:
!! Datum: 22. Juni 2009: neu Rechtsstatus_Baulinie = (in_Bearbeitung,
Planungszone_vorlaeufig_rechtswirksam, rechtskraeftig,
!! Beschwerde_haengig);
!! ***************************************************************************************************************************
DOMAIN
LKoord = COORD2 480000.000 70000.000
840000.000 300000.000;
HKoord = COORD3 480000.000 70000.000
840000.000 300000.000
-200.000
5000.000;
Hoehe = DIM1 -200.000 5000.000;
SchriftOri = GRADS 0.0 399.9;
SchriftSize = (klein, mittel, gross, unterdrueckt);
Zustaendigkeit_Baulinie = (Bund, Kanton, Gemeinde);
Rechtsgrundlage = (Strassen_Gesetz, Wasserbau_Gesetz, Sondernutzungsplan, andere);
Genehmigungsbehoerde = (RRB, RRB_Gemeinde, Gemeinde, Bund, RRB_Bund, andere, unbekannt);
Rechtsstatus_Baulinie = (in_Bearbeitung, Planungszone_vorlaeufig_rechtswirksam, rechtskraeftig,
Beschwerde_haengig);
Herkunft_Baulinie = (Planabgriff, Konstruktion, Koordinaten_Uebernahme);
Herkunft_Grundlage = (AV93_konform, prov_numerisiert, gescannt);
Bezugsrahmen = (LV03alt, LV03neu_LV95);
PlantypArt = (P200,P500,P1000); !!{Planarten angeben}
4.2 / 01.05.2014 /ma
Seite 18 von 59
Muster Datendokumentation und Nachführungskonzept
!! Die Attributsdeklaration OPTIONAL ist rein schnittstellentechnisch zu verstehen und
!! nicht als Vorschrift zur Datenerfassung. Alle aufgefuehrten den Objekten zugehoerigen
!! Attribute sind i.d.R. zu erfassen, sofern deren Wert bekannt ist.
TOPIC Baulinien=
!!Tabelle Entscheid (dient als Entstehungstabelle)
!!*****************
TABLE Entscheid =
Beschreibung: OPTIONAL TEXT*50;
!! Kurzbeschrieb
Genehmigungs_Behoerde: Genehmigungsbehoerde;
Entscheid_Nr: OPTIONAL TEXT*50;
Genehmigungs_Datum: OPTIONAL DATE;
Entscheid_Nr_2: OPTIONAL TEXT*50;
!! wenn RRB_Gemeinde, dann hier Gemeinde-Entscheid
!! wenn RRB_Bund, dann hier Bundes-Entscheid
Genehmigungs_Datum_2: OPTIONAL DATE;
!! wenn RRB_Gemeinde, dann hier Gemeinde-Datum
!! wenn RRB_Bund, dann hier Bundes-Datum
Auflage_Datum: OPTIONAL TEXT*50;
Herkunft_Grundlage: Herkunft_Grundlage;
Bezugsrahmen: Bezugsrahmen;
NO IDENT
END Entscheid;
4.2 / 01.05.2014 /ma
Seite 19 von 59
Muster Datendokumentation und Nachführungskonzept
!!Tabelle Baulinien
!!*****************
TABLE Baulinien =
Objekt: -> Entscheid;
!! Beziehung 1-mc
Art: (Normal_Baulinie,
Zwangs_Baulinie,
Baulinie_mit_Anordnungsbereich,
Bestandes_Baulinie,
Arkaden_Baulinie,
Baulinie_unterirdische_Bauteile,
Baulinie_oberirdische_Bauteile,
Baulinie_Bauten_ohne_Wohn_und_Arbeitsraeume,
Baulinie_Kleinbauten,
andere_Baulinie);
Zusatzinformation_Baulinie: OPTIONAL TEXT*200;
Zustaendigkeit: Zustaendigkeit_Baulinie;
Rechtsgrundlage: OPTIONAL Rechtsgrundlage;
Originalmassstab: PlantypArt // undefiniert = P500 //;
Rechtsstatus: Rechtsstatus_Baulinie;
Herkunft_Baulinie: Herkunft_Baulinie;
Plan_Nr: TEXT*50;
Erfassungs_Datum: DATE;
Bemerkung: OPTIONAL TEXT*200;
NO IDENT
END Baulinien;
TABLE Baulinien_Linienelement =
Objekt: -> Baulinien;
!! Beziehung 1-mc
Geometrie: POLYLINE WITH (STRAIGHTS, ARCS) VERTEX LKoord WITHOUT OVERLAPS > 0.050;
NO IDENT
END Baulinien_Linienelement;
TABLE Baulinien_Flaechenelement =
Objekt: -> Baulinien;
!! Nur bei Baulinien im Anordnungsbereich
!! Beziehung 1-mc
Geometrie: SURFACE WITH (STRAIGHTS, ARCS) VERTEX LKoord WITHOUT OVERLAPS > 0.050;
NO IDENT
END Baulinien_Flaechenelement;
4.2 / 01.05.2014 /ma
Seite 20 von 59
Muster Datendokumentation und Nachführungskonzept
TABLE Bemassung_Linie =
Objekt: -> Baulinien;
!! Beziehung 1-mc
Geometrie: POLYLINE WITH (STRAIGHTS, ARCS) VERTEX LKoord;
Mass: OPTIONAL DIM1 0.00 100.00; !! in Meter, zwingend bei Bemassungslinie
LinArt: OPTIONAL (Bemassungslinie,
Hilfslinie) // undefiniert = Bemassungslinie//;
NO IDENT
END Bemassung_Linie;
TABLE Bemassung_Pos =
Objekt: -> Bemassung_Linie;
!! Beziehung 1-mc
TextPos: LKoord;
TextOri: OPTIONAL SchriftOri // undefiniert = 100.0 //;
TextHAli: OPTIONAL HALIGNMENT // undefiniert = Center //;
TextVAli: OPTIONAL VALIGNMENT // undefiniert = Half //;
SchriftSize: OPTIONAL SchriftSize // undefiniert = mittel //;
NO IDENT
END Bemassung_Pos;
TABLE Beschriftung_Text =
Objekt: -> Baulinien;
!! Beziehung 1-mc
Text: TEXT*200;
TextPos: LKoord;
TextOri: OPTIONAL SchriftOri // undefiniert = 100.0 //;
TextHAli: OPTIONAL HALIGNMENT // undefiniert = Center //;
TextVAli: OPTIONAL VALIGNMENT // undefiniert = Half //;
SchriftSize: OPTIONAL SchriftSize // undefiniert = mittel //;
NO IDENT
END Beschriftung_Text;
END Baulinien. !! End TOPIC
END Baulinien_LU_02. !! End MODEL
FORMAT FIX WITH LINESIZE = 255, TIDSIZE = 12;
CODE
BLANK = DEFAULT, UNDEFINED = DEFAULT, CONTINUE = DEFAULT;
TID = I32;
END.
4.2 / 01.05.2014 /ma
Seite 21 von 59
Muster Datendokumentation und Nachführungskonzept
9 ANHANG II: Namenskonventionen
9.1 Grundlage
In einem komplexen Geographischen Informationssystem werden grosse Mengen an Daten
verwaltet. Deshalb sind Namenskonventionen eine unabdingbare Voraussetzung, um
strukturiertes und transparentes Arbeiten mit GIS-Daten zu gewährleisten. Schwer
verständliche und zufällige Namensgebung für Dateien, Attribute oder Variablen muss
unbedingt vermieden werden, um ein effizientes und unmissverständliches Arbeiten mit
Geodaten in einer vielschichtigen Mehrbenutzerumgebung zu ermöglichen.
Die hier vorliegenden Namenskonventionen für Geodaten sind deshalb zwingend
einzuhalten. Ausserdem empfiehlt es sich, für das Design von Datenbanken Fachleute
beizuziehen. Grundsätzlich gelten für alle Namenskonventionen die folgenden
Rahmenbedingungen:


Umlaute und Sonderzeichen (Ausnahme: Binde- und Unterstrich) sind nicht erlaubt
Leerzeichen in Verzeichnis- oder Dateinamen sind nicht erlaubt
9.2 Nomenklatur für Feature Classes und Shape-Files
Jeder Geodatensatz wird mit einem konventionellen Namen und einem SDE-Namen
bezeichnet. Der konventionelle Name besteht aus den folgenden Elementen:
Themen-Block Umfasst 3 Zeichen, möglichst ohne Zahlen. Gleiche Themenkürzel dürfen
nur verwendet werden, wenn es sich um eine geometrisch neue Version
(Erfassungsmethoden/-grundlagen, Generalisierung, Reklassifizierung
etc.) oder einen anderen Raumausschnitt handelt. Für unterschiedliche
Themen darf nicht dasselbe Kürzel verwendet werden.
Raum-Block
Der Raum-Block besteht aus 4 Zeichen. Er bezeichnet den Perimeter des
Datensatzes und kann aus 4 Buchstaben (Kürzel für Kanton, Amt,
Planungsregion, Gemeinde, Zentralschweiz) oder aus der Nummer des
Kartenblattes der Landestopographie bestehen. Kann der Datensatz
keiner definierten Raumeinheit zugewiesen werden, so wird für den
Raum-Block die nächst höhere Verwaltungseinheit verwendet, in der der
Datensatz vollständig enthalten ist. Für vordefinierte Raumeinheiten siehe
GIS-Handbuch - Verzeichnisse: Raumeinheiten.
Kennzahl
Die Kennzahl bezeichnet die Version des Datensatzes. Sie gibt Auskunft
über verschiedene Generalisierungsgrade, Erfassungsmethoden und grundlagen oder Reklassifizierungen, sofern diese nicht im
Zusammenhang mit einer Nachführung erfolgen.
Bezeichner
Auf die Kennzahl folgt ein zweistelliger Bezeichner für den Feature Typ
des Datensatzes, getrennt durch "_". Die folgende Tabelle legt die zu
verwendenden Endungen für die verschiedenen Feature-Typen fest:
4.2 / 01.05.2014 /ma
Seite 22 von 59
Muster Datendokumentation und Nachführungskonzept
Endung
Feature-Class
_PT
_MP
_LI
_RT
_PY
_ANNO
_V
Feature Typ
Point
MultiPoint
Linie
Route
Polygon
Annotation
SDE-View*
Shapefile
_PT
_LI
_PY
_AN
Beispiele:

STUKTLU0_LI

STUMEIE0_RT Strassennetz mit Routensystem, Gemeinde Meierskappel

GEMKTLU0_PY Gemeindegrenzen als Polygone, ganzer Kanton

GEMAENT0_LI Gemeindegrenzen als Umrisse (Linien), Amt Entlebuch
Strassennetz, ganzer Kanton
Der SDE-Name (z. B. GEO_00100413001) wird von geo intern vergeben. Dieser Name hat
für externe Dienstleister im Normalfall keine Bedeutung.
9.3 Nomenklatur für Attribute, Attribut-Aliase und Attribut-Domänen
Bei der Vergabe von Attributnamen sollten folgende Punkte beachtet werden:

Namen sind stets in Grossbuchstaben zu schreiben und sollten nicht länger als 10
Zeichen (da beim Export von Attribut-Tabellen nach DBF die restlichen Zeichen
abgeschnitten werden), aber dennoch aussagekräftig sein. Abkürzungen sind
ausdrücklich erlaubt. Müssen aus einem Grund längere Feldnamen verwendet werden,
ist darauf zu achten, dass die einzelnen Feldbezeichnungen innerhalb des
Datensatzes (Featureklasse) sich zumindest auf den ersten 10 Stellen unterscheiden
und 25 Stellen nicht überschreiten.
Beispiel:
Feldname:
Auf 10 Stellen gekürzt
Besserer Feldname
BEZEICHNUNG
BEZEICHNUN
BEZ
BEZEICHNUNG_ZUSATZ
BEZEICHNUN
BEZ_ZUS

Gültige Zeichen für Feldnamen sind 0-9, A-Z sowie "_". Umlaute, Leerzeichen und
Bindestriche ("-") sind nicht erlaubt.

Bei zusammengesetzten Feldnamen ist als Trennzeichen ein "_" zu verwenden (Bsp:
STRASS_ID, X_COORD etc.)

In Anhang III findet sich eine Liste mit ausdrücklich nicht erlaubten Feldnamen (z.B.
DATE, GUID, INDEX, JOIN, KEY, NUMBER, PERCENT, PRIMARY, TEXT). Es
handelt sich dabei um in ACCESS, INTERLIS bzw. ORACLE reservierte Feldnamen.
4.2 / 01.05.2014 /ma
Seite 23 von 59
Muster Datendokumentation und Nachführungskonzept

Attribute mit derselben Bedeutung, die in mehreren Datensätzen vorkommen, sind
stets gleich zu schreiben. Die folgende Liste regelt verbindlich Schreibweise, Feldtyp
und Alias einiger häufig vorkommender Attribute:
Attributname
Feldtyp
Alias
Bedeutung
BFS_NR
Short Integer
BFS-Gemeindenummer
BFS-Nummer der Gemeinde
GBPER_CODE
Short Integer
Code Grundbuchperimeter
Code des
Grundbuchperimeters
GBPER_NAME
Text (30)
Grundbuchperimetername
Name des
Grundbuchperimeters
PRZNUMMER
Long Integer
Parzellennummer
Parzellennummer
GEBNUMMER
Text (15)
Gebäudeversicherungsnummer
Gebäudeversicherungsnummer
GEMEINDE
Text (30)
Gemeindename
Name der Gemeinde
PLZ
Short Integer
Postleitzahl
Postleitzahl 4-stellig
ORTSCHAFT
Text (50)
Ortschaftsname
Name der Ortschaft
HOEHE
Double
Höhe ü. Meer [m]
Höhe über Meer
KT
Short Integer
Kantonsnummer
offizielle ID des Kantons
STR_NAME
Text (60)
Strassenname
Strassenname
X_COORD
Double
X-Koordinate
X-Koordinate
Y_COORD
Double
Y-Koordinate
Y-Koordinate
Beispiel:
Folgende Bezeichnungen sind ungültig und durch BFS_NR zu ersetzen:
BFS-NR, BFS, BFSNR, BFS_GEM_NR, GDE_NR, GDENR etc. etc.

Gemeindenamen sollten nur falls unbedingt nötig verwendet werden. Besser sind BFSNummer oder Grundbuchperimeter-Code, da diese auch bei Gemeindefusionen meist
stabil bleiben.

Falls ausser der intern von SDE vergebenen OBJECTID weitere eindeutige
Identifikationsnummern vergeben werden müssen, können diese entweder als
Datensatz-intern oder als global eindeutige IDs definiert werden. Dabei gelten folgende
Namen, Feldtypen und Aliase:
Attributname
Feldtyp
Alias
Bedeutung
UID
Long Integer
Laufnummer
innerhalb des Datensatzes eindeutige ID
UUID
Text (38)
Universally Unique
Identifier
global eindeutige ID
Die IDs dürfen keine instabilen Werte enthalten. Ein instabiler Wert ist z.B. die BFSNummer, weil sie bei Gemeindefusionen ändern kann.

Es werden sog. Grundlage- und erfassungstechnische "Metadaten" definiert, die im
Falle der Verwendung genau gemäss nachfolgender Liste zu übernehmen sind:
Feldname
4.2 / 01.05.2014 /ma
Alias
Feldtyp
Bemerkung
Seite 24 von 59
Muster Datendokumentation und Nachführungskonzept
BASENAME
Bezeichnung
Grundlage
Art Grundlage
Text: 100
Bezeichnung der Grundlage
Ganz-Z: 3
Text: 255
BASESCALE
Bemerkung
Grundlage
Massstab Grundlage
Art der Grundlage als codierte Liste
BASEKIND
Bemerkungen zur Grundlage
BASEORIG
Herkunft Grundlage
Text: 100
Massstab der Grundlage als codierte
Liste BASESCALE
Herkunft, Verfasser der Grundlage
BASEDATE
Datum Grundlage
Datum
Erstellungsdatum der Grundlage
CREAKIND
Art Erfassung
Ganz-Z: 3
CREAPREC
Gleitk.-Z:
3,2
Text: 255
CREABY
DATEOFCREA
CONTPERS
Genauigkeit
Erfassung [m]
Bemerkung
Erfassung
Erstellt durch
Datum Erstellung
Kontaktperson
Erfassungsart der Geometrie
codierte Liste CREAKIND
Erfassungsgenauigkeit in Metern
-99.99 = unbekannt
Bemerkungen zur Erfassung
Text: 50
Datum
Text: 255
Name erstellende(s) Person / Büro
Erstellungsdatum des Objekts
Name, Adresse, E-Mail, Telefon
CONTDATE
Datum Kontakt
Datum
Datum des Kontaktes
CHNGCOM
Bemerkung
Änderung
Geändert durch
Grund Änderung
Text: 255
Bemerkungen zu Änderungen
Text: 50
Ganz-Z: 3
Datum
letzte
Änderung
Datum
Geometrieänderung
Datum
Name der ändernden Person
Grund der letzten Änderung als codierte
Liste CHNGWHY
Datum der letzten Änderung am Objekt
BASEKIND
BASECOM
CREACOM
CHNGBY
CHNGWHY
DATEOFCHNG
DATEOFGEOM
Ganz-Z: 8
Datum
als
Datum der letzten Änderung an der
Geometrie
Dazugehörige codierte Listen:
BASEKIND Art Grundlage
Code
Wert
1
Amtliche Vermessung (AV 93)
2
Amtliche Vermessung (weitere Qualitätsstandards)
3
Übersichtsplan
4
Landeskarte
5
Orthofoto
6
übrige digitale Daten
7
analoger Plan
8
Koordinatenliste
9
Schema oder Skizze
10
Digitales Terrainmodell (DTM)
11
Digitales Oberflächenmodell (DOM)
4.2 / 01.05.2014 /ma
Seite 25 von 59
Muster Datendokumentation und Nachführungskonzept
97
keine
98
andere
99
unbekannt
BASESCALE Massstab Grundlage
Code
Wert
1
real
50
1:50
100
1:100
200
1:200
500
1:500
1000
1:1‘000
2000
1:2‘000
5000
1:5‘000
10000
1:10‘000
25000
1:25‘000
50000
1:50‘000
100000
1:100‘000
98
andere
99
unbekannt
CREAKIND Art Erfassung
Code
Wert
1
Tachymeter
2
GPS
3
Laserscanning
4
Photogrammetrie
5
Messband
6
digitalisiert
7
geschätzt
8
Koordinatenübernahme
9
prozessiert
10
kopiert
98
andere
99
unbekannt
CHNGWHY Grund Änderung
Code
Wert
1
reale Veränderung
4.2 / 01.05.2014 /ma
Seite 26 von 59
Muster Datendokumentation und Nachführungskonzept

2
verbesserte Grundlage
3
restrukturiert (z.B. gesplittet etc.)
4
korrigiert
99
unbekannt
Metadaten zum Status
Feldname
Alias
Feldtyp
Bemerkung
RECHTSTAT
Rechtsstatus
Ganz-Z: 3
GENEHMDAT
Datum Genehmigung
Datum
Rechtsgrundlage als codierte Liste
RECHTSTAT
Genehmigungsdatum
GUELTIGKEIT
Gültigkeit
Ganz-Z: 3
Gültigkeit
als
GUELTIGKEIT
codierte
Liste
Dazugehörige codierte Listen:
RECHTSTAT Rechtsstatus
Code
Wert
1
in Kraft
2
beschwerdehängig
3
laufende Änderung
99
unbekannt
GUELTIGKEIT Gültigkeit

Code
Wert
1
projektiert
2
gültig
3
vergangen
99
unbekannt
Attribut-Aliase
Grundsätzlich ist sämtlichen Attributen ein Alias zu vergeben. Bei der Wahl der AliasNamen ist man relativ frei, es gilt jedoch wie bei den Attributbezeichnungen, dass Felder
mit derselben Bedeutung auch denselben Alias erhalten müssen. Aliasnamen dürfen nicht
ausschliesslich in Grossbuchstaben geschrieben werden. Zudem ist darauf zu achten, dass
technische Einheiten im Alias in einer eckigen Klammer angegeben werden (Bsp: Leistung
[kW], Brückenhöhe [m]).

Attribut-Domänen
Nach Möglichkeit sind sog. Domänen (eindeutige Wertelisten, Menge der möglichen Werte
für ein Attribut/Feld) zu verwenden, um Eingabefehler wie Doppelnennungen mit
unterschiedlichen Bezeichnungen zu verhindern (siehe Bsp. in Kapitel 8.1) und um die
4.2 / 01.05.2014 /ma
Seite 27 von 59
Muster Datendokumentation und Nachführungskonzept
Datenbankstruktur möglichst schlank zu halten. Domänendefinitionen verhindern, dass
falsche Werte in ein Feld eingegeben werden können und dienen somit auch der
Validierung. Ausserdem erleichtern sie die Auswertung der Daten.
Die Bezeichnung von Attribut-Domänen setzt sich grundsätzlich aus zwei Blöcken
zusammen, getrennt durch "_". Der erste Block entspricht dem thematischen Block des
konventionellen Datensatz-Namens. Der zweite Block entspricht dem Namen des Feldes,
auf dem die Attribut-Domäne definiert ist. Attribut-Domänen werden stets gross
geschrieben:
STU_KLASSE
konventioneller Datensatzname (i.d.R. 3 Zeichen)
Feldname
In gewissen Fällen kann das Zeichen "x" als Platzhalter innerhalb der DomänenBezeichnung verwendet werden. So etwa, wenn eine Attribut-Domäne für mehrere
Datensätze gilt, deren Bezeichnungen des thematischen Blockes sich in maximal einem
Zeichen unterscheiden und die jeweils dieselben Felder haben. Dasselbe gilt bei AttributDomänen, die innerhalb desselben Datensatzes auf verschiedenen Feldern definiert sind.
Beispiele:

Die Datensätze INFKTLU0 und INLKTLU haben beide das Feld "S_BED", auf dem die
Domäne "INx_S_BED" definiert ist. Das "x" ersetzt dabei bei der
Domänenbezeichnung das "F" bzw. "L" im Themenblock des Datensatz-Namens.

Der Datensatz AUSKTLU0 hat die Felder "LF" und "LF2", auf denen jeweils die
Domäne "AUS_LFx" definiert ist. Das "x" in der Domänenbezeichnung weist dabei
darauf hin, dass diese Domäne auf verschiedenen Feldern definiert wurde, die jeweils
mit "LF" beginnen.
Ausnahme:

Bei Domänen, die für völlig unterschiedliche Datensätze und unterschiedliche Felder
gelten, werden sprechende Namen verwendet, welche den Inhalt der Domäne
beschreiben. Beispiele: GBAMT (Grundbuchämter Kt. Luzern), JANEIN_SHORT
(ja/nein), KANTON (Kantonsabkürzungen).
Die Länge der Domänenbeschreibung darf 50 Zeichen nicht überschreiten, empfohlen
werden jedoch maximal 30 Zeichen.
Domänenwerte sollen i.d.R. bei 1 beginnen; ebenso sind nach Möglichkeit die Werte 97, 98,
99 für "keine", "andere", "unbekannt" zu verwenden.
9.4 Nomenklatur für Tabellen
Tabellen, die zur Verknüpfung mit einem spezifischen Datensatz dienen oder anstelle von
Domains als Lookup-Tabellen für die Erstellung eines Views verwendet werden, erhalten
den Namen des Datensatzes bzw. Views, gefolgt von der Endung "_T" und bei Bedarf einer
inkrementellen Nummer.
Beispiel:
4.2 / 01.05.2014 /ma
Seite 28 von 59
Muster Datendokumentation und Nachführungskonzept
BKAKTLU0_T (bzw. BKAKTLU0_T1)
Beinhaltet wichtige Sachdaten zur Feature Class BKAKTLU0 und dient zur Erstellung des
Views BKAKTLU0_V.
4.2 / 01.05.2014 /ma
Seite 29 von 59
Muster Datendokumentation und Nachführungskonzept
10 ANHANG III: Liste der von Datenbanken reservierten
Feldnamen
Folgende Wörter sind von Datenbanken wie Oracle oder Access oder von INTERLIS
reserviert und dürfen nicht als Feldnamen verwendet werden (vgl. Kapitel 9.3):
ABSOLUTE
reserviert von Access
ABSTRACT
reserviert von INTERLIS
ACCESS
reserviert von Oracle
ACCORDING
reserviert von INTERLIS
ACTION
reserviert von Access
ADD
reserviert von Oracle und Access
ADMINDB
reserviert von Access
AGGREGATES
reserviert von INTERLIS
AGGREGATION
reserviert von INTERLIS
ALL
reserviert von Oracle, Access und INTERLIS
ALLOCATE
reserviert von Access
ALPHANUMERIC
reserviert von Access
ALTER
reserviert von Oracle und Access
AND
reserviert von Oracle, Access und INTERLIS
ANY
reserviert von Oracle, Access und INTERLIS
ANYCLASS
reserviert von INTERLIS
ANYSTRUCTURE
reserviert von INTERLIS
APPLICATION
reserviert von Access
ARCS
reserviert von INTERLIS
ARE
reserviert von Access
AREA
reserviert von INTERLIS
AS
reserviert von Oracle, Access und INTERLIS
ASC
reserviert von Oracle und Access
ASSERTION
reserviert von Access
ASSISTANT
reserviert von Access
ASSOCIATION
reserviert von INTERLIS
AT
reserviert von Access und INTERLIS
ATTRIBUTE
reserviert von INTERLIS
ATTRIBUTES
reserviert von INTERLIS
AUDIT
reserviert von Oracle
AUTHORIZATION
reserviert von Access
AUTOINCREMENT
reserviert von Access
AVG
reserviert von Access
BAG
reserviert von INTERLIS
BAND
reserviert von Access
BASE
reserviert von INTERLIS
4.2 / 01.05.2014 /ma
Seite 30 von 59
Muster Datendokumentation und Nachführungskonzept
BASED
reserviert von INTERLIS
BASKET
reserviert von INTERLIS
BEGIN
reserviert von Access
BETWEEN
reserviert von Oracle und Access
BINARY
reserviert von Oracle, Access und INTERLIS
BIT
reserviert von Access
BIT_LENGTH
reserviert von Access
BLACKBOX
reserviert von INTERLIS
BLANK
reserviert von INTERLIS
BNOT
reserviert von Access
BOOLEAN
reserviert von Oracle, Access und INTERLIS
BOR
reserviert von Access
BOTH
reserviert von Access
BXOR
reserviert von Access
BY
reserviert von Oracle, Access und INTERLIS
BYTE
reserviert von Access
CARDINALITY
reserviert von INTERLIS
CASCADE
reserviert von Access
CASCADED
reserviert von Access
CASE
reserviert von Access
CAST
reserviert von Access
CATALOG
reserviert von Access
CHAR
reserviert von Oracle und Access
CHAR_LENGTH
reserviert von Access
CHARACTER
reserviert von Access
CHARACTER_LENGTH
reserviert von Access
CHECK
reserviert von Oracle und Access
CIRCULAR
reserviert von INTERLIS
CLASS
reserviert von INTERLIS
CLOCKWISE
reserviert von INTERLIS
CLOSE
reserviert von Access
CLUSTER
reserviert von Oracle
COALESCE
reserviert von Access
CODE
reserviert von INTERLIS
COLLATE
reserviert von Access
COLLATION
reserviert von Access
COLUMN
reserviert von Oracle und Access
COMMENT
reserviert von Oracle
COMMIT
reserviert von Access
COMP
reserviert von Access
4.2 / 01.05.2014 /ma
Seite 31 von 59
Muster Datendokumentation und Nachführungskonzept
COMPACTDATABASE
reserviert von Access
COMPRESS
reserviert von Oracle
COMPRESSION
reserviert von Access
CONNECT
reserviert von Oracle und Access
CONNECTION
reserviert von Access
CONSTRAINT
reserviert von Access und INTERLIS
CONSTRAINTS
reserviert von Access und INTERLIS
CONTAINER
reserviert von Access
CONTINUE
reserviert von Access und INTERLIS
CONTINUOUS
reserviert von INTERLIS
CONTOUR
reserviert von INTERLIS
CONTRACTED
reserviert von INTERLIS
CONVERT
reserviert von Access
COORD
reserviert von INTERLIS
COORD2
reserviert von INTERLIS
COORD3
reserviert von INTERLIS
CORRESPONDING
reserviert von Access
COUNT
reserviert von Access
COUNTER
reserviert von Access
COUNTERCLOCKWISE
reserviert von INTERLIS
CREATE
reserviert von Oracle und Access
CREATEDATABASE
reserviert von Access
CREATEDB
reserviert von Access
CREATEFIELD
reserviert von Access
CREATEGROUP
reserviert von Access
CREATEINDEX
reserviert von Access
CREATEOBJECT
reserviert von Access
CREATEPROPERTY
reserviert von Access
CREATERELATION
reserviert von Access
CREATETABLEDEF
reserviert von Access
CREATEUSER
reserviert von Access
CREATEWORKSPACE
reserviert von Access
CROSS
reserviert von Access
CURRENCY
reserviert von Access
CURRENT
reserviert von Oracle und Access
CURRENT_DATE
reserviert von Access
CURRENT_TIME
reserviert von Access
CURRENT_TIMESTAMP
reserviert von Access
CURRENT_USER
reserviert von Access
CURRENTUSER
reserviert von Access
4.2 / 01.05.2014 /ma
Seite 32 von 59
Muster Datendokumentation und Nachführungskonzept
CURSOR
reserviert von Access
DATABASE
reserviert von Access
DATE
reserviert von Oracle, Access und INTERLIS
DECIMAL
reserviert von Oracle und Access
DECLARE
reserviert von Access
DEFAULT
reserviert von Oracle, Access und INTERLIS
DEFERRABLE
reserviert von Access
DEFERRED
reserviert von Access
DEFINED
reserviert von INTERLIS
DEGREES
reserviert von INTERLIS
DELETE
reserviert von Oracle und Access
DEPENDS
reserviert von INTERLIS
DERIVATIVES
reserviert von INTERLIS
DERIVED
reserviert von INTERLIS
DESC
reserviert von Oracle und Access
DESCRIBE
reserviert von Access
DESCRIPTION
reserviert von Access
DESCRIPTOR
reserviert von Access
DIAGNOSTICS
reserviert von Access
DIM1
reserviert von INTERLIS
DIM2
reserviert von INTERLIS
DIRECTED
reserviert von INTERLIS
DISALLOW
reserviert von Access
DISCONNECT
reserviert von Access
DISTINCT
reserviert von Oracle und Access
DISTINCTROW
reserviert von Access
DOCUMENT
reserviert von Access
DOMAIN
reserviert von Oracle, Access und INTERLIS
DOUBLE
reserviert von Access
DROP
reserviert von Oracle und Access
ECHO
reserviert von Access
ELSE
reserviert von Oracle und Access
END
reserviert von Oracle, Access und INTERLIS
END-EXEC
reserviert von Access
ENUMTREEVAL
reserviert von INTERLIS
ENUMVAL
reserviert von INTERLIS
EQUAL
reserviert von INTERLIS
EQV
reserviert von Access
ERROR
reserviert von Access
ESCAPE
reserviert von Access
4.2 / 01.05.2014 /ma
Seite 33 von 59
Muster Datendokumentation und Nachführungskonzept
EXCEPT
reserviert von Access
EXCEPTION
reserviert von Access
EXCLUSIVE
reserviert von Oracle
EXCLUSIVECONNECT
reserviert von Access
EXEC
reserviert von Access
EXECUTE
reserviert von Access
EXISTENCE
reserviert von INTERLIS
EXISTS
reserviert von Oracle und Access
EXIT
reserviert von Access
EXTENDED
reserviert von INTERLIS
EXTENDS
reserviert von INTERLIS
EXTERNAL
reserviert von Oracle, Access und INTERLIS
EXTRACT
reserviert von Access
FALSE
reserviert von Access
FETCH
reserviert von Access
FIELD
reserviert von Access
FIELDS
reserviert von Access
FILE
reserviert von Oracle
FILLCACHE
reserviert von Access
FINAL
reserviert von INTERLIS
FIRST
reserviert von Oracle, Access und INTERLIS
FIX
reserviert von INTERLIS
FLOAT
reserviert von Oracle und Access
FLOAT4
reserviert von Access
FLOAT8
reserviert von Access
FONT
reserviert von INTERLIS
FOR
reserviert von Oracle und Access
FOREIGN
reserviert von Access
FORM
reserviert von Oracle, Access und INTERLIS
FORMAT
reserviert von INTERLIS
FORMS
reserviert von Access
FOUND
reserviert von Access
FREE
reserviert von INTERLIS
FROM
reserviert von Oracle, Access und INTERLIS
FULL
reserviert von Access
FUNCTION
reserviert von Oracle, Access und INTERLIS
GENERAL
reserviert von Access
GET
reserviert von Access
GETOBJECT
reserviert von Access
GETOPTION
reserviert von Access
4.2 / 01.05.2014 /ma
Seite 34 von 59
Muster Datendokumentation und Nachführungskonzept
GLOBAL
reserviert von Access
GO
reserviert von Access
GOTO
reserviert von Access
GOTOPAGE
reserviert von Access
GRADS
reserviert von INTERLIS
GRANT
reserviert von Oracle und Access
GRAPHIC
reserviert von INTERLIS
GROUP
reserviert von Oracle und Access
GROUP BY
reserviert von Access
GUID
reserviert von Access
HALIGNMENT
reserviert von INTERLIS
HAVING
reserviert von Oracle und Access
HCOORD
reserviert von INTERLIS
HIDING
reserviert von INTERLIS
HOUR
reserviert von Access
I16
reserviert von INTERLIS
I32
reserviert von INTERLIS
IDENT
reserviert von INTERLIS
IDENTIFIED
reserviert von Oracle
IDENTITY
reserviert von Access
IDLE
reserviert von Access
IEEEDOUBLE
reserviert von Access
IEEESINGLE
reserviert von Access
IF
reserviert von Access
IGNORE
reserviert von Access
IMAGE
reserviert von Access
IMMEDIATE
reserviert von Oracle und Access
IMP
reserviert von Access
IMPORTS
reserviert von INTERLIS
IN
reserviert von Oracle, Access und INTERLIS
INCREMENT
reserviert von Oracle
INDEX
reserviert von Oracle und Access
INDEXES
reserviert von Access
INDICATOR
reserviert von Access
INHERITABLE
reserviert von Access
INHERITANCE
reserviert von INTERLIS
ININDEX
reserviert von Access
INITIAL
reserviert von Oracle
INITIALLY
reserviert von Access
INNER
reserviert von Access
4.2 / 01.05.2014 /ma
Seite 35 von 59
Muster Datendokumentation und Nachführungskonzept
INPUT
reserviert von Access
INSENSITIVE
reserviert von Access
INSERT
reserviert von Oracle und Access
INSERTTEXT
reserviert von Access
INSPECTION
reserviert von INTERLIS
INT
reserviert von Access
INTEGER
reserviert von Oracle und Access
INTEGER1
reserviert von Access
INTEGER2
reserviert von Access
INTEGER4
reserviert von Access
INTERLIS
reserviert von INTERLIS
INTERSECT
reserviert von Oracle und Access
INTERVAL
reserviert von Access
INTO
reserviert von Oracle und Access
IS
reserviert von Oracle und Access
ISOLATION
reserviert von Access
JOIN
reserviert von Access und INTERLIS
KEY
reserviert von Access
LANGUAGE
reserviert von Access
LAST
reserviert von Access und INTERLIS
LASTMODIFIED
reserviert von Access
LCOORD
reserviert von INTERLIS
LEADING
reserviert von Access
LEFT
reserviert von Access
LEVEL
reserviert von Oracle und Access
LIKE
reserviert von Oracle und Access
LINE
reserviert von INTERLIS
LINEATTR
reserviert von INTERLIS
LINESIZE
reserviert von INTERLIS
LIST
reserviert von INTERLIS
LNBASE
reserviert von INTERLIS
LOCAL
reserviert von Access und INTERLIS
LOCK
reserviert von Oracle
LOGICAL
reserviert von Access
LOGICAL1
reserviert von Access
LONG
reserviert von Oracle und Access
LONGBINARY
reserviert von Access
LONGCHAR
reserviert von Access
LONGTEXT
reserviert von Access
LOWER
reserviert von Access
4.2 / 01.05.2014 /ma
Seite 36 von 59
Muster Datendokumentation und Nachführungskonzept
MACRO
reserviert von Access
MANDATORY
reserviert von INTERLIS
MATCH
reserviert von Access
MAX
reserviert von Access
MAXEXTENTS
reserviert von Oracle
MEMO
reserviert von Access
METAOBJECT
reserviert von INTERLIS
MIN
reserviert von Access
MINUS
reserviert von Oracle
MINUTE
reserviert von Access
MLSLABEL
reserviert von Oracle
MOD
reserviert von Access
MODE
reserviert von Oracle
MODEL
reserviert von INTERLIS
MODIFY
reserviert von Oracle
MODULE
reserviert von Access
MONEY
reserviert von Access
MONTH
reserviert von Access
MOVE
reserviert von Access
MTEXT
reserviert von INTERLIS
NAME
reserviert von Access und INTERLIS
NAMES
reserviert von Access
NATIONAL
reserviert von Access
NATURAL
reserviert von Access
NCHAR
reserviert von Access
NEWPASSWORD
reserviert von Access
NEXT
reserviert von Access
NO
reserviert von Access und INTERLIS
NOAUDIT
reserviert von Oracle
NOCOMPRESS
reserviert von Oracle
NOT
reserviert von Oracle, Access und INTERLIS
NOTE
reserviert von Access
NOWAIT
reserviert von Oracle
NULL
reserviert von Oracle, Access und INTERLIS
NULLIF
reserviert von Access
NUMBER
reserviert von Oracle und Access
NUMERIC
reserviert von Access und INTERLIS
OBJECT
reserviert von Access
OBJECT
reserviert von INTERLIS
OBJECTS
reserviert von INTERLIS
4.2 / 01.05.2014 /ma
Seite 37 von 59
Muster Datendokumentation und Nachführungskonzept
OCTET_LENGTH
reserviert von Access
OF
reserviert von Oracle und INTERLIS
OFF
reserviert von Access
OFFLINE
reserviert von Oracle
OFOLEOBJECT
reserviert von Access
OID
reserviert von INTERLIS
OLEOBJECT
reserviert von Access
ON
reserviert von Oracle, Access und INTERLIS
ONLINE
reserviert von Oracle
ONONLY
reserviert von Access
OPEN
reserviert von Access
OPENRECORDSET
reserviert von Access
OPTION
reserviert von Oracle und Access
OPTIONAL
reserviert von INTERLIS
OR
reserviert von Oracle, Access und INTERLIS
ORDER
reserviert von Oracle und Access
ORDERED
reserviert von INTERLIS
ORIENTATION
reserviert von Access
ORORDER
reserviert von Access
OTHERS
reserviert von INTERLIS
OUTER
reserviert von Access
OUTPUT
reserviert von Access
OVERLAPS
reserviert von Access und INTERLIS
OWNERACCESS
reserviert von Access
PAD
reserviert von Access
PARAMETER
reserviert von Access und INTERLIS
PARAMETERS
reserviert von Access
PARENT
reserviert von INTERLIS
PARTIAL
reserviert von Access
PASSWORD
reserviert von Access
PCTFREE
reserviert von Oracle
PERCENT
reserviert von Access
PERIPHERY
reserviert von INTERLIS
PI
reserviert von INTERLIS
PIVOT
reserviert von Access
POLYLINE
reserviert von INTERLIS
POSITION
reserviert von Access
PRECISION
reserviert von Access
PREPARE
reserviert von Access
PRESERVE
reserviert von Access
4.2 / 01.05.2014 /ma
Seite 38 von 59
Muster Datendokumentation und Nachführungskonzept
PRIMARY
reserviert von Access
PRIOR
reserviert von Oracle und Access
PRIVILEGES
reserviert von Oracle und Access
PROC
reserviert von Access
PROCEDURE
reserviert von Access
PROJECTION
reserviert von INTERLIS
PROPERTY
reserviert von Access
PUBLIC
reserviert von Oracle und Access
QUERIES
reserviert von Access
QUERY
reserviert von Access
QUIT
reserviert von Access
RADIANS
reserviert von INTERLIS
RAW
reserviert von Oracle
READ
reserviert von Access
REAL
reserviert von Access
RECALC
reserviert von Access
RECORDSET
reserviert von Access
REFERENCE
reserviert von INTERLIS
REFERENCES
reserviert von Access
REFRESH
reserviert von Access
REFRESHLINK
reserviert von Access
REFSYSTEM
reserviert von INTERLIS
REGISTERDATABASE
reserviert von Access
RELATION
reserviert von Access
RELATIVE
reserviert von Access
RENAME
reserviert von Oracle
REPAINT
reserviert von Access
REPAIRDATABASE
reserviert von Access
REPORT
reserviert von Access
REPORTS
reserviert von Access
REQUERY
reserviert von Access
REQUIRED SIGN
reserviert von INTERLIS
RESOURCE
reserviert von Oracle
RESTRICT
reserviert von Access
RESTRICTION
reserviert von INTERLIS
REVOKE
reserviert von Oracle und Access
RIGHT
reserviert von Access
ROLLBACK
reserviert von Access
ROTATION
reserviert von INTERLIS
ROW
reserviert von Oracle
4.2 / 01.05.2014 /ma
Seite 39 von 59
Muster Datendokumentation und Nachführungskonzept
ROWID
reserviert von Oracle
ROWNUM
reserviert von Oracle
ROWS
reserviert von Oracle und Access
SCHEMA
reserviert von Access
SCREEN
reserviert von Access
SCROLL
reserviert von Access
SECOND
reserviert von Access
SECTION
reserviert von Access
SELECT
reserviert von Oracle und Access
SELECTSCHEMA
reserviert von Access
SELECTSECURITY
reserviert von Access
SESSION
reserviert von Oracle und Access
SESSION_USER
reserviert von Access
SET
reserviert von Oracle, Access und INTERLIS
SETFOCUS
reserviert von Access
SETOPTION
reserviert von Access
SHARE
reserviert von Oracle
SHORT
reserviert von Access
SINGLE
reserviert von Access
SIZE
reserviert von Oracle und Access
SMALLINT
reserviert von Oracle und Access
SOME
reserviert von Access
SPACE
reserviert von Access
SQL
reserviert von Access
SQLCODE
reserviert von Access
SQLERROR
reserviert von Access
SQLSTATE
reserviert von Access
START
reserviert von Oracle
STDEV
reserviert von Access
STDEVP
reserviert von Access
STRAIGHTS
reserviert von INTERLIS
STRING
reserviert von Access
STRUCTURE
reserviert von INTERLIS
SUBDIVISION
reserviert von INTERLIS
SUBSTRING
reserviert von Access
SUCCESSFUL
reserviert von Oracle
SUM
reserviert von Access
SURFACE
reserviert von INTERLIS
SYMBOLOGY
reserviert von INTERLIS
SYNONYM
reserviert von Oracle
4.2 / 01.05.2014 /ma
Seite 40 von 59
Muster Datendokumentation und Nachführungskonzept
SYSDATE
reserviert von Oracle
SYSTEM_USER
reserviert von Access
TABLE
reserviert von Oracle, Access und INTERLIS
TABLEDEF
reserviert von Access
TABLEDEFS
reserviert von Access
TABLEID
reserviert von Access
TEMPORARY
reserviert von Access
TEXT
reserviert von Access und INTERLIS
THATAREA
reserviert von INTERLIS
THEN
reserviert von Oracle und Access
THIS
reserviert von INTERLIS
THISAREA
reserviert von INTERLIS
TID
reserviert von INTERLIS
TIDSIZE
reserviert von INTERLIS
TIME
reserviert von Access
TIMESTAMP
reserviert von Access
TIMEZONE_HOUR
reserviert von Access
TIMEZONE_MINUTE
reserviert von Access
TO
reserviert von Oracle, Access und INTERLIS
TOP
reserviert von Access
TOPIC
reserviert von INTERLIS
TRAILING
reserviert von Access
TRANSACTION
reserviert von Access
TRANSFER
reserviert von INTERLIS
TRANSFORM
reserviert von Access
TRANSIENT
reserviert von INTERLIS
TRANSLATE
reserviert von Access
TRANSLATION
reserviert von Access und INTERLIS
TRIGGER
reserviert von Oracle
TRIM
reserviert von Access
TRUE
reserviert von Access
TYPE
reserviert von Access und INTERLIS
UID
reserviert von Oracle
UNDEFINED
reserviert von INTERLIS
UNION
reserviert von Oracle, Access und INTERLIS
UNIQUE
reserviert von Oracle, Access und INTERLIS
UNIQUEIDENTIFIER
reserviert von Access
UNIT
reserviert von INTERLIS
UNKNOWN
reserviert von Access
UNQUALIFIED
reserviert von INTERLIS
4.2 / 01.05.2014 /ma
Seite 41 von 59
Muster Datendokumentation und Nachführungskonzept
UPDATE
reserviert von Oracle und Access
UPDATEIDENTITY
reserviert von Access
UPDATEOWNER
reserviert von Access
UPDATESECURITY
reserviert von Access
UPPER
reserviert von Access
URI
reserviert von INTERLIS
USAGE
reserviert von Access
USER
reserviert von Oracle und Access
USING
reserviert von Access
VALIDATE
reserviert von Oracle
VALIGNMENT
reserviert von INTERLIS
VALUE
reserviert von Access
VALUES
reserviert von Oracle und Access
VAR
reserviert von Access
VARBINARY
reserviert von Access
VARCHAR
reserviert von Oracle und Access
VARCHAR2
reserviert von Oracle
VARP
reserviert von Access
VARYING
reserviert von Access
VERSION
reserviert von INTERLIS
VERTEX
reserviert von INTERLIS
VERTEXINFO
reserviert von INTERLIS
VIEW
reserviert von Oracle, Access und INTERLIS
WCODE
reserviert von Oracle
WHEN
reserviert von Access und INTERLIS
WHENEVER
reserviert von Oracle und Access
WHERE
reserviert von Oracle, Access und INTERLIS
WITH
reserviert von Oracle, Access und INTERLIS
WITHOUT
reserviert von INTERLIS
WORK
reserviert von Access
WORKSPACE
reserviert von Access
WRITE
reserviert von Access
XOR
reserviert von Access
YEAR
reserviert von Access
YES
reserviert von Access
YESNO
reserviert von Access
ZONE
reserviert von Access
4.2 / 01.05.2014 /ma
Seite 42 von 59
Muster Datendokumentation und Nachführungskonzept
11 ANHANG IV: Topologieregeln
Mit dem Begriff Topologie wird eine Reihe räumlicher Integritätsregeln umschrieben, die
das Verhalten räumlicher Objekte und Objektklassen beschreiben. Bei der Erzeugung von
GIS-Datensätzen ist darauf zu achten, dass die Topologie unter Beachtung dieser Regeln
aufgebaut wird, so dass ein fehlerfreier und konsistenter Datensatz entsteht.
In den Kapiteln 11.1 bis 11.6 werden die Kriterien aufgelistet, welche im Rahmen der
Topologie von Bedeutung sind. Bei verwaltungsinternen Projekten, in denen ausschliesslich
mit ESRI-Produkten gearbeitet wird, kann man sich hingegen auf Kapitel 11.7
konzentrieren und in der dortigen Tabelle die für den betreffenden Datensatz geforderten
Topologieregeln definieren.
11.1 Nachbarschaft – Angrenzen – Gebietseinteilung
Folgende Kriterien werden in der Datenbeschreibungssprache auch Gebietseinteilung
genannt, womit eine endliche Menge von (allgemeinen) Flächen und Restflächen, welche
die Ebene überlappungsfrei überdecken, gemeint ist. In INTERLIS beispielsweise steht für
Gebietseinteilungen der geometrische Attributtyp AREA zur Verfügung.

Innerhalb desselben Layers (synonym für räumliche Ebene) dürfen sich Flächen
(=Gebietsobjekte) nicht überschneiden.

vorweisen.

Innerhalb desselben Layers dürfen Linien nicht aufeinander liegen, d.h. redundant
vorkommen (eindeutiges Knoten-Kanten-Modell). Benachbarte Polygone grenzen
durch ein eindeutig definiertes Liniensegment aneinander. Linienzüge einer
Gebietseinteilung müssen immer echte Grenzlinien sein. Es dürfen also keine
Linienzüge existieren, bei denen auf beiden Seiten die gleiche Fläche liegt. Dies ist
auch durch die Definition der Fläche ausgeschlossen.
11.2 Koinzidenz
Die Flächenkonsistenz wird im Knoten/Kanten-Modell mit der Nachbarschafts-Prüfung gewährleistet. Dabei wird geprüft, ob jede Kante auf beiden Seiten eine Fläche hat. Dort, wo
aufgrund des Sachverhalts zu fordern (z.B. Grundstücksgrenze bildet auch gleichzeitig
Begrenzung für ein Objekt) müssen Linien anderer Layer (Grundstücksgrenzen, Bodenbedeckung) deckungsgleich mit den betreffenden Gebietsobjekten sein.
Fast koinzidierende Knoten führen zu Gaps und Overlaps (Lücken und Überlappungen),
was zu vermeiden ist.
A1
K1
A2
P4
P
Punkt / Knoten
K
Kante
A
Fläche
K2
P1
P2
K3
A3
4.2 / 01.05.2014 /ma
P3
K4
A4
Seite 43 von 59
Muster Datendokumentation und Nachführungskonzept
P3 und P4 sind die fast koinzidierenden Knoten. Die Kanten K1-K4 haben nur eine
Nachbarfläche und zwar jeweils A1-A4.
11.3 Konnektivität
Konnektivität bedeutet, dass einzelne Liniensegmente durch Knoten mit den Nachbarsegmenten verbunden sein müssen (z.B. bei Gewässer-, Strassennetzen) um eine
Linienverfolgung gewährleisten zu können. Liniennetze müssen eine Knoten-KantenTopologie aufweisen.
Fehlende Knoten führen zu Lücken mit Fläche 0.
A1
K1
P1
P2
K2
A2
P3
P
Punkt / Knoten
K2,3
korrekte Kante
K1
fehlerhafte Kante
A
Fläche
Läufer
K3
A3
P3 liegt in der Geraden, die durch P1 und P2 geht. P3 ist ein Läufer. K1 hat auf der unteren
Seite keine Nachbarfläche, K2 und K3 haben auf der oberen Seite keine Nachbarfläche.
Die Lücke wird durch die Kanten K1, K2 und K3 gebildet. Sie hat jedoch keine Fläche, weil
P3 ein Läufer ist.
11.4 Abzuleitende Regeln für den Aufbau von GIS-Datensätzen

Die Geometriedaten sind in einem topologisch fehlerfreien Knoten-Kanten-Modell zu
erfassen und aufzubauen.

Zulässig sind nur die Geometrietypen Punkt, Linie und Fläche. Linien und Flächen
dürfen nur aus Geraden und Kreisbögen gebildet werden. Kreisbögen sind ggf. in
segmentierte Linien umzuwandeln (siehe 11.5).

Bei Flächen ist auf geschlossene Polygone zu achten. Sog. 'overlaps', 'overshoots',
'undershoots' bei Linien und sog. 'Sliverpolygone' bei Flächen sind zu eliminieren.
Insbesondere sind bei Linien die Kreuzungspunkte und deren Anschlüsse sowie bei
Polygonen die vollständige Schliessung der Vektorkette fehlerfrei zu bilden. Kreuzende
Linien ohne Zwischenpunkte sowie nicht koordinatengleiche Anschlüsse von zwei sich
berührenden Linien sind nicht zulässig.

Der Datensatz muss in sich eine korrekte, topologische Struktur aufweisen.
Sogenannte „simple features“ (Shapefiles etc.) genügen diesen Anforderungen in der
Regel nicht. Das heisst, dass zumindest der abzuliefernde Datensatz im Originalformat
mit einem GIS-Produkt und in einem Format erzeugt werden muss, das eine Topologie
explizit unterstützt. Ausnahmen müssen klar begründet sein. Für Vorabklärungen sind
vor Projektvergabe geeignete Testdatensätze zur Verfügung zu stellen.

Auf eine klare Strukturierung der thematischen Ebenen ist zu achten. Attribute werden
über einen Primärschlüssel mit der Sachdatenbank verknüpft. Für jedes geometrische
Objekt ist ein eindeutiger Identifikator festzulegen. Für jede Fläche ist genau ein Punkt
festzulegen, der innerhalb der Fläche liegen muss und deren Identifikator trägt. Bei
4.2 / 01.05.2014 /ma
Seite 44 von 59
Muster Datendokumentation und Nachführungskonzept
Linien- und Punktelementen kann der Identifikator direkt angehängt werden. Der
Identifikator verweist auf den Primärschlüssel zur Sachdatenbank.

Wegen der Koinzidenz müssen Flächenbegrenzungen, die von einem vorhandenen
Linien- oder Flächenelement abgeleitet sind, eine exakte Deckung mit diesem Element
im Bereich ihres gemeinsamen Verlaufs aufweisen (z.B. Hoheitsgrenzen, Gewässer,
Strassen und Wege). Andernfalls entstehen räumliche Inkonsistenzen in Form von
sogenannten „Sliverpolygonen“ (kleinste Versatzpolygone).
11.5 Problematik Kreisbögen
In der amtlichen Vermessung werden Kreisbögen für die Abbildung von definierbaren
Krümmungen und Kurven verwendet, z.B. bei Strasseneinmündungen. Kreisbögen (im
Englischen 'circular arcs' - unter diesem Suchbegriff wird man auch in den einschlägigen
Foren der GIS-Software-Hersteller fündig) finden insbesondere in CAD Programmen
Verwendung (AutoCAD, MicroStation etc.) und werden dort z.B. mit Spline-Funktionen
generiert. GIS-Software konnte Kreisbögen lange Zeit nicht unterstützen. Das heisst, dass
bei älteren GIS Dateiformaten insofern Vorsicht geboten ist, da bei der Konvertierung in
diese Formate die Kreisbögen in Liniensegmente ('strokes') umgewandelt werden. Es ist
unschwer nachzuvollziehen, was mit dem Kreisbogen und seiner Lagegenauigkeit
geschieht, wenn z.B. mehrere Umwandlungen zwischen Formaten stattfinden, die
Kreisbögen unterstützen bzw. nicht unterstützen: Es ist mit signifikanten Lageungenauigkeiten zu rechnen.

Dateiformate, die Kreisbögen unterstützen (keine abschliessende Aufzählung) sind:
DWG/DXF, DGN, Geomedia Access Warehouse (> Release 4.00.22.12), ESRI ArcGIS
Geodatabase (> Rev. 8.2).

Dateiformate, die Kreisbögen nicht unterstützen: ESRI Shape (ArcView GIS), ESRI
Exportfile (ARC/INFO Coverage ohne COGO Modul), MapInfo MIF/MID.
Werden Daten, welche Kreisbögen enthalten, in ein Dateiformat konvertiert, das Kreisbögen nicht unterstützt, so ist dieser Vorgang und das verwendete Format zu
dokumentieren. Kann das Softwareprodukt die Länge der Bogensegmente beeinflussen (z.
B. FME), so ist die verwendete Segmentlänge anzugeben.
11.6 Genauigkeit (vgl. auch Kap. 4.1)

Die Lagegenauigkeit muss vor der Erfassung genau definiert werden und möglichst
vielen künftigen Anwendungen genügen, es gilt also auf andere Projekte Rücksicht zu
nehmen und Abhängigkeiten zu beachten. Für ÖREB-Daten wird Parzellenschärfe
verlangt, d.h. als Grundlage sind die Daten der Amtlichen Vermessung zu verwenden.

Attribute charakterisieren eine Entität, einen Entitätstyp, eine Beziehung oder einen
Beziehungstyp in einem Datenmodell. Sie werden dargestellt z.B. als ein alphanumerisches Datenfeld in einer Datenbanktabelle, das ein räumliches Objekt wie einen
Punkt, eine Linie, eine Fläche oder eine Zelle mit einer Eigenschaft beschreibt.
Attribute ergeben zusammen die Sachdaten eines Objektes; sie charakterisieren
dieses Objekt neben seiner Geometrie und Topologie speziell in seiner Bedeutung und
thematischen Aussage.
Als attributive Genauigkeit steht die Übereinstimmung der Information in der
Sachdatenbank mit der Realität, z.B. die Übereinstimmung einer Aussage zur
Bodenbedeckung oder Landnutzung mit den tatsächlichen Verhältnissen vor Ort. Die
Qualität einer attributiven Aussage ist ferner von der Merkmalskala und den daraus
gebildeten Klassen abhängig. Skalen und Klassen sind mit Ihren Definitionen und
Ausprägungen für den Datensatz zu beschreiben.
4.2 / 01.05.2014 /ma
Seite 45 von 59
Muster Datendokumentation und Nachführungskonzept

Die Qualität der räumlichen Information sollte über die ganze Kartenausdehnung und
gemäss den – massstabsabhängigen - definierten Qualitätskriterien homogen sein,
Abweichungen sind zu beschreiben.
11.7 Topologieregeln nach ESRI (Beispiele)
Nachfolgend einige ausgewählte Beispiele wichtiger Topologieregeln für Polygone
(Flächen) und Linien, wie sie mit den ESRI-Produkten formuliert werden können.
Eine vollständige Übersicht findet man unter:
http://esri-germany.de/downloads/papers/TopologyRules_themes.pdf
4.2 / 01.05.2014 /ma
Seite 46 von 59
Muster Datendokumentation und Nachführungskonzept
4.2 / 01.05.2014 /ma
Seite 47 von 59
Muster Datendokumentation und Nachführungskonzept
4.2 / 01.05.2014 /ma
Seite 48 von 59
Muster Datendokumentation und Nachführungskonzept
4.2 / 01.05.2014 /ma
Seite 49 von 59
Muster Datendokumentation und Nachführungskonzept
4.2 / 01.05.2014 /ma
Seite 50 von 59
Muster Datendokumentation und Nachführungskonzept
In nachfolgender Matrix können sowohl für Polygone wie auch für Linien Topologieregeln
definiert werden:
Matrix für Polygone

Matrix für Linien
Keine Überlappung
Keine Dangles
Keine Lücke
Keine Pseudo-Nodes
Enthält Punkte aus
Keine Überlappung mit anderen
Linien
Grenzen überdeckt durch Linien
von
Keine Überlappung mit sich
selbst
Wird überdeckt durch eine Fläche
von
Nur Single-Part
Überlappt sich nicht mit
Punktabstand muss grösser als
Cluster Tolerance sein

Überdeckt sich gegenseitig mit
Punktabstand muss grösser als
Cluster Tolerance sein
4.2 / 01.05.2014 /ma
Seite 51 von 59
Muster Datendokumentation und Nachführungskonzept
12 ANHANG V: Erfassungsrichtlinien
Typische Erfassungsprobleme und deren angestrebte Lösung sollen bildlich dargestellt
werden. Nachfolgende Abbildungen zeigen anhand eines Beispiels auszugsweise, wie die
geometrische Abbildung eines Objektes definiert werden kann.
Beispiel Strassenachsen:
Erfasst wird die Mittelachse der Strassen, was in der Realität ungefähr der weissen
Mittellinie entspricht. Für die Bildung der Mittelachse werden die Topics Liegenschaften,
Bodenbedeckung und Einzelobjekte der amtlichen Vermessung verwendet.
4.2 / 01.05.2014 /ma
Seite 52 von 59
Muster Datendokumentation und Nachführungskonzept
Die Achsenelemente werden als tangentiale Abfolge von Linie, Kreisbogen, Linie, Kreisbogen, etc. erfasst. Im Bereich von Einmündungen und Kreuzungen sind die
Strassenachsen in einzelne Elemente unterteilt (\). Einzig bei kreuzungsfreien Übergängen
wie Brücken, Tunneln und Unterführungen dürfen sich Strassenachselemente kreuzen.
13 ANHANG VI: Flussdiagramme
13.1 Organisatorisches Nachführungsdiagramm, Bsp. NICHT-ÖREB-Daten
1)
Verkehrsverbund
Luzern (VVL)
GIS Kanton
Luzern
2)
3)
Transportunternehmen
5)
4)
Excel-File mit
Attributinformationen
Datensatz Strassen
und Wege UP10
6)
Datensatz Buslinien
7)
Aufschaltung des aktualisierten
Datensatzes auf den Fahrplanwechsel
1. Der VVL fordert die Transportunternehmen auf, geänderte Linienführungen zu melden.
2. Transportunternehmen melden Änderungen an den VVL in Form von Karten. Im
Geoportal unter dem URL http://www.geo.lu.ch/map/grundbuchplan/ können Karten der
4.2 / 01.05.2014 /ma
Seite 53 von 59
Muster Datendokumentation und Nachführungskonzept
3.
4.
5.
6.
7.
von Änderungen betroffenen Gebiete in A4 oder A3 erstellt werden. Darauf können
Mutationen abgebildet werden.
Der VVL übergibt dem GIS Kanton Luzern die Karten mit den Änderungen. Zudem
übergibt er die aktualisierten Attributinformationen zu den Buslinien in Tabellenform.
Mithilfe der gelieferten Tabelle werden die Attributinformationen des Excel-Files
nachgeführt.
Mithilfe der gelieferten Kartenausschnitte werden die Achsen der Buslinien im
Datensatz Strassen und Wege UP10 nachgeführt.
Mit einem FME-Skript kann der neue, aktualisierte Busliniendatensatz erstellt werden
und auf Fehler kontrolliert werden.
Der aktualisierte Busliniendatensatz soll jeweils auf den Fahrplanwechsel den alten
Datensatz ersetzen.
13.2 Organisatorisches Nachführungsdiagramm, Bsp. ÖREB-Daten
4.2 / 01.05.2014 /ma
Seite 54 von 59
Muster Datendokumentation und Nachführungskonzept
Nachführungskonzept Zonenplanung
Datenbezug
GIS-Dienstleister /
Ortsplaner
Archiv
wenn keine Regelung
GIS-Koordinator
Gemeinde
BUWD
rawi
GISKoordinator
RDP
GeoShop
Zonen
plan
ITF
Information
Auftrag
BZR
Word
1
Zuordnungs
tabelle
Vorprüfung
3
Bereinigung
Genehmigungsantrag
Beschlussfassung
2
Öffentliche
Auflage
Zonen
plan
BZR
Druck
Zonen
plan
Bericht
Vorprüfung
BZR
Druck
Zonen
plan
BZR
Druck
Korrekturen aufgrund Einsprachen
Zonen
plan
4
BZR
Druck
Zonen
plan
5
Zonen
plan
BZR
Druck
BZR
Druck
Genehmigungsentscheid
ev. mit Anforderungen
u. Korrekturen
Bestätigung
Zonen
plan
6
BZR
Druck
Zonenplan
Druck/PDF
BZR
Druck/PDF
Beschwerde
Auslieferung
Upload GeoShop
Kopie Bestätigung
Zonen
plan
7
8
4.2 / 01.05.2014 /ma
Zonen
plan
BZR
Word
AV
Daten
ITF
BZR
PDF
Nupla
PDF
Zuordnungs
tabelle
Bestätigung
Zonenplan
PDF
Zonen
plan
BZR
Druck
Zonen
plan
BZR
Druck
Information
BZR
PDF
Zuordnungs
tabelle
Beschwerdeentscheid
Verwaltungs- oder
Bundesgericht
Seite 55 von 59
Muster Datendokumentation und Nachführungskonzept
13.3 Technischer Arbeitsablauf, Bsp. Erfassung Strassenachsen
Der Technische Ablauf der Datenerfassung ist nachvollziehbar darzustellen. Die einzelnen
Objekte im Diagramm sind durchzunummerieren und in der Folge mit ein paar Sätzen zu
beschreiben, ggf. ergänzt mit weiteren Abbildungen oder Screenshots.
Folgendes Beispiel zeigt auszugsweise den Ablauf bei der Erfassung von Strassenachsen
(als Darstellungsmethode könnte z.B. auch der Model Builder von Arc GIS verwendet
werden):
1. Extrahieren der relevanten Achselemente
aus dem alten Datensatz STRUKTLU0
aufgrund eines geeigneten
Operatsperimeters z.B. der
Gemeindegrenze als AchseAlt in eine
Personal Geodatabase z.B. Export.mdb.
2. Überprüfen des Feldes UUID des
Datensatzes AchseAlt und fehlende UUIDs
ergänzen. Zum Generieren der UUIDs
kann das GUID Tool der
ArcGIS/Developper Tools verwendet
werden.
3. Zusammenfügen (Dissolve) der Objekte des
Datensatzes AchseAlt aufgrund des Feldes
UUID in den Datensatz AchseAltUUID.
4. Topologie-Test des Datensatzes Achse.
Es werden eine ClusterTolerance von 0.002
m und folgende Topologie-Regeln verwendet:

Must Not Overlap

Must Not Self-Overlap

Must Be Single Part

Must Not Self-Intersect

Must Not Intersect Or Touch Interior
etc.
4.2 / 01.05.2014 /ma
Seite 56 von 59
Muster Datendokumentation und Nachführungskonzept
14 ANHANG VII: Darstellungsmodell
Darstellungsrichtlinien, Beispiel digitale Baulinien
4.2 / 01.05.2014 /ma
Seite 57 von 59
Muster Datendokumentation und Nachführungskonzept
15 Anhang VIII: Die wichtigsten Vorgaben nochmals in der
Übersicht
15.1 Einstellungen für Arc GIS (siehe auch Kapitel 4.1):




Projektion:
Koordinatensystem:
XY-Resolution:
XY-Tolerance:
Hotine _Oblique_Mercator_Azimuth_Center
GCS_CH1903
0.00005 m
0.0004 m.
Grundsätzlich ist darauf zu achten, bei der Erstellung von Datenmodellen nur folgende
Datentypen zu verwenden:








Datum: Tag.Monat.Jahr
Datum/Zeit: Tag.Monat.Jahr Stunden:Minuten:Sekunden
Text: Zeichenkette alphanumerischer Symbole (Länge ist zu definieren, max. 400)
Ganz-Z n: Ganzzahl mit n Stellen
Gleitk-Z n,m: Gleitkommazahl mit n Stellen, davon m nach dem Komma (Bsp.:
3.456: Gleitk-Z = 4,3)
Polygon: Geometrietyp Fläche (INTERLIS: surface, area)
Polyline: Geometrietyp Linie
Point: Geometrietyp Punkt
Bei Geodaten, welche ausschliesslich verwaltungsintern und mit ESRI-Produkten erstellt
werden, können die Datenmodelle mit folgenden (ESRI-spezifischen) Datentypen definiert
werden:







Long Integer: Ganzzahl zwischen -999‘999‘999 und 999‘999‘999
Short Integer: Ganzzahl zwischen -999 und 999
Double: Gleitkommazahl
Text: Zeichenkette alphanumerischer Symbole (Länge ist zu definieren, max. 400)
Date: Datumsfeld
Date/Time: Datumsfeld mit Zeit
Geometry: Geometrietyp (ESRI: point, line, polygon, multipoint)
Bei der Verknüpfung von Datensätzen ist als Primary Key (Schlüsselfeld) ein Feld des Typs
Long Integer zu verwenden. Nachführungsattribute sind ebenfalls aufzunehmen. Für
codierte Werte müssen Codelisten (sog. Domänen) definiert werden (vgl. Kapitel 8.1).
15.2 Vorgaben Nomenklatur (siehe auch Anhang II):
Attribut-Namen sind stets in Grossbuchstaben zu schreiben und sollten nicht länger als 10
Zeichen sein. Abkürzungen sind ausdrücklich erlaubt. Müssen längere Feldnamen verwendet werden, ist darauf zu achten, dass die einzelnen Feldbezeichnungen innerhalb des
Datensatzes (Featureklasse) sich zumindest auf den ersten 10 Stellen unterscheiden und
20 Stellen nicht überschreiten.

Gültige Zeichen für Feldnamen sind 0-9, A-Z sowie "_". Umlaute, Leerzeichen und
Bindestriche ("-") sind nicht erlaubt.

Bei zusammengesetzten Feldnamen ist als Trennzeichen ein "_" zu verwenden (Bsp:
STRASS_ID, X_COORD etc.)

In Anhang VII findet sich eine Liste mit ausdrücklich nicht erlaubten Feldnamen.
4.2 / 01.05.2014 /ma
Seite 58 von 59
Muster Datendokumentation und Nachführungskonzept

Attribute mit derselben Bedeutung, die in mehreren Datensätzen vorkommen, sind
stets gleich zu schreiben. Verbindliche Vorgeben zu Schreibweise, Feldtyp und Alias
siehe Kap. 9.3.
4.2 / 01.05.2014 /ma
Seite 59 von 59