Praxisbeispiel: Datenbewirtschaftung des Gemeindeverbands REAL

Transkript

1 Datenumfang und -modelle im Bereich Abwasser im Kt. Luzern Raumdatenpool Kanton Luzern 22. November 2012 Praxisbeispiel: Datenbewirtschaftung des Gemeindeverbands REAL Raphael Vonaesch Dipl. Kultur-Ing. ETH

2 Inhalt Inhalt 1. Ausgangslage 2. Teilprojekt REAL 3. «Lessons learned» 4. Weiteres Vorgehen 1

3 1. Ausgangslage ROTHEN- BURG EMMEN ADLIGENS- WIL LUZERN (LITTAU) LUZERN MEGGEN MALTERS KRIENS HORW 2

4 1. Ausgangslage 1. Ausgangslage 8 Verbandsgemeinden 5 Datenlieferanten 4 verschiedene Informatiksysteme 3

5 1. Ausgangslage Häufige Probleme beim Datenaustausch verschiedene Datenformate unterschiedliche Datenstrukturen unvollständige Datensätze unterschiedliche Datenqualität Beispiele Datenstruktur: Eigentümer: Material: GALU, öffentlich, Ö, V, REAL, PVC, Polyvinilchlorid, Kunststoff, 4

6 1. Ausgangslage Gemeinde A Probleme mit Datenaustausch Gemeinde B Schacht-Nr. Y X Deckelhöhe Bemerkung Dimension1 Dimension2 Baujahr Zustand Altitude sur route Altitude sur route siphon à l'entrée Gemeinde D Gemeinde C Schacht-Nr. Y X Deckelhöhe Bemerkung Baujahr Zustand Altitude sur route Altitude sur route siphon à l'entrée

7 1. Ausgangslage Unterschiede bezüglich Format der Daten 6

8 1. Ausgangslage Unterschiede bezüglich Struktur der Daten 7

9 1. Ausgangslage Unterschiede bezüglich Qualität der Daten 8

10 1. Ausgangslage Resultat: Nahtloses Zusammenfügen unmöglich Werkinformationen Leitungskataster Abwasser (SIA /2005) 9

11 1. Ausgangslage 1. Ausgangslage 8 Verbandsgemeinden 5 Datenlieferanten 4 verschiedene Informatiksysteme 2 Transfer-Datenmodelle (Raumdatenpool) Beispiele Vorgabe Raumdatenpool: Eigentümer: Material: Recycling_Entsorgung_Abwasser_Luzern Kunststoff_Polyvinilchlorid 10

12 1. Ausgangslage Sind die Daten einheitlich strukturiert 11

13 1. Ausgangslage...ist das Zusammenfügen viel einfacher Datenaustausch wird mit minimalen Kosten erreicht 12

14 2. Teilprojekt REAL 2. Teilprojekt REAL Ziel: Koordinierte Datenbewirtschaftung klar definierte Vorgaben an die Verbandsgemeinden für Datenabgabe 13

15 2. Teilprojekt REAL 14

16 2. Teilprojekt REAL 15

17 2. Teilprojekt REAL 16

18 2. Teilprojekt REAL Austausch über INTERLIS automatisierte Prüfung der Daten möglich (Pflichtattribute, Datenstruktur) Nutzung bestehender Werkzeuge (Schnittstellen, Checker, Viewer, Geodatenserver, etc.) 17

19 Datenfluss Verbands-GEP REAL, Phase 1 GIS-Dienstleister Peter Stalder Ingenieur AG ITF GIS LK, WI, GEP Datenbank REAL ITF ITF Download Geoshop nach Bedarf Upload Geoshop periodisch Verbandsgemeinden AV-Daten Nutzungsplanung LK WI (GEP) Gefahrenkarten etc. GIS-Dienstleister (Geometer) GIS-Dienstleister (andere) Internet Viewer Online-Check (ITF Fehlerdatei) RDP: GIS: LK: WI: AV: GEP: V-GEP: ITF: Raumdatenpool Geografisches Informationssystem Leitungskataster Werkinformation = LK + zusätzl. Attribute Amtliche Vermessung Genereller Entwässerungsplan Verbands-GEP INTERLIS-Transferdatei = Textdatei mit allen Daten, inkl. Geometrie Transfer RDP-Daten: Daten-Upload (Lieferung) Daten-Download (Bezug) Web-Services (Internet) Ingenieure V-GEP Transfer gemäss Vorgaben aus Datenbewirtschaftungskonzept 18

20 2. Teilprojekt REAL 19

21 3. «Lessons learned» 3. «Lessons learned» Kardinalität (= Anzahl Elemente, welche dem Objekt über eine Beziehung zugeordnet werden können) Prüfung in INTERLIS 1 nur beschränkt möglich 1 1 n 20

22 3. «Lessons learned» 3. «Lessons learned» Kardinalität (= Anzahl Elemente, welche dem Objekt über eine Beziehung zugeordnet werden können) Prüfung in INTERLIS 1 nur beschränkt möglich Objektidentifikation vs. Meldewesen STANDARDOID gemäss INTERLIS 2 Definition stabile und weltweit eindeutige und einmalige Objektidentifikation mit Präfix (8) / Postfix (8) Beispiel: ch10ng19lu

23 3. «Lessons learned» Exkurs TID und OBJ_ID INTERLIS 1 Auszug ILI-Datei: TABLE Gemeinde = OBJ_ID: TEXT*20; Superclass: -> Organisation;!! 1-1 Beziehung Einwohner: OPTIONAL EGW;!! Ständige Einwohner IDENT OBJ_ID; END Gemeinde; Beispiel Transferdatensatz (ITF-Datei): TABL GEMEINDE OBJE ZZZ_GE1036 ZZZ_GE1036 ZZZ_GE Transfer-Id (TID) 22

24 3. «Lessons learned» 3. «Lessons learned» Kardinalität (= Anzahl Elemente, welche dem Objekt über eine Beziehung zugeordnet werden können) Prüfung in INTERLIS 1 nur beschränkt möglich Objektidentifikation vs. Meldewesen (Exkurs TID und OBJ_ID) Vorteile INTERLIS 2 (Auswahl) CLASS SIA405_BaseClass (ABSTRACT) EXTENDS Base.BaseClass = OID AS STANDARDOID; ATTRIBUTE OBJ_ID: TEXT*16; Metaattribute: MANDATORY Metaattribute; UNIQUE OBJ_ID; END SIA405_BaseClass; 23

25 3. «Lessons learned» 3. «Lessons learned» Kardinalität (= Anzahl Elemente, welche dem Objekt über eine Beziehung zugeordnet werden können) Prüfung in INTERLIS 1 nur beschränkt möglich Objektidentifikation vs. Meldewesen (Exkurs TID und OBJ_ID) Vorteile INTERLIS 2 (Auswahl) Superclass Subclass mit Erweiterungen möglich: sogenannte EXTENDS Möglichkeit partieller Aktualisierung von Daten (Update) Standard-OID ist im Modell enthalten und kann mittels Checker geprüft werden 24

26 4. Weiteres Vorgehen 4. Weiteres Vorgehen Bearbeitung Teilprojekt «Anlagenkataster» (Prüfung Datenqualität, Ergänzungen) Definition Vorgaben für GEP-Daten (Vorlagen des VSA: «GEP-Musterpflichtenheft» und «Wegleitung GEP-Daten») Bearbeitung weiterer Teilprojekte des Verbands-GEP REAL (Zustand, Sanierung und Unterhalt; Fremdwasser; Entwässerungskonzept; Massnahmenplan, etc.) 25