Konzeption zum Aufbau eines Geoportals und eines Infrastrukturknotens der Stadt Beelitz. Stand Version 1.0

Transkript

1 Konzeption zum Aufbau eines Geoportals und eines Infrastrukturknotens der Stadt Beelitz Stand Version 1.0

2 Erstellt durch IGGV Ingenieurgesellschaft für Geoinformation und Vermessung mbh Benzstraße 7 b Potsdam Seite 2 von 39

3 Inhaltsverzeichnis 1 Einleitung Ausgangssituation Allgemein Fachanwendung ARCHIKART Projekt-Rahmenbedingungen Zielsetzung Umsetzung Gesamtarchitektur Aufbau eines Infrastrukturknotens Funktionelle Anforderungen Technische Anforderungen Anforderungen an Geodatenhaltung Prozessbeschreibung Aufbau eines Geoportals Funktionelle Anforderungen Technische Anforderungen Prozessbeschreibung Datenbereitstellung aus ARCHIKART Vorbemerkung Technische Realisierung Vorzugsvariante Datenaufbereitung/Digitalisierung Seite 3 von 39

4 5.5.1 Prozessbeschreibung Beschaffung eines DesktopGIS Projektablauf Arbeitspakete/Lieferumfang Zeitplanung Abnahmekriterien Auswirkungen der Maßnahme Organisatorisch Technisch Anlagen Seite 4 von 39

5 Abkürzungen ALB ALK ALKIS AP BE/BB DHHN EFRE EPSG ETL ETRS GDI GIS GPK GSC ILB ISK LGB NKF SHP TUIV-AG WFS WMS WMTS Automatisiertes Liegenschaftsbuch Automatisierte Liegenschaftskarte Amtliches Liegenschaftskatasterinformationssystem Arbeitspaket Berlin/Brandenburg Deutsche Haupthöhennetz Europäischer Fond für regionale Entwicklung European Petroleum Survey Group Geodesy Extract, Transform, Load Europäisches Terrestrisches Referenzsystem Geodateninfrastruktur Geografisches Informationssystem Geoportal-Kommune GeoServiceCenter Investitionsbank des Landes Brandenburg Infrastrukturknoten Landesvermessung, Geobasisinformation Brandenburg (Landesbetrieb) Neues kommunales Finanzmanagement Shape (ESRI-Shape-Format kann als Quasistandard im GIS-Bereich betrachtet werden) Kommunale Arbeitsgemeinschaft Technikunterstützte Informationsverarbeitung im Land Brandenburg Web Feature Service Web Map Service Web Map Tile Service Seite 5 von 39

6 Abbildungen/Tabellen Abbildung 1: Interaktive Kartenanwendung Reitrundweg... 9 Abbildung 2: Skizze der Gesamtarchitektur Abbildung 3: ARCHIKART-Anbindung Variante a) Abbildung 4: ARCHIKART-Anbindung Variante b) Abbildung 5: Gantt-Diagramm zur Zeitplanung Tabelle 1: Prozessablauf Aufbau Infrastrukturknoten Tabelle 2: Prozessablauf Aufbau Geoportal Tabelle 3: Gegenüberstellung ARCHIKART Datenbereitstellung a) und b) Tabelle 4: Prozessablauf Datenaufbereitung/Digitalisierung Seite 6 von 39

7 1 Einleitung Die Stadt Beelitz beabsichtigt, den Aufbau und die Bereitstellung eines Geoportals und Infrastrukturknotens als künftigen Bestandteil der Geodateninfrastruktur Berlin/Brandenburg (GDI BE/BB). Über das Geoportal als interaktive Web-Kartenanwendung wird sich die interessierte Öffentlichkeit und die Verwaltung u. a. über die Bauleitplanung informieren können. Durch den Infrastrukturknoten werden Geodienste (WMS, WFS) zum Beispiel für Architekten, Planer und interne und externe Verwaltung zur Nutzung in entsprechenden Fachanwendungen bereitgestellt. Im Vorfeld wurde durch die Stadt Beelitz hierzu ein Antrag auf Zuwendungen nach der GDI- EFRE-Förderrichtlinie des Landes Brandenburg gestellt. Eine Bewilligung dieses Antrages liegt vor. Diese Konzeption soll die konkrete Umsetzung des technischen Aufbaus von Geoportal und Infrastrukturknoten vorbereiten und ermöglichen. Es werden Ansätze dargestellt und Anforderungen festgelegt, die die Projektrealisierung ermöglichen. 2 Ausgangssituation 2.1 Allgemein Die Stadtverwaltung Beelitz besteht aus den Organisationseinheiten Bauamt, Hauptamt, Kämmerei, Liegenschaften und Ordnungsamt. Seite 7 von 39

8 Das Intranet der Stadtverwaltung ist eine mit VMware virtualisierte Umgebung mit ca. 8 virtuellen Maschinen. Die jeweiligen Arbeitsplätze verfügen über Dual Core PCs und 22 Zoll- Monitore. Die Arbeitsplatzrechner werden derzeit von Windows XP auf Windows 7 umgestellt. Als Browser kommen der Internet Explorer und Mozilla Firefox zum Einsatz. Die Browser sind so konfiguriert, dass eine Aktualisierung der Browser bei entsprechenden Updates automatisch erfolgt. Die Stadtverwaltung nutzt als sogenannte Office-Anwendung Microsoft Office 2007 einschließlich Outlook. Auf der Homepage der Stadt Beelitz wird bereits unter der Rubrik Tourismus zum Thema Reitrundweg mit der freien Software Mapbender eine interaktive Kartenanwendung betrieben. Seite 8 von 39

9 Abbildung 1: Interaktive Kartenanwendung Reitrundweg Aufgrund fehlender vertraglicher Grundlagen zur Aktualisierung, Pflege und zum Hosting dieser Kartenanwendung ist ein Einsatz in der GDI Beelitz nicht möglich. Darüber hinaus erfüllt Mapbender sowohl technisch als auch funktionell nicht den Anforderungen in der GDI Beelitz. Beispielhaft wird hier die fehlende kombinierte WMS- und WFS-Bereitstellung aus der Anwendung heraus über eine grafische Benutzeroberfläche genannt. 2.2 Fachanwendung ARCHIKART Als zentrale Fachanwendung wird in der Stadtverwaltung die Software ARCHIKART der ARCHIKART Software AG eingesetzt. ARCHIKART ist eine Software für eine liegenschaftsbezogene Vorgangsbearbeitung. Die verschiedenen Organisationseinheiten der Stadtverwal- Seite 9 von 39

10 tung können somit einen zentralen Datenbestand, eine MySQL-Datenbank, nutzen. Für verschiedenste Anwendungsfälle sind entsprechende Eingabe-, Auswerte- und Recherchemöglichkeiten vorhanden. Die Stadtverwaltung verfügt mit der Software ARCHIKART über eine sogenannte Stadtlizenz. Somit sind alle ARCHIKART-Anwendungen aus den Bereichen Liegenschaften, Bau, Umwelt, NKF, Verkehr und Facility Management ohne Begrenzung der Anwenderzahl nutzbar. Darüber hinaus steht mit der Stadtlizenz die Kartenanwendung ARCHIKART-Karthago zur Verfügung. ARCHIKART-Karthago besteht im Wesentlichen aus einem WebGIS-Client und einem Karten- Server, der die entsprechenden Kartendienste für den Client im Intranet ausliefert. Die Stadtverwaltung nutzt in ARCHIKART derzeit noch ALK- mit ALB-Daten. Eine Umstellung auf ALKIS wird in Kürze erfolgen. Die ALKIS-Daten werden dann in einem vierteljährlichen Turnus aktualisiert. 3 Projekt-Rahmenbedingungen Die Rahmenbedingungen für die Projektrealisierung werden wesentlich durch die GDI- Förderrichtlinie sowie den Zuwendungsbescheid des Zuwendungsgebers ILB vom bestimmt. Demnach ist auf Grundlage des Antrages der Stadt Beelitz (Eingangsdatum bei der ILB: ) das Vorhaben bewilligt. Beantragt wurde durch die Stadt Beelitz als Gegenstand der Förderung 1) Vergabeleistungen für die Konzeption und den technischen Aufbau von Infrastrukturknoten, Geoportalen und Geodiensten, Seite 10 von 39

11 2) Vergabeleistungen zur GDI-konformen Aufbereitung von digitalen Daten mit Raumbezug 3) Vergabeleistungen zur Digitalisierung von lediglich analog vorliegenden Informationen mit Raumbezug Mit der detaillierten Projektbeschreibung der Stadt Beelitz werden die o. g. Fördergegenstände weiter spezifiziert. Zur Konzeptionserstellung lag die Fassung vom vor. Bei der LGB liegt allerdings der Stand vor. Das Vorhaben ist gemäß Zuwendungsbescheid bis zum durchzuführen (Investitionszeitraum). Weiterhin hat die Stadt Beelitz mit Schreiben vom erklärt, dass sie dem von der LGB vorgelegten Kriterienkatalog vom verbindlich zustimmt. Demnach ist Soft- und Hardwarebeschaffung nicht ausgeschlossen. Es wird empfohlen, dass die Stadtverwaltung zur Vervollständigung der eigenen Unterlagen die aktuelle Antragsfassung in Kopie z. B. bei der LGB anfordert. 4 Zielsetzung Die Zielsetzung des Projektes wird zunächst ausführlich durch die Leistungsbeschreibung Informationsportal der Stadtverwaltung Beelitz vom beschrieben und nachfolgend zusammengefasst: 1. Aufbau eines Infrastrukturknotens 2. Aufbau eines Geoportals 3. Einbeziehung von ARCHIKART in die Software-Architektur der GDI Beelitz 4. Datenaufbereitung und Digitalisierung einschließlich Überführung der Bauleitplanung nach XPlanGML 5. Anschaffung eines DesktopGIS einschl. XPlanGML und SHP-Schnittstelle Aufgrund entsprechender Abstimmungen sind folgende Punkte ausdrücklich keine Ziele des Projektes Seite 11 von 39

12 Herstellung eines Parallelsystems zu ARCHIKART Herstellung von komplexen Fach- und Funktionsmodulen (vgl. Leistungsbeschreibung vom ) 5 Umsetzung 5.1 Gesamtarchitektur Zum allgemeinen Verständnis wird zunächst nachfolgend die gesamte Architektur der zukünftigen GDI Beelitz skizziert. Zentrales Thema des hier beschriebenen Projektes ist die Bereitstellung ausgewählter verwaltungsinterner Daten, möglichst unmittelbar, aus der zentralen Datenbank von ARCHIKART. Abbildung 2: Skizze der Gesamtarchitektur Die in Abbildung 2 abstrahierte Skizze der Gesamtarchitektur verdeutlicht, dass verwaltungsintern ARCHIKART unverändert genutzt wird. Seite 12 von 39

13 Zukünftig soll zusätzlich der aufzubauende ISK Geodienste der Stadt Beelitz bereitstellen. Die jeweils zugrunde liegenden Daten sollen bei Verfügbarkeit aus der zentralen Datenbank von ARCHIKART bereitgestellt werden. Unabhängig davon werden die Daten der Bauleitplanung auf dem ISK vorgehalten. Außerdem soll zusätzlich der Karten-Server von ARCHIKART in die Lage versetzt werden, Kartendienste öffentlich verfügbar zu machen. Ein Ansatz zur Realisierung wird unter Punkt 5.4 dargestellt. Das Geoportal ermöglicht als webbasierter Karten-Viewer die dynamische Abfrage und Anzeige von Kartendiensten, die vom ISK der Stadt Beelitz oder von anderen Stellen, z. B. der LGB bereitgestellt werden. Für den Aufbau des ISK und des Geoportals wird die Software Geoportal-Kommune 1 empfohlen. Hiermit wird eine Nachnutzung EFRE-geförderter Ergebnisse realisiert. 5.2 Aufbau eines Infrastrukturknotens Die Aufgabe des Infrastrukturknotens ist primär die Erzeugung und Bereitstellung von standardisierten Geodiensten. Diese so genannten OGC Webservices können dann in Geoportale oder externe Fachanwendungen eingebunden werden. Inhaltliche Grundlage der Webservices bilden die aufbereiteten kommunalen Geodaten. Aus technischer Sicht kommt eine komplexe Serverinfrastruktur zum Einsatz. Für ihren Aufbau wird die Nachnutzung des Geoportals-Kommune empfohlen Funktionelle Anforderungen Der kommunale Infrastrukturknoten sollte die nachfolgenden Funktionalitäten bieten. Für seine Konfiguration ist eine einfache und komfortable (grafische) Benutzeroberfläche hilfreich. Aufgrund der engen Verknüpfung mit dem ebenfalls aufzubauenden Geoportal wird hier eine gemeinsame, übergreifende Verwaltung empfohlen (vgl. Punkt 5.3.1). 1 Seite 13 von 39

14 Visualisierung von Geodaten Die aufbereiteten kommunalen Geodaten sind mit Hilfe eines Web Mapping Service (WMS) in Kartenform zu visualisieren. Zu berücksichtigen sind u. a. die aktuell geforderten Standards gemäß Geoservice Application Profile (GAP), Masterplan für den Aufbau der Geodateninfrastruktur Berlin/Brandenburg und Architekturkonzept (Architektur der Geodateninfrastruktur Deutschland Version 2). Sofern möglich und sinnvoll, sollte für die grafische Darstellung die Orientierung an verbindlichen Zeichenkatalogen (z.b. PlanzV) erfolgen. Weiterhin wird der Einsatz von Visualisierungstechniken wie z. B. Styled Layer Descriptor (SLD) empfohlen. Auslieferung von Geodaten Eine Auslieferung von Geodaten ist standardisiert durch einen Web Feature Service (WFS) möglich. Geoobjekte sind im Format Geography Markup Language (GML) abzugeben. Zu berücksichtigen sind u. a. die aktuell geforderten Standards gemäß GAP, Masterplan und Architekturkonzept Version 2. Abfrage von Sachdaten Per WMS visualisierte Geodaten können innerhalb der Kartengrafik über den Aufruf GetFeatureInfo abgefragt werden. Die entsprechenden Sachdaten sind daraufhin zurückzugeben. Bereitstellung von Metadaten Neben den innerhalb der Geodatenaufbereitung erfassten Metadaten müssen auch zu Geodiensten und Geoanwendungen Metadaten erfasst und bereitgestellt werden. Es sind die Standards ISO und entsprechend dem Brandenburgischen Profil zu beachten. Auch hier können die im Rahmen der GDI-BE/BB kostenfrei zur Verfügung gestellten Werkzeuge ProMIS-Online und GeoMIS genutzt werden. Der kostenintensive Aufbau und Betrieb eines eigenen Metadatenkatalogservers inklusive der Entwicklung einer voll funktionsfähigen Suchmaschine wird abweichend von der GDI-EFRE-Antragstellung für die begrenzte Anzahl an Datenbeständen nicht empfohlen. Aufgrund derzeit noch eingeschränkter Ver- Seite 14 von 39

15 knüpfungsmöglichkeiten zwischen dem kommunalen Infrastrukturknoten und den extern bereitgestellten Metadaten sowie zur Performance-Optimierung, ist zusätzlich die direkte Integration von ausgewählten Metadatenelementen in Geodiensten sinnvoll. Der Zugriff kann mittels GetCapabilities-Aufruf erfolgen. So bereitgestellte Metadaten können per Importschnittstelle in den zentralen Metadatenkatalog des Landes überführt werden, so dass eine Doppelerfassung weitgehend vermieden wird Technische Anforderungen Für den Aufbau und Betrieb des Infrastrukturknotens wird ein im Internet verfügbarer Rootserver benötigt. Neben der ISK-Funktionalität wird in einer einfachen Ausbaustufe die gleichzeitige Nutzung als Geoportalserver empfohlen. Hard-/Software Hardwareseitig sollten Komponenten aus dem professionellen Serverbereich zum Einsatz kommen. Für eine mögliche Konfiguration werden die folgenden, durchschnittlichen Eckwerte aufgeführt: 1 oder 2 Vierkernprozessoren, 4-8 GB Arbeitsspeicher, 4 Festplatten je MB, davon 3 im Verbund (RAID 5). Die Softwareausstattung des Rootservers soll neben Betriebssystem und Webserver spezielle GDI-Softwarekomponenten umfassen, die u. a. die Bereitstellung der OGC Web Services übernehmen (z.b. MapServer). Für das Betriebssystem und zugehörige Software sind in regelmäßigen Zyklen Aktualisierungen einzuplanen. Dies kann monats- oder quartalsweise erfolgen. Sicherheitsrelevante Updates sollten kurzfristig eingespielt werden. Der Rootserver ist durch ein professionelles Firewallsystem zu sichern. Optional kann der Webserver über eine semantische Web Application Firewall geschützt werden. Hierdurch wird der direkte und unbefugte Zugriff auf die Geodienste und im Besonderen auf die Geodaten unterbunden. Dies ist derzeit noch nicht zwingend erforderlich, kann jedoch in einer weiteren Ausbaustufe, z.b. bei zusätzlicher Einbindung von sensiblen Daten und Diensten, notwendig Seite 15 von 39

16 werden. Weiterhin sind die Empfehlungen der IT-Grundschutzkataloge des Bundesamtes für Sicherheit in der Informationstechnik (BSI) zu berücksichtigen, um ein entsprechendes Maß an Sicherheit zu gewährleisten. Betrieb Für den Betrieb des Infrastrukturknotens (ISK) bzw. des Rootservers gibt es verschiedene Nutzungsmodelle. Ein Hosting" basiert häufig auf einem Komplettangebot mit Hardware zur Miete, während ein Housing" die Möglichkeit bietet, ein eigenes, selbstkonfiguriertes System in das Netzwerk zu integrieren. Standort ist in den meisten Fällen ein Rechenzentrum mit entsprechender Anbindung. Der Betrieb kann bei entsprechender Fachkenntnis in Eigenleistung oder durch einen externen Dienstleister erfolgen. Das Lastverhalten und das erzeugte Traffic-Volumen werden für den anfänglichen Betrieb als gering eingeschätzt. In weiteren Ausbaustufen und zu einem späteren Zeitpunkt kann es hierbei jedoch zu einer starken Erhöhung kommen, sofern die komplette Geodatennutzung und -bereitstellung der Stadt online bzw. serverseitig erfolgt (z.b. Bereitstellung von hochauflösenden Befliegungen per OWS). In der Stadtverwaltung Beelitz wäre theoretisch der Betrieb auf einer virtuellen Maschine oder dedizierten Server möglich. Allerdings wird hiervon im Rahmen dieser Konzeption aus wirtschaftlicher Sicht abgeraten. Neben ggf. zusätzlichen Energiekosten und der einhergehenden Umweltbelastung steht bei der v. g. Empfehlung primär der Arbeitsaufwand bei zukünftigen Softwareaktualisierungen im Vordergrund. Dabei ist zu beachten, dass das Geoportal-Kommune auf frei verfügbare Software-Module und Bibliotheken zurückgreift und bei Aktualisierungen zwingend Abhängigkeiten der jeweiligen Module und Bibliotheken untereinander zu berücksichtigen sind. Für den potentiellen Administrator, der nur sporadisch mit diesem Problem konfrontiert wird, kann der Aktualisierungsprozess äußerst zeitaufwändig werden. Somit wird Hosting bei einem Dienstleister empfohlen Anforderungen an Geodatenhaltung Geodaten können je nach Bedarf im Dateisystem oder einer Datenbank abgelegt sein. Bei Verwendung bzw. Nachnutzung von GDI-Softwarekomponenten ist auf Kompatibilität bzw. Seite 16 von 39

17 entsprechende Schnittstellen zu achten. Als unproblematisch erweisen sich häufig für Vektordaten das Format SHP und für Rasterdaten das Format TIF, die für viele Anwendungsfälle ausreichend sind. Für datenbankgestützte Geoinformationen ist ein zusätzlicher Datenbankserver zu installieren. Unterstützung von XPlanung Neben den einfach strukturierten Geodatensätzen, für die eine OWS-Bereitstellung im Rahmen einer GDI ohne Einschränkungen realisiert werden kann, stellt die Unterstützung von Geodaten der Bauleitplanung im XPlan-Standard einen Spezialfall dar. Da die direkte Integration und Auslieferung von XPlanGML 3.0 in OGC Webservices (OWS) aufgrund der Komplexität des XPlan-Datenmodells und noch fehlender Anwendungskomponenten derzeit nur eingeschränkt möglich ist, wird eine Vereinfachung der entsprechenden Datenstrukturen empfohlen. Zur Nachnutzung bietet sich hierfür ein universelles Datenmodell (UDM) an, das als Ergebnis einer Fördermaßnahme der Gemeinde Nuthetal entwickelt wurde und die einfache Bereitstellung von XPlanung über Infrastrukturknoten per OWS und damit deren weitere Einbindung in Geoportale oder externe Fachanwendungen ermöglicht. Bestandteil dieses Datenmodells ist die Konvertierung von XPlanGML-Datensätzen in vereinfachte Datenbankabfragen. Die Abfragen werden innerhalb einer räumlichen Datenbank ausgeführt und enthaltene Informationen in einem speziellen Schema abgelegt. Als Datenbanksystem wird PostgreSQL/PostGIS genutzt, welches sich sehr gut im GDI-Umfeld einbinden lässt. In weiteren Schritten kann ein Geodienst aufgebaut werden, der die entsprechende Geodatenbank als Quelle nutzt und alle thematischen Ebenen mit ihren Geometrien sowie verknüpfte Sachdaten bereitstellt. Seite 17 von 39

18 5.2.4 Prozessbeschreibung Der Infrastrukturknoten der Stadt Beelitz soll durch einen Dienstleister extern aufgebaut und betrieben werden. Der Prozessablauf ist in der folgenden Übersicht zusammengefasst. Nach erstmaliger Einrichtung und Konfiguration der notwendigen Systemkomponenten und Geodienste kann der laufende Betrieb einschließlich der System- und Datenpflege beginnen. Sobald ein stabiler Betrieb gewährleistet werden kann, sind alle kommunalen Geodienste des Typs WMS im Geoportal Brandenburg gemäß GDI-Vorgabe zu registrieren und zu kategorisieren. Das Registrieren von Geodiensten des Typs WFS im Geoportal Brandenburg ist derzeit technisch noch nicht möglich und muss zu einem späteren Zeitpunkt sowie bei Realisierung entsprechender Funktionalitäten nachgeholt werden. Das aufzubauende Geoportal (vgl. Punkt 5.3) und der zugehörige Infrastrukturknoten sollten innerhalb der GDI BE/BB als regionales Fachportal publiziert werden. Hierzu genügt eine entsprechende Mitteilung an das GeoServiceCenter (GSC). Lfd. Nr. Wer Was 1 Stadt Beauftragung eines Dienstleisters mit dem Aufbau eines ISK 2 Dienstleister Einrichtung und Konfiguration des Serversystems (Root-Server u. Internet-Komponenten) 3 Dienstleister Konfiguration ISK-Software, OWS Server Konfiguration Datenhaltung o Transformation XPlanGML3 in universelles Datenmodell (UDM) o Einrichtung der Datenbank und Import o Einrichtung des Verzeichnissystems Konfiguration Geodienste o Erstellung der Geodienste o Visualisierung angelehnt an PlanzV o thematische Visualisierung Seite 18 von 39

19 Lfd. Nr. Wer Was o Erfassung von Metadaten (Typ Service ) o Registrierung im Geoportal Brandenburg Qualitätsprüfung 4 Stadt Abnahme des kompletten Geoportals mit allen Bestandteilen. 5 Dienstleister Betrieb des Geoportals einschließlich Laufendhaltung Tabelle 1: Prozessablauf Aufbau Infrastrukturknoten 5.3 Aufbau eines Geoportals Das Geoportal soll den einfachen Online-Zugriff auf das Geoinformationsangebot der Stadt Beelitz bieten. Durch seinen Aufbau soll der bestehende Online-Auftritt fachlich ergänzt werden. Hierfür ist das Geoportal-Template Geoportal-Kommune zu verwenden Funktionelle Anforderungen Ein Geoportal bindet die vom Infrastrukturknoten ausgehenden Geodienste in eine einfache und komfortable Oberfläche ein und macht sie somit nutzbar. Hierfür werden mehrere Portalbestandteile benötigt. Den übergeordneten Rahmen für das aufzubauende Geoportal soll ein einfaches CMS (Content Management System) bilden, welches die einzelnen Bestandteile vereint und die Pflege durch den Administrator/Sachbearbeiter ermöglicht. Die optische Gestaltung ist an den kommunalen Gestaltungsstil (Corporate Identity) anzulehnen. Die wichtigsten Bestandteile eines Geoportals einschließlich der jeweiligen Funktionen werden nachfolgend beschrieben. Kartenanwendung Die Kartenanwendung ist der zentrale Bestandteil des Geoportals. Sie zeigt mit Hilfe einer OWS-Schnittstelle (WMS) Geoinformationen als Kartendarstellung im Webbrowser des Anwenders. Falls noch nicht im Geoportal verfügbar, ist die Einbeziehung des WMTS-Standards in die v. g. OWS-Schnittstelle einzubeziehen. Seite 19 von 39

20 Grundlegende Funktionen, die dem Anwender zur Verfügung stehen sollen, sind: individuelle Anpassung der Kartenansicht wie z.b. Zoom, Pan, Maßstabswahl, Suche nach Adressangaben, Werkzeuge zur Ermittlung von Strecken und Flächen, Werkzeuge zur Abfrage von verknüpften Sachinformationen, Legendeninformationen, Druckfunktion. Für die Strukturierung des Informationsangebotes in Form verfügbarer Kartenthemen wird der Einsatz entsprechender Bedienelemente wie z.b. Baumstrukturen etc. empfohlen. Für die einzelnen Werkzeuge und Funktionen sollen leicht verständliche Buttons und Icons genutzt werden. Suchwerkzeuge Das Geoportal soll dem Nutzer einfache Suchwerkzeuge zur Informationsrecherche bereitstellen. Für die oben aufgelistete raumbezogene Suche bzw. die Suche nach Adressangaben ist die Umsetzung einer Gazetteer-Client-Funktionalität auf Basis einer entsprechenden OWS-Schnittstelle (WFS) sinnvoll. Der Client bietet bestimmte Felder für Suchangaben, die z. B. auf im Rahmen der GDI bereitgestellte Gazetteer-Dienste der LGB angewendet werden können, um eine entsprechende Positionierung in der Karte vorzunehmen. Weiterhin wird innerhalb des Geoportals eine zusätzliche Suchmöglichkeit nach Stichworten empfohlen. Diese kann u. a. die internen Metadaten der Geodienste und hier speziell Titel, Kurzbeschreibung, Schlüsselwörter etc. auswerten und entsprechende Ergebnisse auf Wunsch in der Karte anzeigen. Sonstige redaktionelle Portalinhalte Neben den raumbezogenen Inhalten sollte das Geoportal die Möglichkeit bieten, für den Anwender weitere, erläuternde Informationen bereitzustellen. Hierzu zählen z. B. eine kurze Beschreibung der kommunalen Geodateninfrastruktur sowie aktuelle Meldungen zu Datenaktualisierungen oder zum Portalbetrieb. Weiterhin ist neben dem verpflichtenden Impressum eine einfache Möglichkeit der Kontaktaufnahme für Nutzeranfragen vorzuhalten. Seite 20 von 39

21 Um externen Fachanwendern die Integration der kommunalen Geodienste in eigene Anwendungen zu erleichtern, wird die Veröffentlichung einer Auflistung mit allen verfügbaren Geodiensten einschl. GetCapabilities-Aufruf empfohlen. Diese Auflistung ist auch für die einfache Einbindung der vom ISK bereitgestellten Geodienste in andere Fach- oder Verwaltungsportale hilfreich. Benutzerverwaltung Eine sehr einfache Vergabe an Rechten für bestimmte Themen und Nutzer ist innerhalb einer Kartenanwendung relativ einfach umzusetzen. So kann z. B. die Ansicht, der Ausdruck oder die Abfrage eines Themas entsprechend reglementiert werden. Dies stellt jedoch nur eine einfache Zugriffskontrolle dar. Ein umfassender Schutz von Geodiensten erfordert weitreichende Authentifizierungsmechanismen, deren vollständige Unterstützung bislang nur wenige Anwendungen bieten. Sofern ein Zugangsschutz notwendig ist, sind ggf. entsprechende Anpassungen am Geoportal einzuplanen (vgl. Punkt 5.2.2). Portalverwaltung/Administration Die Administration ist das zentrale Konfigurationswerkzeug für das Geoportal. Aufgrund der engen Verknüpfung mit dem ebenfalls aufzubauenden Infrastrukturknoten soll eine gemeinsame, übergreifende Verwaltung eingerichtet werden. Auf Basis eines CMS soll der Administrator/Sachbearbeiter die einfache Möglichkeit erhalten, Portalbestandteile zu konfigurieren sowie raumbezogene und sonstige redaktionelle Inhalte zu erstellen und zu pflegen. Eine komfortable, grafische Benutzeroberfläche mit entsprechender Hilfefunktion ist hierfür wichtige Voraussetzung. Im Detail sollten die folgenden Aufgaben durchgeführt werden können: Anlegen von Geodiensten und Geodatenquellen (ISK), Erfassen von grundlegenden Metadaten (ISK), Anlegen von Geothemen für die Kartenanwendung (Geoportal), Einrichten von Benutzern, Rollen und Rechten (Geoportal), Redaktion von sonstigen Portalinhalten einschl. aktuellen Meldungen, Impressum, Layout (Geoportal). Seite 21 von 39

22 5.3.2 Technische Anforderungen Für den geplanten Aufbau und Betrieb des Geoportals wird die Nutzung im Zusammenhang mit dem ebenfalls aufzubauenden Infrastrukturknoten empfohlen. Der benötigte Rootserver erfüllt somit zwei Funktionen: a) Bereitstellung von OWS als ISK-Server und b) Einbindung von OWS als Geoportalserver. Die oben getroffenen Aussagen zu Anforderungen an Hard-/Software sowie Betrieb sind demnach auch hier zutreffend (vgl. Punkt 5.2.2). Die webbasierte Benutzeroberfläche des Geoportals sollte in einem aktuellen Standardbrowser (Microsoft Internet Explorer, Mozilla Firefox) ohne zusätzliche Erweiterungen lauffähig sein. Um eine entsprechende Akzeptanz beim Nutzer zu erreichen, ist speziell bei der Kartenanwendung auf ein zeitgemäßes Handling und eine möglichst selbsterklärende Bedienung zu achten. Hierfür kann u. a. die Webtechnologie AJAX eingesetzt werden Prozessbeschreibung Das Geoportal der Stadt Beelitz soll im Auftrag durch einen Dienstleister extern aufgebaut und betrieben werden. Der Prozessablauf ist in der folgenden Übersicht zusammengefasst. Nach erstmaliger Einrichtung sowie nach erfolgter Anbindung an den Infrastrukturknoten steht ein fertiges Geoportal einschl. Inhalten und insbesondere den eingebundenen Geodiensten für den Onlinezugriff bereit. Lfd. Nr. Wer Was 1 Stadt Beauftragung eines Dienstleisters mit dem Aufbau eines Geoportals mit folgenden Bestandteilen: Portalverwaltung/Administration (Portalhülle) Kartenanwendung (Viewer) Seite 22 von 39

23 Lfd. Nr. Wer Was Suchwerkzeuge (Gazetteer Client) OWS-Schnittstellen 2 Stadt Festlegung bereitzustellender Daten, Informationen und Dienste Festlegung der grundlegenden Portalstruktur u. -inhalte Festlegung der Funktionalitäten 3 Dienstleister Erstellung eines Prototypen für ein Geoportal und Abstimmung mit dem Auftraggeber Anbindung des Infrastrukturknotens Anlegen von Geothemen für die Kartenanwendung Einrichtung der Benutzerverwaltung Anpassung der Benutzeroberfläche (Corporate Identity), redaktionelle Arbeiten Erfassung von Metadaten (Typ Application ) Registrierung im Geoportal Brandenburg Qualitätsprüfung 4 Stadt Abnahme des kompletten Geoportals mit allen Bestandteilen. 5 Dienstleister Betrieb des Geoportals einschließlich Laufendhaltung Tabelle 2: Prozessablauf Aufbau Geoportal 5.4 Datenbereitstellung aus ARCHIKART Vorbemerkung Eine zentrale Zielsetzung im Projekt ist die Einbeziehung von ARCHIKART in die Software- Architektur der GDI Beelitz. Laut Leistungsbeschreibung vom soll die anzuschaffende Lösung u. a. über eine Schnittstelle verfügen, die eine bidirektionale Sachdatenübergabe zu ARCHIKART ermöglicht. Seite 23 von 39

24 ARCHIKART wird in der Stadtverwaltung Beelitz mit einer MySQL-Datenbank genutzt. Somit wäre technisch mit entsprechenden ETL-Prozessen ein Datenaustausch zwischen der ARCHIKART-Datenbank und der ISK-Datenbank (vgl. Punkt auf Seite 17) realisierbar. Allerdings muss nicht zu Letzt aus Gewährleistungsgründen ein schreibender Zugriff auf die ARCHIKART-Datenbank durch fremde Software ausgeschlossen werden. Demnach wäre alternativ ein ausschließlich lesender Zugriff auf die ARCHIKART-Datenbank möglich. Dabei ist zu beachten, dass das Datenmodell der ARCHIKART-Datenbank weitestgehend normalisiert vorliegen dürfte. Das heißt, dass die Tabellenstruktur so entwickelt wurde, dass Redundanzen in der Datenhaltung vermieden werden. Für den Nutzer relevante Informationen sind dann lediglich durch die Kombination von in Beziehung stehenden Tabellen möglich. So werden letztendlich in ARCHIKART die Informationen für den Nutzer dargestellt. Im Rahmen des GDI-Projektes müsste somit das Datenmodell der ARCHIKART-Datenbank analysiert und ausgewertet werden, um die jeweils erforderlichen Daten für eine Darstellung im Geoportal auszulesen. Dieser Ansatz des lesenden Zugriffs durch ein ETL-Tool muss jedoch aus wirtschaftlicher Sicht verworfen werden, da nicht auszuschließen ist, dass ARCHIKART zukünftig Änderungen im Datenmodell vornehmen wird. Die Folge wäre eine aufwändige Nachführung des ETL-Tools in Anpassung auf das erneuerte Datenmodell. Aufgrund des Risikos, dass langfristig zusätzliche Kosten bei Anpassungen des Datenmodells durch ARCHIKART entstehen, scheidet diese Möglichkeit grundsätzlich aus Technische Realisierung Mit der Konzeptionserstellung ist mit der ARCHIKART Software AG im Rahmen der zeitlich begrenzten Möglichkeiten mit Telefonaten und s eine mögliche technische Realisierung abgestimmt worden. Mit dieser Konzeption wird die Umsetzung zum Datenaustausch zwischen ARCHIKART und Geoportal wie folgt empfohlen. Der Datenaustausch wird ausschließlich von ARCHIKART zum Seite 24 von 39

25 Geoportal realisiert. Ein Datenaustausch in entgegengesetzter Richtung entfällt somit. Für den Datenaustausch von ARCHIKART zum Geoportal kommen zwei Varianten in Frage: a) ARCHIKART stellt Kartendienste bereit, b) Sachdaten werden über den ARCHIKART-eigenen ServerAgent und Geometriedaten als ESRI-Shape-Dateien exportiert. Variante a) Abbildung 3: ARCHIKART-Anbindung Variante a) ARCHIKART-Karthago beinhaltet einen Karten-Server, der bereits heute diverse Karten als WMS für die interne Darstellung in ARCHIKART-Karthago bereitstellt. Nach einer technischen Anpassung wäre dieser Karten-Server in der Lage, den WMS auch für eine öffentliche Nutzung im Geoportal bereitzustellen. Allerdings erfüllt der ARCHIKART-WMS nicht die Anforderungen der GDI BE/BB. So unterstützt der WMS nur ein Bezugssystem und eine Sachdatenabfrage via GetFeatureInfo wird nicht unterstützt. Außerdem stellt der ARCHIKART-Karten- Server keinen WFS bereit. Dennoch lässt sich der ARCHIKART-WMS im Geoportal-Kommune nutzen. Ein entscheidender Vorteil ist hier, dass eine vorgenommene Konfiguration intern und extern genutzt werden kann. Der ARCHIKART-WMS erhält seine Datengrundlage direkt Seite 25 von 39

26 von der ARCHIKART-Datenbank und ist somit permanent aktuell. Bei Bedarf kann für den Dienst eine Standardkonformität hergestellt werden. Der Karten-Server des Geoportals Kommune fungiert zunächst als WMS-Client, um dann als WMS-Server den Dienst z. B. als WMS bereitzustellen. Der ARCHIKART-WMS wird erforderlichenfalls gewissermaßen durch geschleift. Mit der Variante a) ist grundsätzlich der Betrieb des ARCHIKART-Karten-Servers und der parallele Betrieb des Karten-Servers des Geoportals Kommune erforderlich. Einerseits um im Bedarfsfall Standardkonforme Kartendienste aus ARCHIKART zu liefern, andererseits, um z. B. die Bauleitplanung als WMS und WFS bereitzustellen. Zusammenfassung Variante a): Keine Anpassung bei Änderungen des Datenmodells ARCHIKART WMS liefert Daten aus ARCHIKART o Keine Sachdatenabfrage o Entspricht nicht den Anforderungen der GDI BE/BB o Somit Durchschleifen durch GPK erforderlich Kein WFS Darstellung im GPK möglich o Bauleitplanung WMS u. WFS über Karten-Server GPK Der Karten-Server von ARCHIKART ist in der Stadtlizenz (vgl. Punkt 2.2) bereits enthalten. Für die Bereitstellung externer Kartendienste ist zusätzlicher Konfigurationsaufwand einzuplanen (vgl. Punkt 7.1 Arbeitspakete). Variante b) ARCHIKART bietet die Möglichkeit über das Softwaremodul ServerAgent Sachdaten auszutauschen. Mit dem ARCHIKART ServerAgent können Sachdatentabellen zu den ARCHIKART Objekten erstellt und deren Inhalt punktgenau ausgewählt werden. Diese Tabellen lassen sich in beliebigen Zieldatenbanken ablegen. Auch ein Wechsel des Datenbanksystems beispielsweise aus einem zentralen ORACLE Datenbanksystem auf einen Webserver mit Seite 26 von 39

27 PostgreSQL Datenbank ist problemlos möglich. Je nach Anforderung an die Aktualität können die Daten entweder dauerhaft abgeglichen werden oder aber in bestimmten festgelegten Zeiträumen. 2 Die Tabellen des ServerAgent sind flexibel konfigurierbar. Somit kann schon auf Ebene des ServerAgent eine Filterung schutzwürdiger Daten erfolgen. Parallel zu dem Sachdatenexport muss jedoch für die Darstellung im Geoportal manuell ein ESRI-Shape-Export erfolgen. Abbildung 4: ARCHIKART-Anbindung Variante b) Somit ist mit dem ServerAgent eine Sachdatenübertragung aus der bestehenden MySQL- Datenbank von ARCHIKART in die PostgreSQL-Datenbank des Geoportals realisierbar. Die Konfiguration der Geodienste kann dann zentral über die Oberfläche des Geoportals Kommune erfolgen. Hier ist die Bereitstellung standardkonformer Dienste als WMS einschl. Sachdatenabfrage via GetFeatureInfo und WFS möglich. 2 Stand Seite 27 von 39

28 Workflow Auf Seite des Geoportals Kommune sollte eine entsprechende PostgreSQL-Zieldatenbank vorbereitet werden. Hierzu kommt eine entsprechende Datenbank-Installation in der Stadtverwaltung Beelitz als Zwischenschicht in Frage. Diese Zieldatenbank wird zeitlich gesteuert durch den ServerAgent befüllt. Aus dieser Zieldatenbank wird ebenfalls zeitlich gesteuert ein Dump (Speicherauszug) erzeugt. Der Dump wird zeitlich gesteuert über eine sichere Verbindung auf den Geoportal/ISK-Server überspielt. Hier erfolgt das zeitlich gesteuerte Einlesen des Dumps in die Datenbank. Alternativ kann über eine gesicherte Verbindung der ServerAgent direkt auf die PostgreSQL- Zieldatenbank auf dem Geoportal/ISK-Server zugreifen. Hierzu ist seitens der Stadtverwaltung eine feste IP zweckmäßig, so dass seitens Geoportal/ISK-Server der Port der Datenbank ausschließlich für diese IP geöffnet wird. Parallel muss ein entsprechender Workflow für die Übertragung der dazugehörigen Geometriedaten im SHP-Format technisch und organisatorisch realisiert werden. Es wird davon ausgegangen, dass einzelne Prozesse nur manuell angestoßen oder ausgeführt werden können. Es ist geplant, dass eine Aktualisierung wahrscheinlich in einem Monatsturnus erfolgen wird. Der oben beschriebene Workflow deckt zunächst nur die Übertragung der Sachdaten ab. Wie bereits erwähnt muss außerdem die Geometrie, vorzugsweise im SHP-Format, übertragen werden. Die Verknüpfung der Sach- und Geometriedaten erfolgt am zweckmäßigsten in der Zieldatenbank des Geoportal/ISK-Servers durch Import der SHP-Dateien in die PostgreSQL-Datenbank, die hierfür zusätzlich PostGIS-Funktionalität mitbringt. Auf Datenbankebene ist dann eine Verknüpfung der Sachdatentabellen mit den Geometrietabellen möglich. Im Rahmen der Projektrealisierung ist hierfür ein praktikabler Workflow zu entwickeln, so dass die Datenübertragung und Aktualisierung mit überschaubarem Aufwand ermöglicht wird. Seite 28 von 39

29 Zusammenfassung Variante b) ServerAgent liefert aktuelle Sachdaten Geometrie muss als ESRI-Shape-Datei (SHP) manuell exportiert werden WMS standardkonform WFS möglich Der ServerAgent ist bereits in der Stadtlizenz von ARCHIKART enthalten. Ein ESRI-Shape- Export ist auch verfügbar. Auch hier muss Einrichtungs- und Konfigurationsaufwand für den ServerAgent berücksichtigt werden (vgl. Punkt 7.1 Arbeitspakete). Zusammenfassung Variante a) und b) Variante a) Variante b) Vorteil Hohe Datenaktualität Schnelle Datenbereitstellung (intern konfiguriert kann auch extern bereitgestellt werden) Nachteil Extern keine Sachdaten Nicht standardkonform Kein WFS Vorteil Standardkonform Extern Sachdaten verfügbar WFS verfügbar Externe Geodienste werden in einer Oberfläche verwaltet Nachteil Manueller SHP-Export Tabelle 3: Gegenüberstellung ARCHIKART Datenbereitstellung a) und b) Wie bereits ausgeführt, kann die Standardkonformität des ARCHIKART-WMS bei Bedarf durch Einbeziehung des Karten-Servers des Geoportals Kommune hergestellt werden Vorzugsvariante In Abstimmung mit der Stadtverwaltung Beelitz wird festgelegt, dass sowohl Variante a) als auch Variante b) im Rahmen des GDI-Projektes für die Stadt Beelitz umgesetzt werden. Je nach Anwendungsfall kann zukünftig die passende Variante zur Veröffentlichung von verwal- Seite 29 von 39

30 tungsinternen Daten gewählt werden. Variante a) mit permanent aktuellen Daten und wenig Funktionalität oder Variante b) mit zeitlich gesteuertem Aktualitätsturnus und voller Funktionalität. 5.5 Datenaufbereitung/Digitalisierung Seitens der Stadt Beelitz sollen im Rahmen der GDI BE/BB Informationen zur Bauleitplanung und weitere Geofachdaten bereitgestellt werden. Alle genannten Daten befinden sich im Eigentum der Stadt Beelitz und unterliegen keinen weiteren Zugangsbeschränkungen Prozessbeschreibung Im Folgenden werden grundlegende im Rahmen der Geodatenaufbereitung durchzuführende Arbeitsprozesse beschrieben. Bauleitplanung Die unstrukturiert vorliegenden Daten der Bauleitplanung sind digital im Standard XPlanGML3 zu erfassen. Hierfür werden die entsprechenden Teilprozesse Scan, Georeferenzierung, Vektorisierung und Sachdatenanbindung durchgeführt. Vor Beginn der Bearbeitung sind die gewünschte Erfassungstiefe und qualität festzulegen (vgl. Pflichtenheft XPlanungskonforme Erfassung von Daten der Bauleitplanung, Landesamt für Bauen und Verkehr 2009). Die Stadtverwaltung Beelitz hat sich zunächst für die Erfassungsqualität Abdigitalisierung und die Erfassungstiefe Geltungsbereich entschieden. Eine größere Erfassungstiefe kann und wird bei zukünftigen Planaufstellungen und Bearbeitungen berücksichtigt. Im Rahmen der Bearbeitung ist das mögliche Erfordernis der Umzeichnung zu prüfen, wenn die Planzeichnungen gescannt und georeferenziert sind und damit gravierende Abweichungen erkennbar sind. Hier kann der somit noch nicht einzuschätzende Aufwand mit entsprechenden Nachträgen abgefangen werden. Seite 30 von 39

31 Neben den XPlan-Datensätzen sowie den gescannten und georeferenzierten Planzeichnungen sind für alle Planungen zusätzlich und sofern vorhanden textliche Festsetzungen, Legenden und komplette Plandokumente im Rasterformat vorzuhalten. Weiterhin ist für jeden XPlan-Datensatz mit Hilfe des im Rahmen der GDI BE/BB offiziell bereitgestellten Prüftools XPlanGML-Validator eine entsprechende Qualitätsprüfung durchzuführen. Innenbereichs-, Denkmalbereichs- und Sanierungssatzung Die Bearbeitung der Innenbereichs- sowie der Denkmalbereichs- und der Sanierungssatzung (Sonstige Planung) erfolgt weitgehend analog zu der im vorhergehenden Abschnitt beschriebenen Verfahrensweise. Für die weitere, geplante Bereitstellung der kommunalen Bauleit- und Sonstigen Planung auf Basis von standardisierten Geodiensten und mit Hilfe eines Infrastrukturknotens wird eine zusätzliche unter Punkt (Seite 16) beschriebene Datenaufbereitung empfohlen. Weitere Daten Alle weiteren Daten sind in der Anlage Auflistung Datenthemen vom (Datenthemen.pdf) aufgeführt. Lfd. Nr. Wer Was 1 Stadt Zusammentragen aller Daten 2 Dienstleister Scan und Georeferenzierung Vektorisierung o Bauleitplanung o Innenbereichs-, Denkmalbereichs- und Sanierungssatzung o Weitere Themen Aufbereitung von Sachdaten Bearbeitung externer Referenzen Legende, textl. Testsetzungen, Plandokument (nur Planung) Seite 31 von 39

32 Lfd. Nr. Wer Was Erfassung von Metadaten (Typ Data Set/Series ) Qualitätsprüfung 3 Stadt Prüfung und Abnahme Tabelle 4: Prozessablauf Datenaufbereitung/Digitalisierung 6 Beschaffung eines DesktopGIS In der Stadtverwaltung wird zurzeit kein DesktopGIS eingesetzt. Somit wäre eine Aktualisierung der im Projekt erzeugten Geodaten sowie eine Aufbereitung ergänzender Geodaten zukünftig nicht möglich. Gemäß der detaillierten Projektbeschreibung als Anlage des Antrages für die GDI-EFRE-Antragstellung soll das Gesamtsystem mit seinen Fach- und Funktionsmodulen aber auch eine Erfassung von Geodaten ermöglichen. Vor diesem Hintergrund ist für einen Arbeitsplatz 1) ein DesktopGIS mit 2) einer XPlanGML-Schnittstelle (Import/Export) und 3) einer SHP-Schnittstelle (Import/Export) zu beschaffen. Erst mit dem verwaltungsinternen Einsatz eines zeitgemäßen DesktopGIS ist ein nachhaltiger Erfolg des Gesamtprojektes gewährleistet! 7 Projektablauf 7.1 Arbeitspakete/Lieferumfang Im Interesse einer zeitlich gestrafften Umsetzung des Gesamtprojektes werden die einzelnen in dieser Konzeption beschrieben Leistungen folgenden Arbeitspaketen zugeordnet: 1. Vergabe 2. ISK/Geoportal 3. Datenbereitstellung aus ARCHIKART Seite 32 von 39

33 a) Einrichtung und Konfiguration des ARCHIKART-Karten-Servers für die externe Bereitstellung von Kartendiensten, ggf. zzgl. Hardware einschl. Einrichtung, sofern für den Karten-Server mit externer Bereitstellung erforderlich b) Einrichtung und Konfiguration des ARCHIKART ServerAgents für eine PostgreSQL-Zieldatenbank 4. Einrichtung der Zieldatenbank und Entwicklung eines Workflows (vgl. Punkt 5.4.2, Seite 28) 5. Datenaufbereitung/Digitalisierung XPlanung 6. Datenaufbereitung/Digitalisierung der übrigen Themen 7. DesktopGIS einschl. Schnittstellen Seite 33 von 39

34 7.2 Zeitplanung Da das hier beschriebene Projekt mithilfe von GDI-EFRE-Fördermitteln finanziert wird ist ein Projektabschluss in 2013 zwingend einzuhalten. Vor diesem Hintergrund wird die Zeitplanung entsprechend Gantt-Diagramm in Abbildung 5 festgelegt. Abbildung 5: Gantt-Diagramm zur Zeitplanung Es muss besonders berücksichtigt werden, dass die Einrichtung der Zieldatenbank von der Datenbereitstellung aus ARCHIKART abhängig ist. Seite 34 von 39

35 7.3 Abnahmekriterien Abnahmekriterien legen fest, welche Kriterien die Ergebnisse der einzelnen Arbeitspakete (vgl. Punkt 7.1 Arbeitspakete/Lieferumfang) erfüllen müssen, um den Anforderungen zu entsprechen. Detaillierte Anforderungen ergeben sich im Übrigen aus dem Punkt 5 Umsetzung. AP 2: ISK/Geoportal Anforderung Erfüllt ja/nein ISK ist installiert und eingerichtet. Standardkonforme Geodienste werden durch ISK bereitgestellt. Geodienste erfüllen die Anforderungen der GDI BE/BB Metadatenerfassung/Registrierung für ISK (vgl. Punkt 5.2.4). Geoportal ist installiert und eingerichtet. Geoportal ist lauffähig unter Internet Explorer und Firefox. Metadatenerfassung/Registrierung für Geoportal (vgl. Punkt 5.3.3). AP 3: Datenbereitstellung aus ARCHIKART Anforderung Erfüllt ja/nein ARCHIKART-Karten-Server kann extern WMS bereitstellen. ARCHIKART ServerAgent ist für PostgreSQL-Zieldatenbank eingerichtet/vorbereitet und Zieldatenbank wird gefüllt. Schulung der Stadt Beelitz für zukünftige individuelle WMS- Bereitstellung ist erfolgt. Schulung der Stadt Beelitz in die weitere Nutzung und Konfiguration des ServerAgents einschl. Shape-Export ist erfolgt. AP 4: Einrichtung Zieldatenbank und Entwicklung eines Workflows Anforderung Erfüllt ja/nein Zieldatenbank ist eingerichtet. Seite 35 von 39

36 Datenbereitstellung aus ARCHIKART funktioniert. Workflow für zukünftige Aktualisierung ist entwickelt und dokumentiert. Schulung der Stadt Beelitz in die weitere Nutzung und Konfiguration des Workflows erfolgt. AP 5: Datenaufbereitung/Digitalisierung XPlanung Anforderung Erfüllt ja/nein Ggf. bereitgestellte Pläne wurden zurückgegeben. XPlanGML Datensätze wurden auf Datenträger übergeben. Dokumentierte Validierung wurde übergeben. Metadaten wurden erfasst (vgl. Punkt 5.5.1). AP 6: Datenaufbereitung/Digitalisierung der übrigen Themen Anforderung Erfüllt ja/nein Ggf. bereitgestellte Pläne wurden zurückgegeben. Datensätze einschl. SLDs wurden auf Datenträger übergeben. Metadaten wurden erfasst (vgl. Punkt 5.5.1). AP 7: Beschaffung DesktopGIS einschl. Schnittstellen Anforderung Erfüllt ja/nein DesktopGIS ist installiert und funktionsfähig Integration der ARCHIKART-Architektur wurde vorgenommen WMS und WFS lassen sich einbinden Geschützte WMS und WFS lassen sich einbinden XPlanGML Import/Export erfolgreich getestet SHP Import/Export erfolgreich getestet Seite 36 von 39

37 8 Auswirkungen der Maßnahme Im Rahmen des hier beschriebenen Projektes werden die verschiedensten Daten aufbereitet und für die öffentliche und verwaltungsinterne Nutzung bereitgestellt. Diese Daten stellen derzeit somit einen gewissen Wert dar. Der Wert der Daten kann zukünftig nur erhalten bleiben, wenn in angemessenen Abständen Aktualisierungen erfolgen. Durch die Verknüpfung von ARCHIKART und dem Geoportal-Kommune wird die Voraussetzung für die Datenaktualität der Sachdaten geschaffen. Somit kann durch die Stadtverwaltung nach Projektabschluss lediglich eine Aktualisierung der Sachdaten vorgenommen werden. Zur Aktualisierung von zugehörigen geografischen Objekten ist zusätzlich ein Desktop-GIS erforderlich. Im Rahmen dieser Konzeption wurde überprüft, ob eine Anschaffung eines Desktop-GIS mit dem Förderbescheid dieser Maßnahme (vgl. Punkt 3 Projekt-Rahmenbedingungen) im Einklang steht. Seitens der fachtechnischen Prüfstelle wurde dies nach Abstimmung mit dem Innenministerium jedoch fernmündlich ausdrücklich verneint. Es wurde um eine entsprechende schriftliche Auskunft gebeten. Zum Zeitpunkt der Fertigstellung der Konzeption lag diese Auskunft nicht vor. Unabhängig von der Förderfähigkeit eines Desktop-GIS ist davon auszugehen, dass für die Aktualisierung der in diesem Projekt gewonnenen Daten organisatorische und technische Maßnahmen erforderlich sind. An dieser Stelle soll ausdrücklich darauf hingewiesen werden, dass das Projekt zwar primär für die Nachnutzung durch die Öffentlichkeit durchzuführen ist. Aber auch verwaltungsintern wird die Nutzung sämtlicher in diesem Projekt gewonnenen Daten die jeweiligen Arbeitsprozesse unterstützen. An dieser Stelle wird auch auf den GIS-Leitfaden Aufbau und Einsatz eines Geografischen Informationssystems aus Sicht Brandenburger Gemeinden der TUIV-AG Brandenburg verwiesen. Seite 37 von 39

38 8.1 Organisatorisch Die Stadtverwaltung hat bereits in der Vergangenheit durch diverse Dienstleister geografische Informationen erstellen lassen. Beispielhaft kann die Bestandsdokumentationen nach Baumaßnahmen oder die Bauleitplanung genannt werden. Die jeweils erstellten Dokumente werden in Papierform den entsprechenden Akten zugeordnet oder in anderer Weise aufbewahrt. Um zukünftige Datenlieferungen mit möglichst geringem Aufwand für die GDI Beelitz nutzbar machen zu können, müssen bestimmte Anforderungen an die Datenlieferung festgelegt werden. Hierzu gehören insbesondere Dateiformat (ESRI-Shape-Format wird empfohlen) oder XPlanGML 3.0, Koordinaten-Bezugssystem EPSG: (ETRS89) und Höhensystem (DHHN92). Die Einhaltung dieser Festlegungen muss geprüft und ggf. durchgesetzt werden. Weiterhin muss festgelegt werden, welche Organisationseinheiten die Datenlieferungen schließlich in das interne System einpflegen. In gleicher Weise muss die Ausgabe von Daten z. B. an Planungsbüros festgelegt werden. Die entsprechenden Festlegungen müssen dokumentiert und in der Verwaltung verteilt werden. Für die Organisationsgröße der Stadt Beelitz wird empfohlen, eine halbe Vollzeitstelle als sogenannten GIS-Administrator vorzusehen. Je nach Vorkenntnis muss auch Schulungsbedarf berücksichtigt werden. Durch die vertragliche langfristige Einbeziehung eines geeigneten GIS-Dienstleisters nach Projektabschluss könnte der Bedarf weitestgehend kompensiert werden. 8.2 Technisch Der technische Fortschritt in der Informationstechnologie im Allgemeinen und in der Geoinformationstechnologie im Besonderen wird sich äußerst dynamisch weiterentwickeln. Auch hier empfiehlt sich die Betreuung durch einen externen Dienstleister, um auf neue Entwick- Seite 38 von 39

39 lungen und Möglichkeiten, z. B. zur Vereinfachung von Verwaltungsprozessen, zu reagieren. Somit wird ein langfristiger Projekterfolg gewährleistet. 9 Anlagen Als separate Dokumente wurden erstellt: Liste XPlanung vom (XPlanung.pdf) Auflistung Datenthemen vom (Datenthemen.pdf) Seite 39 von 39