Juli Auftraggeber:

Transkript

1 Konzeption zum Aufbau eines Webdienstes und eines anwendungsbezogenen Geoportals für die Bereitstellung von Geodaten basierter Bildungsinformationen (EduGIS) Juli 2010 erstellt durch: Auftraggeber: lat/lon Staatliches Schulamt Wünsdorf gesellschaft für mbh Aennchenstr Bonn Tel Fax info@lat-lon.de Kompetenzzentrum Verwaltungszentrum Hauptallee 116/ Zossen Projekt NAME/ID: bbedugis

2 Inhaltsverzeichnis Einleitung Organisationsstruktur und Architektur Datengrundlage Primärdaten Sekundärdaten Metadaten Funktionsumfang von EduGIS GeoPortal Portalfunktionen Gestaltungskriterien Datenhaltung und Geo-Dienste Kartendienst Datenhaltung (Datenbank) Daten- und Zugriffssicherung Umsetzung Zeitplan und Umsetzungsphasen Empfohlene Software Geoportale Kartendienste Aufwände und erforderliche Hardware...38

3 Abbildungsverzeichnis Abb. 1: Architektur der GDI Brandenburg (aus Sollkonzept GIB)...8 Abb. 2: Verbindung von der GDI Brandenburg mit der GDI-DE (aus Sollkonzept GIB)... 9 Abb. 3: Beispiel zur Nutzung von Geobasisdaten als Hintergrundinformation...14 Abb. 4: Anbindung von Kartendiensten in EduGIS...19 Abb. 5: Allgemeine Architektur zur Verwendung eines speziellen Proxies zur Absicherung von OGC Web Services (OWS)...31 Abb. 6: Zeitplan für die Umsetzung der ersten Phase von EduGIS...39 Tabellenverzeichnis Tab. 1: Kartendienste des LGB...17 Tab. 2: Verbreitete Open Source-Pakete für Geoportale...34 Tab. 3: verfügbare Open Source Kartendienste...36

4 Änderungen Datum Autor Beschreibung Andreas Poth Initialisierung des Dokuments Andreas Poth Erstellen der Dokumentstruktur und Referenzliste Andreas Poth Erstellung des Konzepts Anne Loos QS Andreas Poth Ergänzung des Zeitplans Jens Fitzke Durchsicht der vollständigen Entwurfsfassung Andreas Poth Einarbeiten von Änderungsvorschlägen und Korrekturen Andreas Poth Überarbeitung des Dokuments gemäß Änderungs- und Ergänzungswünschen des AGs Anne Loos Überarbeitung Layout Andreas Poth Finale Einarbeitung von Änderungswünschen

5 Referenzen Land Brandenburg, Ministerium des Inneren (2006): Geodateninfrastruktur im Land Brandenburg, Sollkonzept GIB Land Brandenburg / Berlin (2008): Anforderungen an ein Geoportal der Geodateninfrastruktur Berlin/Brandenburg Land Brandenburg / Berlin (2007): Grundsätze und Ziele der Geodateninfrastruktur-Berlin/Brandenburg CeGi (2007): Schlussbericht zu Beratungsdienstleistungen im Rahmen der Umsetzungsplanung zur Organisation der gemeinsamen Geodateninfrastruktur der Länder Berlin und Brandenburg, Version 1.1 Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder der Bundesrepublik Deutschland (AdV) (2008): Dokumentation zur Modellierung der Geoinformationen des amtlichen Vermessungswesens (GeoInfoDok), ALKIS-Signaturenkatalog Teil C: Präsentation. Open Geospatial Consortium: Web Map Service Implementation Specification, Version 1.1.1, OGC Document r3 Open Geospatial Consortium: OpenGIS Web Map Server Implementation Specification, Version 1.3.0, OGC Document Open Geospatial Consortium: Web Feature Service Implementation Specification, Version 1.1.0, OGC Document Open Geospatial Consortium: Styled Layer Descriptor Implementation Specification, Version 1.0.0, OGC Document Open Geospatial Consortium: Web Map Context Documents, Version 1.0.0, OGC Document r2 INSPIRE (2009): Metadata Implementing Rules: Technical Guidelines based on EN ISO and EN ISO 19119, Version 1.1 ISO/TC 211 (2006): Resolution of comments received at the review document N 1916 of the final text of ISO/DTS 19139, Geographic information - Metadata - XML schema implementation, N 2048 GDI-DE (2010): Architektur der Geodateninfrastruktur Deutschland Version 2.0 (beta) 5

6 Einleitung Das Ministerium für Bildung, Jugend und Sport hat das IT-Kompetenzzentrum Wünsdorf beauftragt, im Rahmen der GDI-Brandenburg einen Web-Dienst und Geofachportal zur Bereitstellung von geokodierten Bildungsinformationen aufzubauen. Dabei handelt es sich zunächst um die Standorte von Schulen und Kindertagesstätten (Kitas). Die Kernfunktionalitäten des Web-Dienstes und des Portals sollen im Internet zunächst für jedermann frei zugänglich sein und den Informationsbedarf von Bürgern, Unternehmen, Wissenschaft etc. bzgl. der Leistungsfähigkeit des Bildungssystems des Landes Brandenburgs adressieren. In der Leistungsbeschreibung zum vorliegenden Konzept sind insbesondere die folgenden Anforderungen genannt: Es sind Daten aus dem Geschäftsbereich des Brandenburger Bildungsministeri- ums (MBJS) zugrunde zu legen. Dabei handelt es sich um die geocodierten Standorte aller Schulen, Kindertagesstätten (Kita) und Horte gekoppelt mit Informationen aus den Fachanwendungen des Geschäftsbereichs. Der Dienst ist ausbaufähig zu gestalten, um zukünftig auch weitere geocodierte Daten des Geschäftsbereiches für die Bereitstellung zu nutzen. Der Dienst ist nach OGC-konformen Standards zu erstellen und hat EPSG:25832, EPSG:25833 und EPSG:4326 zur interoperablen Nutzung zu unterstützen. Zusätzlich ist die Bereitstellung im amtlichen Bezugssystem des Landes Brandenburg zu erstellen (EPSG:325832, EPSG:325833). Der Dienst soll sowohl eine standardisierte Kartografie (sofern vorhanden) für die Visualisierung bildungsrelevanter Sachverhalte, als auch eine weitestgehend automatisierte Bereitstellung von Geobasis- und Geofachdaten aus den bereits vorhandenen Datenbeständen (Quellen) erlauben. Der Dienst soll datenbankgestützt betrieben werden. Dabei sind datenlogistische Aspekte der bestehenden Datenbanklandschaft des Geschäftsbereichs zu berücksichtigen. Ziel ist eine weitestgehend automatisierte Bereitstellung von Geobasisund Geofachdaten aus den bereits vorhandenen Datenbeständen (Quellen). Es sollen Lösungsansätze für den Aufbau eines Geoportals innerhalb von beste- henden Internetanwendungen aufgezeigt werden. Dabei sollen technische Aspekte und die Einbindung in bestehende Anwendungen berücksichtigt werden; insbesondere ist die Kopplung mit den "Schulporträts Brandenburg" vorgesehen. Es ist die Bereitstellung von Metadaten sowohl für den zu erstellenden Dienst selbst als auch für die verwendeten Daten nach den Standards des OGC, der ISO und von INSPIRE zu konzipieren. 6

7 Es sollen Empfehlungen für die notwendige Hardware- und Software-Ausstattung gegeben werden. Präferiert wird die Nutzung Lizenzkosten freier Software. Es ist eine Abschätzung von Folgekosten für die empfohlenen Produkte aufzustellen. Das im Folgenden wiedergegebene Konzept entwickelt Architektur und Rahmen zur Einrichtung und zum Betrieb einer Web-Anwendung, welche die beschriebenen Anforderungen umsetzt. Besonders berücksichtigt wird dabei die Integration in die Geodateninfrastruktur (GDI) Brandenburgs und damit die Einhaltung der entsprechenden Standards und Spezifikationen sowie die mögliche Erweiterbarkeit der Anwendung. Wo keine eindeutige Empfehlung gegeben werden kann - da z.b. mehrere gleichwertige Optionen bestehen - werden alternative Szenarien entwickelt und dargestellt. Die konkrete Ausgestaltung muss in diesen Fällen im Rahmen der geplanten Umsetzung erfolgen. Abschließend wird ein Ausblick auf die Umsetzung des entwickelten Konzepts hinsichtlich Aufwand und Zeitrahmen gegeben. 7

8 1 Organisationsstruktur und Architektur Gemäß des Sollkonzepts Geodateninfrastruktur für das Land Brandenburg (Sollkonzept GIB) liegt... die Durchführungsverantwortungen beim Aufbau der Geodateninfrastruktur bei den jeweils zuständigen Einrichtungen des Landes, der Landkreise oder der Kommunen. Zentrale Leistungen und Daten werden dabei von der Landesvermessung und Geobasisinformation Brandenburg (LGB) bereitgestellt. Die Umsetzung fachgebundener Anwendungen auf Landesebene obliegt den jeweiligen Einrichtungen des Landes. Diese können dabei auf die vom LGB bereitgestellten Dienste und Geobasisdaten zugreifen. Umgekehrt sollen Dienste, die von Landeseinrichtungen im Rahmen des Aufbaus fachbezogener Geodateninfrastrukturen bereitgestellt werden, auch der GDI Brandenburg zur Verfügung stehen. Sie müssen daher den im Sollkonzept GIB geforderten Standards genügen. Der Zugang zu den im Rahmen der GDI Brandenburg entwickelten und bereitgestellten Diensten und Portalen, wird durch das Internetportal der GDI Brandenburg beschrieben (siehe Abbildung 1). Abbildung 1: Architektur der GDI Brandenburg (aus Sollkonzept GIB) 8

9 Auf eine vollständige Integration in das Portal wird bewusst verzichtet, so dass jedes Fachportal sein eigenes Erscheinungsbild ("corporate identity") realisieren kann. Des weiteren sind alternative Zugänge und Verlinkungen möglich. Im Rahmen der Umsetzung von Fachportalen ist gemäß Sollkonzept GIB die Möglichkeit zur Übernahme/Nachnutzung bereits bestehender Lösungen (Fachportale: Geothermie, Vermessung, Katastrophenschutz, Tourismus, Umwelt, Raumplanung und Landesliegenschaft) zu prüfen. Die Bereitstellung der Metadaten wird weiterhin zentral vom LGB betrieben. Zwar bestehen ab Juli 2010 für Landeseinrichtungen Nachnutzungsmöglichkeiten der Metadaten-Lösung ProMIS, doch sollte diese lediglich zur Erfassung von Metadaten und deren Übermittlung an das LGB dienen. Die eigenverantwortliche Bereitstellung von Metadaten durch Landeseinrichtungen mittels eines OGC Catalogue Services im Internet ist weder verpflichtend noch sinnvoll. Da die GDI Brandenburg ihrerseits in die GDI-DE eingebunden ist, sind zudem deren Richtlinien zu beachten (Abbildung 2). Zur Zeit liegt die Spezifikation für die GDI-DE in Version 1.0 vor, Version 2.0 ist als Konzept bereits vorhanden und wird in den nächsten Monaten verabschiedet. Hierdurch werden u.a. Teile der im Rahmen von INSPIRE formulierten Standards verbindlich in die GDI-DE übernommen. Abbildung 2: Verbindung von der GDI Brandenburg mit der GDI-DE (aus Sollkonzept GIB) Das IT-Kompetenzzentrum Wünsdorf als Teil des Schulamtes Wünsdorf und damit teil einer nachgeordneten des Ministeriums für Bildung, Jugend und Sport (MBJS) unterliegt somit den im Sollkonzept GIB genannten Anforderungen und Rahmen bedingungen. Das MBJS als obere Schulbehörde ist zuständig für die Genehmi9

10 gung von Schulen und Eigentümer der nachfolgend dargestellten Primärdaten. Die Organisation der ca. 940 Schulen des Landes in Bezug auf Lehrkräfte, Schulaufsicht etc. obliegt den sechs Schulämter (Brandenburg an der Havel, Cottbus, Eberswalde, Frankfurt, Perleberg und Wünsdorf), die die unteren Schulbehörden bilden. Jedes einzelne Schulamt ist zuständig für Schulen in einem oder mehreren Landkreisen und kreisfreien Städten. Federführend bei der Erstellung von EduGIS ist das IT-Kompetenzzentrum, Schulamt Wünsdorf. Hier wird auch die Datenaufarbeitung und Bereitstellung übernommen. Das "Zentrale System zur Online-Verwaltung von Schulinformationen" (ZENSOS) ist ein Intranetportal zur Erfassung, automatischen Aufbereitung und Darstellung aller für die Wahrnehmung der gesetzlichen Aufgaben des MBJS und der Staatli chen Schulämter relevanten Daten. Mit dem Einsatz von ZENSOS sollen die Geschäftsprozesse während der Datenerfassung und -aufbereitung im gesamten Geschäftsbereich optimiert und effektiver gestaltet werden. In ZENSOS werden neben vielen weiteren Informationen auch die (geocodierten) Adressdaten der Schulstandorte gehalten und gepflegt. Die Daten zu den Kita- und Hortstandorten werden über das Landesjugendamt Bernau (LJA) verwaltet. Eine Verwaltungsvereinbarung zur Überlassung und Aufbereitung der Kita-Daten mit der nachgeordneten Einrichtung des MBJS existiert bisher noch nicht. Um eine aktuelle Integration der (geocodierten) Informationen zu gewährleisten, wird das Aufstellen einer solchen Vereinbarung einschließlich der Benennung der Lieferintervalle und der technischen Spezifikationen für den hier konzipierten Geo-Webdienst und für das Geo-Fachportal empfohlen. Eine erste Nutzung des Geo-Webdienstes EduGIS soll im Rahmen "Schulporträts des Landes Brandenburg erfolgen. Das Internet-Portal "Schulporträts Brandenburg" wird vom Landesinstitut Schule und Medien Berlin-Brandenburg (LISUM) betrieben. Die Steuerung und Planung der Weiterentwicklung des Internet-Portals erfolgt im MBJS. Die konkrete Umsetzung erfolgt durch die Arbeitsgruppe Schulporträt im LISUM. Die für das Portal verwendeten Daten werden von den Schulen über das zentrale System ZENSOS eigenverantwortlich gepflegt. Durch eine tägli che Datenübernahme aus ZENSOS werden die Schulporträts aktuell gehalten. Die Datenübernahme erfolgt mittels einer Softwarelösung des Kompetenzzentrums Wünsdorf. Das Portal ist auf Basis des CMS Typo3 vollständig außerhalb des Landesverwaltungsnetz im Internetsegment des Zentralen IT-Dienstleistern (ZIT) realisiert. Die einzelne Schulporträts verfügen datentechnisch über eine eindeutige Schnittstelle, mit deren Hilfe sie in das EduGIS-Portal eingebunden werden können. Sollte sich bei der Umsetzung von EduGIS für eine solche Anbindung entschieden werden, ist eine auch hier eine Vereinbarung mit dem Betreiber des Fachportals "Schulporträts Brandenburg" bzgl. der Stabilität der Schnittstelle zu treffen. 10

11 2 Datengrundlage Im Zuge der initialen Datenbereitstellung zum Aufbau der Fachanwendung EduGIS sind verschiedene Aspekte hinsichtlich der verwendeten Daten zu berücksichtigen: Zuständigkeiten für die verwendeten Datensätze Aufbereitung und Aktualisierungen von Datenbeständen Menge der mit Schul- und Kita-Standorten verknüpften alphanumerischen Daten Datenqualität Aspekte des Datenschutzes und Lizenzrechts Bei den Daten ist zwischen Primärdaten, die durch die Schulämter bereitgestellt werden und Geobasisdaten (Sekundärdaten), die in der Regel durch das LGB verfügbar gemacht werden, zu unterscheiden. Im Laufe der Integration von EduGIS in die GDI Brandenburg spielt außerdem das Erfassen und Pflegen von Metadaten eine Rolle. 2.1 Primärdaten Als Primärdaten der Anwendung sind die Schul-Standorte und Kita-Standorte inklusive der mit ihnen verbundenen alphanumerischen Daten anzusehen. Die Primärdaten liegen als Vektordaten (Punkte) vor. Die Schulbehörden sind im Rah men der Bereitstellung über die Fachanwendung EduGIS für die Erfassung und Pflege der entsprechenden Metadaten gemäß ISO 19115/19139 sowie der Berücksichtigung des INSPRE-Metadatenprofils und des Brandenburg-Metadatenprofils verantwortlich. Die Daten der Schul-Standorte werden von den Schulämtern über das System ZENSOS erfasst und verwaltet. Da die zugrunde liegende relationale Datenbank keine Geodatenverwaltung kennt, müssen die Daten zur Nutzung in einem GIS entsprechend aufbereitet werden. Dies geschieht zurzeit zentral für alle Schulämter durch das beim Schulamt Wünsdorf angesiedelte IT-Kompetenzzentrum unter Verwendung der Software ArcView/GIS der Firma ESRI. Mit der Umsetzung von EduGIS soll diese Aufgabe vollständig und automatisiert von einer eingesetzten Geodatenbank übernommen werden. Die Kita-Standorte und die damit verknüpften alphanumerischen Daten werden den Schulämtern als Trägern des EduGIS-Projekts vom Landesjugendamt in Bernau zur Verfügung gestellt. Eine abschließende Aussage zu Aufarbeitung der Kita-Daten kann erst gemacht werden, wenn eine entsprechende Vereinbarung 11

12 zum Datenformat und zu den notwendigen Zeitintervallen vorliegt (s.o.). Im Zuge einer automatisierten Synchronisation der im Extranet zu betreibenden Fachanwendungen EduGIS ist die Entwicklung eines geeigneten Verfahrens zu prüfen (s.u.). In einer weiteren Ausbaustufe der Anwendung wird die Integration von Sportstätten als sinnvoll erachtet. Deren Verwaltung unterliegt ebenfalls dem MBJS. Die entsprechenden Zuständigkeiten sind im Rahmen des Ausbaus der Anwendung zu klären; dabei ist auch hinsichtlich der Frage der Metadatenerfassung (s.o.) zu entscheiden, ob es sich bei den Sportstätten um Primär- oder Sekundärdaten handelt. Zu den Primärdaten zählen neben den geometrischen Informationen zur Lage von Schulen und Kitas auch alphanumerische Daten, die von den Schulämtern für die Schulen - ebenfalls über ZENSOS in der MaxDB verwaltet werden. Ferner besteht, wie bereits erwähnt, die Möglichkeit, auf das bereits vorhandene Portal 'Schulporträts Brandenburg' zuzugreifen. Da die Anforderungen an beide Anwendungen jedoch nicht deckungsgleich sind, kann das Portal 'Schulporträts Brandenburg' nach augenblicklichen Sachstand nur im Rahmen der Bereitstellung von Zusatzinformationen an EduGIS angebunden werden. Kitas sind in diesem Portal nicht vertreten und erfordern daher auf jeden Fall eine Ableitung und Aufarbeitung der alphanumerischen Daten. 2.2 Sekundärdaten Sekundärdaten betreffen nicht den Zuständigkeitsbereich der Schulämter und werden daher auch nicht von diesen verwaltet, sie stehen den Schulämtern aber zur Nutzung in einer Fachanwendungen zur Verfügung. Häufig handelt es sich bei Sekundärdaten um Geobasisdaten, die durch das LGB bereitgestellt werden und als Hintergrundinformationen zur Darstellung der Primärdaten dienen ( Abbildung 3). Ferner können Sekundärdaten im Rahmen der Fachanwendungen EduGIS zur Navigation und Analyse eingesetzt werden. Das LGB stellt mehrere Karten- und Datendienste bereit, die im Rahmen von EduGIS genutzt werden können. Zur Zeit stehen die Kartendienste kostenfrei und ohne Einschränkungen zur Verfügung; die Erstellung einer entsprechenden Gebührenordnung ist jedoch in Vorbereitung. Unabhängig von den Kosten sind hierzu verbindliche Vereinbarungen mit dem Innenministerium bzw. dem LGB zu treffen. 12

13 Abbildung 3: Beispiel zur Nutzung von Geobasisdaten als Hintergrundinformation Eine Liste aller verfügbaren Karten- und Datendienste kann über das Portal der GDI Brandenburg eingesehen werden: Die Verfügbarkeit der Dienste im Landesverwaltungsnetz liegt laut Aussage des LGB bei mindestens 97,5 %. Die folgende Tabelle gibt einen Überblick über zurzeit vom LGB bereitgestellten Kartendienste, deren Einsatz im Rahmen von EduGIS sinnvoll erscheint: 13

14 Name 1 Datentyp1 Beschreibung WMS-DTK10 Der Geodienst WMS die digitale topographische Karte 1:10000 (DTK10), die aus den Daten des Digitalen BasisLandschafts-modells abgeleitet wurde Raster WMS-DTK25 Der Geodienst DTK25-WMS liefert die digitale topographische Karte 1:25000 (DTK50), die aus den Daten des Digitalen Basis-Landschaftsmodells abgeleitet wurde Raster WMS-DTK50 Der Geodienst DTK50V-WMS liefert die digitale topographische Karte 1:50000, die aus den Daten des Digitalen Landschaftsmodells (DLM50) abgeleitet wurde. Raster Gemeint sind die den gelieferten Karten zugrunde liegenden Datentypen 14 Beispiel

15 WMS-DRK Der Web Map Service WMSDRK100 stellt die Digitale Regionalkarte 1 : als Farbvariante dar. Die Daten beinhalten das Gewässer- und Verkehrsnetz, sowie die flächenhafte Darstellung von Siedlungen und Vegetation. Raster WMS-DLK Der Web Map Service WMSDLK250-N stellt die Digitale Landeskarte 1 : Normalausgabe als Farbvariante bereit. Die Digitale Topographische Landeskarte 1 : gibt einen Überblick über die Landestopographie Brandenburgs vom Gewässernetz über das Verkehrsnetz bis hin zur flächenhaften Darstellung von Siedlungen und Vegetation. Raster DOP20c Der GeoWebDienst WMSDOP20c liefert digitale Orthophotos als Farbvariante in der Bodenauflösung von 20cm. Raster WMS-DOP40g Der Geodienst WMS-DOP40g liefert digitale Orthophotos als Graustufenbilder in der Boden-auflösung von 40cm. Raster 15

16 WMS-DOP100g Der GeoWebDienst WMSDOP100g liefert digitale Orthophotos als Graustufenbilder in der Bodenauflösung von 1m. Raster WMSDOP500g / DOP2500g Dieser GeoWebDienst liefert digitale Orthophotos als Graustufenbilder in den Bodenauflösungen von 5m und 25m. Raster WMS-DNM Der Geodienst WMS liefert topographische Karten in verschiedenen Darstellungen für den Maßstabsbereich von 1: bis 1:1000 Vektor WMS-VG Der Geodienst WMS liefert die Verwaltungsgrenzen des Landes für den Maßstabsbereich von 1: bis 1:1000 Vektor Zurzeit nicht verfügbar Tabelle 1: Kartendienste des LGB Alle Dienste bis auf den zum Zeitpunkt der Erstellung des Konzepts nicht verfügbaren Kartendienst 'WMS-DOP500g / DOP2500g' antworten auf Kartenanfragen innerhalb weniger Sekunden. Einem Einsatz im Rahmen von EduGIS steht aus Sicht der Performanz daher nichts entgegen. 16

17 Zur Bereitstellung von Hintergrundkarten eignen sich die Kartendienste WMS-DTK10, WMS-DTK25, WMS-DTK50, WMS-DRK und WMS-DLK, welche maßstabsabhängig in einer Kartenebene zusammengefasst werden sollten (entsprechendes gilt bei der Verwendung Digitaler Orthophotos [DOP]). Die so erzeugten Karten liefern Kartendarstellungen in Form topographischer Karten, die vielen Nutzern aus anderen Geo-Portalen vertraut sind. Nachteilig wirkt sich bei diesen Kartendiensten die Verwendung von Rasterdaten als Datengrundlage aus. Bei Darstellungen, die nicht dem nativem Maßstab entsprechen, kommt es zu Artefakten, wie sie bei der Vergrößerung und Verkleinerung von Rastergrafiken unumgänglich sind. Alternativ oder zusätzlich können die Kartendienste WMS-DNM und WMS-VG genutzt werden, die verschiedene Ebenen zur Darstellung von Themen und Beschriftungen auf Basis von Vektordaten bieten. Die Verwendung von Vektordaten als Datengrundlage vermeidet die bei Rastern auftretenden Artefakte bei Anfragen in unterschiedlichen, nicht der nativen Auflösung entsprechenden Maßstäben. Sollten die Kartendienste WMS-DNM und WMS-VG genutzt werden, so ist es ggf. sinnvoll, diese Dienste ebenfalls über den Kartendienst von EduGIS zu kaskadieren, um die angebotenen Kartenebenen (je nach Auswahl bis zu ca. 15 Stück) in einer oder zwei Ebenen zusammenzufassen. Dies verbessert die Übersichtlichkeit bei der Einbindung in ein Portal und vereinfacht vor allem für Nutzer, die keine oder nur wenig Erfahrung im Umgang Geographischen Infor mationssystemen haben, die Nutzung. Zusätzlich sollte eine Hintergrundkarte basierend auf DOP20c, WMS-DOP40g, WMS-DOP100g, WMS-DOP500g und WMS-DOP2500g angeboten werden, um Digitale Orthofotos (Luftbilder) als Kartenhintergrund verwenden zu können; eine Darstellung, die vielen Nutzern aus Google Maps vertraut ist. Sollte sich für die Verwendung von rasterbasierten Kartendiensten bzw. Kartenebenen entschieden werden, ist zu prüfen, ob die freie Maßstabsauswahl im EduGIS-Portal zugunsten einer vorgegebenen Maßstabsliste, wie sie u.a. von Google Maps und OpenLayers bekannt ist, ausgetauscht wird. Dadurch ist es möglich, die beschriebenen Artefakte zu vermeiden bzw. auf ein Minimum zu begrenzen. Mit der Oben angesprochenen maßstabsabhängigen Zusammenfassung der landesweiten Kartendienste bzw. der entsprechenden Kartenebenen - wird der Übergang in ihrer Verwendung in Abhängigkeit zum Maßstab der angefragten Karte beschrieben. Für den Portalnutzer erscheint nur eine 'logische' Kartenebene, die, für den Nutzer transparent, auf mehrere physische Datenquellen abgebildet wird. Um die Konfiguration des Fachportals in EduGIS möglichst einfach und stabil zu gestalten, sollte die Zusammenfassung über das Einrichten entsprechender Ebenen in einem kaskadierenden Web Map Service erfolgen: 17

18 EduGIS Portal EduGIS EduGIS WMS WMS Primärdaten externe WMS LGB WMS kaskadierte WMS Abbildung 4: Anbindung von Kartendiensten in EduGIS Neben Hintergrundkarten bietet das LGB weitere Daten bzw. Dienste an, die im Rahmen von EduGIS sinnvoll genutzt werden können. Allen voran ist der Gazetteer-Dienst zu nennen. Seine Einbindung in das zu erstellende Portal ermöglicht die Navigation in der Karte unter Verwendung geographischer Namen. Dies vereinfacht vor allem für Personen, die es nicht gewohnt sind, mit Kartenanwendungen umzugehen, das Arbeiten mit dem Portal. Zur Zeit stehen die folgenden Datentypen zur Verfügung: Verwaltungsgliederung Recherche nach Verwaltungseinheiten Kreise Recherche nach Brandenburg Strassen Postleitzahlgebiete Wohnplaetze Gemeinden Gemeindeteile den Kreisen Recherche nach Straßennamen Recherche nach Postleitzahlen Recherche nach Wohnplätzen Recherche nach Gemeinden Recherche nach Gemeindeteilen 18 des Landes

19 Ortsteile Hauskoordinaten Flur Gemarkung Flurstuecke ALK-Rahmen TK10 TK25 TK50 TK100 Recherche nach Ortsnamen und Ortsteilnamen Recherche nach postalischen Adressen Recherche nach Flurübersichten Recherche nach Gemarkungsübersichten Recherche nach Flurstücken Recherche nach ALK-Rahmenkarten Recherche nach Blattschnitten der TK10 Recherche nach Blattschnitten der TK25 Recherche nach Blattschnitten der TK50 Recherche nach Blattschnitten der TK100 Relevant erscheinen zunächst vor allem die Datentypen Verwaltungsgliederung, Kreise, Gemeinden, Gemeindeteile, Ortsteile, Strassen und Hauskoordinaten. Werden diese Datentypen hierarchisch verknüpft, ermöglichen sie das schrittweise Eingrenzen der gesuchten Region. Zu prüfen bleibt, ob auf Basis des Gazetteers des LGB Freitextsuchen realisiert werden können, so wie es viele Nutzer z.b. von Google Maps gewöhnt sind (z.b.: 'Ludwig Jahn Straße Herzberg'). Gemarkungen, Fluren etc. sowie TK-Blattschnitte haben für EduGIS keine weitere Relevanz und sollten dem Nutzer daher nicht angeboten werden. Grundsätzlich verfügt das LGB über weitere Datensätze, die ggf. für zusätzliche Ausbaustufen von EduGIS von Relevanz sind. Zu nennen sind hier u.a. Gebäudegrundrisse (vor allem der Schulgebäude und Kitas) sowie Straßen und Gehwege. Letztere können, wenn sie in entsprechender Qualität vorliegen, zur Berechnung von Routen und Erreichbarkeiten genutzt werden. 19

20 2.3 Metadaten Metadaten beschreiben eine Anwendung und die darin verwendeten Daten. Gemäß INSPIRE sind die Staaten der EU verpflichtet, Metadaten zu verschiedenen Themenbereichen zu erfassen und online über einen Metadatendienst ("Catalogue Service") verfügbar zu machen. Der föderale Charakter der Bundesrepublik führt dazu, dass die Zuständigkeiten hierzu teilweise bei den Ländern liegen. Die meisten Länder, und so auch Brandenburg, haben daher damit begonnen, Metadaten konform zum INSPIRE-Metadatenprofil zu erfassen, das seinerseits auf den ISO-Normen 19115, und aufsetzt. In Brandenburg werden Metadaten zentral über einen Katalogdienst angeboten, der vom LGB verwaltet wird. Über das System ProMIS haben Landeseinrichtungen die Möglichkeit, Metadaten zu den von Ihnen verwalteten Daten und Diensten zu erfassen und zu pflegen. Die Landeseinrichtungen sind angehalten entsprechende Metadaten über den Katalogdienst des Landes bereitzustellen; der Betrieb eines eigenen Katalogdienstes ist bei Fachanwendungen nicht gefordert und in Erwartung der geringen Menge an Primärdaten im Zusammenhang mit EduGIS auch nicht sinnvoll. Im Rahmen von EduGIS werden zunächst nur drei Metadatensätze zu erfassen sein. Dabei handelt es sich um Daten-Metadaten zu den Schul- und KitaStandorten sowie einen Service-Metadatensatz zum zu realisierenden Web Map Service. Sollte in zukünftigen Ausbaustufen von EduGIS die Möglichkeit zum direkten Datenzugriff, z.b. über einen Web Feature Service, geschaffen werden, wäre ein weiterer Service-Metadatensatz zu integrieren. Sekundärdaten müssen nicht über Metadaten beschrieben werden, da dies bereits durch verantwortli chen Stellen geschieht bzw. geschehen sollte. Zur Erfassung der Metadaten steht ab Juli 2010 das vom LGB betriebene System ProMIS zur Verfügung, daher sollte auf die Installation einer eigenen Lösung verzichtet werden. Die Verwendung von ProMIS stellt gleichfalls sicher, dass Metadaten immer konform zu den Richtlinien des Metadatenprofils der GDI Brandenburg erhoben werden. 20

21 3 Funktionsumfang von EduGIS Bei der Umsetzung der Komponenten von EduGIS gilt es neben der gewünschten Funktionalität mehrere Richtlinien und Spezifikationen einzuhalten. So wird sichergestellt, dass sich EduGIS vor allem der zugehörige Kartendienst - in die GDI Brandenburg integrieren lässt. Die wichtigsten Richtlinien und Spezifikationen sind im Sollkonzept GIB festgelegt und werden daher an dieser Stelle nicht noch einmal aufgeführt. Die Einhaltung der im Sollkonzept GIB gemachten Vorgaben, sollten bei der Umsetzung von EduGIS verbindlich vorgeschrieben werden. Abweichungen hiervon, die sich ggf. aus fachlichen Anforderungen ergeben, soll ten nur in Ausnahmefällen z.b. dort, wo sich die Standardisierung weiterentwickelt hat (z.b. INSPIRE) - zugelassen werden. Entsprechende Ausnahmen sind bei der Erstellung eines Feinkonzepts für EduGIS zu formulieren. Zusätzliche Anforderungen an die Konformität zu bestehenden Standards haben sich in den letzten Jahren vor allem durch die Standardisierung einer europäi schen Geodateninfrastruktur im Rahmen von INSPIRE ergeben. Die dort erstellten Richtlinien sind zum Teil bereits in nationales Recht überführt bzw. haben Eingang in die Spezifikation der GDI-DE 2.0 gefunden. Letztere befindet sich zurzeit in Vorbereitung und wird in den nächsten Monaten veröffentlicht. Einen guten Überblick über die relevanten Spezifikationen und Richtlinien gibt das Portal der GDI-DE Konformitätsregeln für die Darstellung von Schulen und Kitas lassen sich nicht festlegen. Zwar ist im ALKIS-Signaturenkatalog der GeoInfoDok jeweils eine Darstellungsvorschrift für allgemeinbildende Schulen und Kitas definiert, eine weitere Differenzierung nach Schul- und Kita-Typen, wie sie für die Fachanwendungen EduGIS erforderlich ist, findet jedoch nicht statt. Im Rahmen der Erstellung eines Feinkonzepts für EduGIS ist daher ein Darstellungskatalog für Schulen und Kitas zu entwickeln. Wie bereits erwähnt besteht EduGIS aus den beiden Komponenten Portal und Kartendienst (WMS, inkl. Datenhaltung). Der Kartendienst (WMS) muss unabhängig vom Geoportal betreibbar sein, da diesen Dienst auch andere Nutzer im Rahmen des GDI-Angebots nutzen werden. Das bedeutet u.a., dass sich das EduGISPortal bei der Bereitstellung von Funktionen nicht auf Fähigkeiten des gewählten Kartendienstes stützen darf, die über die im Sollkonzept GIB festgelegten ver bindlichen Funktionen hinausgehen. 21

22 3.1 GeoPortal Portalfunktionen Bei der Definition der im EduGIS-Portal zu realisieren Funktionen ist zwischen Standardfunktionen zu unterscheiden, die nahezu jedes Produkt bereitstellt und erweiterten Funktionen, die zum Teil speziell für das EduGIS-Portal entwickelt werden müssen. Als Standardfunktionen bereitzustellen sind: zoomin/zoomout durch Klick in die Karte, Aufziehen eines Rechtecks, Drehen des Mausrads und direkte Auswahl des Kartenmaßstabs Verschieben der Karte (pan) mit gedrückter Maustaste Abfrage von Sachinformationen zu Objekten (Schulen, Kitas) in einer Karte Darstellen einer Übersichtskarte Auswahl der sichtbaren Kartenebenen Darstellen einer Legende (Hierbei darf sich das Portal nicht auf die Unterstützung der GetLegendGraphic Operation eines WMS verlassen, da diese gemäß Sollkonzept GIB nicht verbindlich ist.) Eine besondere Anforderung ergibt sich bei den Standardfunktionen für die Abfrage von Sachinformationen zu Objekten. Wie bereits ausgeführt, steht mit den 'Schulporträts Brandenburg' ein Portal zur Verfügung, welches der Öffentlichkeit wichtige Informationen zu Schulen zugänglich macht. Damit besteht neben der Option, Sachinformationen aus der Datenhaltung von EduGIS auszulesen und anzuzeigen, die Möglichkeit, das Portal "Schulporträts Brandenburg" parametrisiert aufzurufen und die dort hinterlegten und aufgearbeiteten Informationen zu einer bestimmten Schule anzuzeigen. Hierzu muss die für EduGIS verwendete Portalsoftware in der Lage sein, die Kennung und den Typ der von einem Nutzer in der Karte angeklickten Schule aus der Antwort des zugrundeliegende Web Map Service auszulesen und entsprechend aufbereitet an das Portal 'Schulporträts Brandenburg' zu schicken. Das Ergebnis der Anfrage kann in ei nem eigenen Browserfenster oder einer gesonderten Ansicht (z.b. mit Karteikartenreiter) des EduGIS-Portals angezeigt werden. Erweiterte Funktionen dienen vor allem der Bearbeitung der mit dem Thema Schul- und Kita-Standorte verbundenen Fragestellung. Bei der Auswahl ist zu beachten, dass sich EduGIS in der ersten Version vor allem an Eltern, Schüler und interessierte Laien, nicht jedoch an Personen mit Erfahrungen im Umgang mit Geographischen Informationssystemen wendet. Das heißt, ein Zuviel an Möglichkeiten und Funktionen, besonders dann, wenn sie unmittelbar in der Oberfläche 22

23 des Portals angeboten werden, kann auf zahlreiche Nutzer irritierend wirken und die intuitive Nutzbarkeit der Anwendung einschränken oder gar verhindern. Als sinnvolle für die erste Ausbaustufe werden folgende erweiterte Funktionen angesehen: Integration eines Gazetteer-Dienstes zur Navigation über geographisches Namensgut Drucken einer Karte bzw. Erstellen einer Druckvorlage als PDF inkl. der Möglichkeit einfacher Kommentierungen Das Messen von Entfernungen Anzeigen von Puffern um Schul-, Kita- und Wohn-Standorte Alle genannten Funktionen können unmittelbar von einem Portal realisiert werden und erfordern keine über das Sollkonzept GIB hinausgehenden Fähigkeiten des von EduGIS verwendeten Kartendienstes. Die durch den Auftraggeber in Betracht gezogene Möglichkeit der Definition fachlicher Filter bei der Anfragen von Karten sollte für die erste Version von EduGIS überdacht werden. Die Aufteilung der Schul- und Kita-Standorte in typ-/träger-/jahresabhängige Kartenebenen zusammen mit der Möglichkeit der Anzeige von Puffer realisiert wahrscheinlich den Großteil der Anwendungsfälle und ist vor allem für Laien wesentlich einfacher zu bedienen. Ferner würde die Umsetzung einer solchen Funktion, die Einbindung eines weiteren Dienstes (Web Feature Service) oder die Nutzung von nicht über das Sollkonzept GIB als verbindlich beschriebenen Funktionen von Kartendiensten nahelegen. Auf den ersten Blick gegensätzlich zur angestrebten Einfachheit scheint die Opti on weitere, nicht primär GIS-spezifische Funktionen in EduGIS zu integrieren. Im Zuge der Weiterentwicklung des Internets bzw. der dort verbreiteten Anwendungen, die häufig unter dem Begriff Web 2.0 zusammengefasst werden, scheint dies aber sinnvoll, um die Attraktivität des Portals zu erhöhen. Mittlerweile besteht bei Internet-Nutzern ein zunehmendes Interesse daran, nicht nur die durch den jeweiligen Anbieter bereitgestellten Informationen abzurufen, sondern selbst die verschiedenen Angebote zu kommentieren. Die große Akzeptanz, die eine entsprechende Funktion in Google Maps hat, ist ein Indiz dafür, dass sich Nutzer von Kartenanwendungen im Internet zunehmend nicht nur als reine Konsumenten von Information sehen, sondern selbst auch Informationen weitergeben möchten. Zumindest mittelfristig scheint die Integration einer Kommentarfunktion daher sinnvoll. 23

24 Für weitere Ausbaustufen des Portal sind vor allem Funktionen zu berücksichtigen, die es Fachanwendern verstärkt erlauben, EduGIS in ihre tägliche Arbeit zu integrieren. Damit einher geht zwingend die Unterscheidung zwischen verschiedenen Nutzern bzw. Nutzergruppen. Während anonyme Nutzer weiterhin eine eingeschränkte Sicht auf Daten und Funktionen erhalten, werden autorisierten Nutzern, in Abhängigkeit zu ihren individuellen Rechten zusätzliche Daten und Funktionen angeboten. Grundsätzlich muss die eingesetzte Portal-Software daher über die Möglichkeit der Personalisierbarkeit von Inhalt und Funktionen verfügen. Zugriffe auf Karten- und Datendienste müssen weiterhin standardkonform erfolgen (dass heißt z.b. der ausschließliche Zugriff mittels HTTPs ist nicht möglich). Die damit verbundenen notwendigen Mechanismen zum Schutz vor nicht autorisierten Zugriffen vor allem auf Daten werden weiter unten dargestellt. In einer Ausbaustufe des EduGIS-Portals werden die folgenden Funktionen, die in der Regel nur autorisierten Nutzern zur Verfügung stehen sollten, als sinnvoll er achtet: Erweiterung des Angebots an Sachinformationen zu Schulen und Kitas, Integration von alphanumerischen und räumlichen Filtermöglichkeiten mit entsprechender Darstellung der Filtermenge, Integration zusätzlicher Geo(Vektor)datensätze (Verwaltungseinheiten, Straßen, Häuser/Adressen, Sportstätten etc.) Erstellen komplexer Berichte, inkl. mehrseitige PDF-Dokumente Durchführung von Berechnungen/Simulationen z.b. Routenberechung, Berechnung von Einzugsgebieten auf Basis der tatsächlich benötigten Anreisezeit etc. Laden und Speichern von Portalzuständen/Projekten Möglichkeit zum Download von Daten zur lokalen Weiterverarbeitung Gestaltungskriterien Für kartengestützte Anwendungen gilt, dass die Übersichtlichkeit und Zugänglichkeit für den Nutzer in der Regel mit der Größe der Karte zunimmt, da größere Karten auch bei höheren Auflösungen noch einen hinreichend großen Raumausschnitt darstellen können. Die für EduGIS eingesetzte Portal-Software sollte daher die Möglichkeit bieten, die Größe der Kartendarstellung an die Größe des Bildschirms bzw. Browserfensters anpassen zu können. Im Idealfall geschieht dies automatisch. Die sich daraus ergebenden Abweichungen zum Layout des Portals der Schulämter sind aufgrund des deutlichen Gewinns an Nutzerfreundlichkeit zu 24

25 akzeptieren. Grundsätzlich gestützt wird dieses Vorgehen durch das Layout der bereits über die GDI Brandenburg verfügbaren Kartenanwendungen, die ebenfalls von der Gestaltung des jeweiligen Portals abweichen. Die Übernahme der corporate identity betrifft somit vor allem die Übernahme der farblichen Ausprägung, die Verwendung von Grafiken und Icons sowie sofern möglich die Anpassung von Schaltflächen (Buttons) und Menüs. Um das EduGIS-Portal auch in andere Web-Anwendung wie 'Schulporträts Brandenburg' integrieren zu können, muss es möglich sein, das Portal in einem HTMLIFrame zu betreiben oder von einer externen Anwendung in einem weiteren Browser-Tab bzw. in einem eigenständigen Browserfenster zu öffnen. Dabei muss es möglich sein, das Portal parametrisiert - z.b. über Vorgabe eines bestimmen Raumausschnitts bzw. einer Schul- oder Kita-Kennung aufzurufen. Wird das EduGIS-Portal in einen IFrame eingebettet, ist bei der Wahl des Layouts darauf zu achten, dass dieses auch bei kleineren Darstellung ansprechend ist und das Portal intuitiv bedienbar bleibt, da die Größe von IFrames in der Regel deutlich unter der der umgebenden HTML-Seite liegt. Alternativ besteht grundsätzlich die Möglichkeit, die eigentliche Kartenkomponente (Karten-Viewer) eines Geo-Portal als eigentständige Komponente in eine andere Anwendung einzubetten. Aus technischer Sicht ist dies relativ problemlos, wenn bei der Realisierung des EduGIS-Portals kein als fertiges Produkt vorliegendes Geo-Portal zu Einsatz kommt sondern auf ein Komponenten-Framework zurückgegriffen wird (z.b. map fish). Dies verteuert jedoch die Erstellung des eigentlichen EduGISPortals u.u. signifikant (siehe Kapitel ). Kommt bei der Umsetzung eine bereits vorhandene Portal-Lösung zum Einsatz, ist das Herauslösen eines KartenViewers ggf. technisch nicht unproblematisch und dem entsprechend mit zusätzlichen Aufwänden verbunden. 3.2 Datenhaltung und Geo-Dienste Da aufgrund der Netzwerkarchitektur des Landesverwaltungsnetzes in Brandenburg zurzeit kein Zugriff vom Internet auf Dienste in Intranet möglich ist, ist es erforderlich, EduGIS außerhalb des Intranets zu realisieren. Die betrifft sowohl die zu verwendenden Server und Dienste als auch die Datenhaltung Kartendienst Für die Wahl des einzusetzenden Kartendienstes gilt zunächst die zwingende Erfüllung der in der GDI Brandenburg geltenden Richtlinien. Dies heißt vor allem die Unterstützung des OGC-Standards WMS 1.1.1, sowie die Unterstützung der in Brandenburg gebräuchlichen Koordinatenreferenzsysteme: 25

26 EPSG:25832 EPSG:25833 EPSG: EPSG:35833 EPSG:3034 EPSG:3035 EPSG:3044 EPSG:3045 EPSG:31468 EPSG:31469 Zusätzlich wird die Unterstützung der geographischen Koordinatenreferenzsystems EPSG:4326 empfohlen. Ferner ist vom Auftraggeber die Unterstützung des Koordinatenreferenzsystems EPSG: gefordert, das standardmäßig nicht durch die im Rahmen der GDI Brandenburg betriebenen Kartendienste unterstützt wird. Im Zuge der Standardisierungsbemühungen auf europäischer Ebene durch INSPI RE wird die Unterstützung der OGC-Spezifikation WMS bzw. eines darauf aufsetzenden sog. "View Service" verbindlich. Diese hat auch in die GDI-DE 2.0 Spezifikation Eingang gefunden, wobei hier auch weiterhin die WMS-Spezifikation in der Version unterstützt wird. Die vom LGB bereitgestellten Kartendienste werden bis auf weiteres lediglich OGC WMS unterstützen. Mit einem Aufbau von Kartendiensten gemäß der OGC WMS und INSPIRE View Service Spezifikationen ist nicht vor 2011 zurechnen. Die Darstellung von Kitas und Schulen durch einen Kartendienst erfordert den flexiblen Umgang mit Darstellungsvorschriften. Der einzusetzende Web Map Service sollte daher in der Lage sein, klassifizierte Darstellungen anhand alphanu merischer Attribute z.b. der Schulform zu definieren. Dabei sollte es möglich sein, neben vordefinierten Symbolen wie Kreis, Quadrat, Dreieck etc. auch individuelle Symbole anzugeben. Dabei ist sicher zu stellen, dass diese in Form von Vektorgrafiken definiert werden können, um eine freie Skalierung zu ermöglichen. Individuell definierte Symbole müssen, wie vordefinierte Standardformen, beliebig einfärbbar sein. Um die Übersichtlichkeit der Kartendarstellung zu gewährleisten, ist ferner sicherzustellen, dass Zeichenvorschriften maßstabsabhän26

27 gig festgelegt werden können. Dies erlaubt es, bei kleineren Maßstäben einfache Symbole zu verwenden, die einen groben Überblick über die Verteilung z.b. der Kitas eines bestimmten Trägers ermöglichen; bei größeren Maßstäben kann auf komplexere Darstellungen umgeschaltet werden, um z.b. den Träger, die Zahl Kinder und die Ausstattung in die Ausprägung einer Darstellungsvorschrift mit einfließen zu lassen. Der Web Map Services bezieht die in der ersten Projektphase verwendeten Daten zur Schulen und Kitas direkt aus einer außerhalb des Landesbehördennetzes installierten Geo-Datenbank (s.u.). Ferner muss er in der Lage sein, andere Web Map Services in einer Kaskade anzubinden (siehe Abbildung 4). Dabei ist zu gewährleisten, dass mehrere kaskadierte WMS ggf. maßstabsabhängig in einem Layer zusammengefasst werden können.. Sollte in einer weiteren Ausbaustufe von EduGIS für autorisierte Nutzer die Möglichkeit realisiert werden, direkt auf Daten zuzugreifen, bietet der Einsatz eines OGC Web Feature Service hierzu eine standardisierte Schnittstelle. Zurzeit ist WFS die aktuelle vom OGC verabschiedete Spezifikationsversion, im Rahmen von INSPIRE wird allerdings bereits die sich noch in Vorbereitung befindende Version 2.0 als verbindlich definiert 2. Die Entscheidung, welche Version im Rahmen von EduGIS ggf. zum Einsatz kommt, sollte daher erst bei der Konkretisierung entsprechender Pläne getroffen werden Datenhaltung (Datenbank) Gemäß Vorgabe soll die Datenhaltung datenbankbasiert erfolgen. Zur Vermeidung zusätzlicher Lizenzkosten wird der Einsatz einer Open Source-Datenbank bevorzugt. Zur Zeit stehen mit PostgreSQL und MySQL Opensource-Datenbanken mit nativer Unterstützung von Geometrien zur Verfügung. Beide Datenbanken können sowohl unter Linux als auch unter Windows betrieben werden und sind mit vergleichbarem Aufwand zu installieren. Zudem handelt es sich bei beiden Datenbanken im Kern um relationale Datenbanksysteme, die um einen zusätzlichen Objektdatentyp (Geometry) und entsprechende Funktionen erweitert wurden. Grundsätzlich weiter verbreitet als Datenbank ist MySQL, doch gilt dies nicht für den Einsatz im GIS-Umfeld. Hier ist PostgreSQL mit der PostGIS-Erweiterung deutlich überlegen. Diese Überlegenheit bezieht sich vor allem auf die Qualität der implementierten Geometrie/Topologie-Unterstützung, aber auch auf die Menge der verfügbaren Funktionen. Damit ergibt sich im Hinblick auf die mögliche Inte gration zusätzlicher Funktionen in EduGIS bei der Verwendung von PostgreSQL 2 Zurzeit befindet sich die WFS 2.0 Spezifikation im Abstimmungsverfahren; mit einer Verabschiedung ist im Laufe der nächsten Monate zu rechnen. 27

28 ein höheres Maß an Nachhaltigkeit. Da die zu verwaltende Datenmenge im Rahmen von EduGIS vergleichsweise gering ist, spielen Erwägungen hinsichtlich Skalierbarkeit keine Rolle. Es wird daher empfohlen, die Datenbank innerhalb von EduGIS mit PostgreSQL und der PostGIS-Erweiterung zu realisieren. Der Import der Schul- und Kita-Daten sowie deren Synchronisation ist zunächst getrennt zu betrachten, da beide Datensätze aus verschiedenen primären Datenhaltungen stammen (s.o.). Wie bereits dargelegt, werden Stammdaten zu Schulen von den Schulämtern über das ZENSOS administriert. Da hierfür im Rahmen des Portals "Schulporträts Brandenburg" bereits eine Java-basierte Software zur Synchronisation von Primärdatenhaltung und Datenhaltung der Internetanwendung besteht, sollte, um eine redundante Entwicklung zu vermeiden, der entsprechende Mechanismus auch für EduGIS verwendet werden. Die zum Betrieb eines Kartendienstes erforderlichen Geometriedaten, lassen sich für Punktgeometrien datenbankseitig problemlos z.b. über einen Trigger - aus jeweils einer x- und y-spalte herstellen. Das über ZENSOS verwaltete Datenbankschema umfasst ca. 250 Tabellen und Datenbankviews. Aus diesen Tabellen und Views wer den nur die Inhalte in die Datenhaltung des Kartendienstes von EduGIS übernommen, die für den Betrieb erforderlich sind. Die genau Definition dieser Inhalte muss im Rahmen der Umsetzung von EduGIS erfolgen. Je nach verwendetem Kar tendienst (und in einer späteren Ausbaustufe ggf. auch Datendienst) kann es erforderlich sein, die gespiegelten Originaldaten auf ein anderes Schema abzubilden, da nicht alle Kartendienste mit relationalen Schemata beliebiger Komplexi tät zurecht kommen. Das Vorgehen für den Import und Abgleich der Kita-Daten ist noch nicht abschließend geklärt, da wie bereits dargestellt zurzeit noch keine Vereinbarung über das Datenformat und den Zyklus besteht, in denen die Daten zur Verfügung gestellt werden. Es ist jedoch davon auszugehen, dass die Daten vom ITKompetenzzentrum so aufgearbeitet werden, dass sie direkt in die von EduGIS verwendete Datenbank gespielt werden können. Das hierzu benötigte Datenbankschema hängt, wie bei den Schuldaten, vom eingesetzten Kartendienst ab und muss in der Umsetzungsphase definiert werden Daten- und Zugriffssicherung Wie bereits dargestellt, erscheint die Ausweitung des Funktions- und Datenangebots verbunden mit einer Personalisierung der Portaloberfläche in einer weiteren Ausbaustufe als sinnvoll. Hierfür sind mehrere Erweiterungen gegenüber der initialen Version von EduGIS erforderlich. Um diese zu bestimmen, muss zunächst festgelegt werden, für welche Funktionen und Daten ein Zugriffsschutz einzurich28

29 ten ist. Zu beachten ist dabei, dass sich die Absicherung vor unerlaubten Zugriffen nicht primär auf das Portal sondern die über dieses angebotenen Daten bezieht. Ferner ist festzulegen, welche Arten unerlaubter Zugriffe auf jeden Fall unterbunden werden müssen und welche ggf. akzeptiert werden können, um die Benutzbarkeit und Standardkonformität von EduGIS nicht über Gebühr einzuschränken bzw. aufzugeben. Mögliche Angriffspunkte für unerlaubte Zugriffe sind: direkter Zugriff auf geschützte Daten indirekter Zugriff auf geschützte Daten durch Einklinken in die Kommunikations kette Verändern von Daten Ausführen von unerlaubten Aktionen auf ansonsten zugänglichen Daten Übernahme des Servers und unautorisierter Betrieb einer zusätzlichen/alternati ven Anwendung Für jedes aufgelistete Schadverhalten gibt es in der Regel mehrere Abwehrme chanismen, die den Betrieb eines Geoportals in unterschiedlicher Weise beeinflussen. Zunächst wird das Risiko in Bezug auf das Abgreifen und Ändern von Daten bereits dadurch deutlich verringert, indem lediglich die tatsächlich erforderlichen Daten verfügbar gemacht werden. Dies hört sich zunächst selbstverständlich an, erfordert aber genaue Überlegungen, welche Funktionen über das Portal angeboten werden sollen bzw. welche Funktionen ggf. an anderer Stelle bereits realisiert sind und in der vorhanden Form genutzt werden können. Ein gutes Beispiel ist die bereits erwähnte Gazetteer-Funktion; ein entsprechender Web-Dienst wird vom LGB bereits angeboten, so dass der Aufbau einer eigenen Datenhaltung nicht erforderlich ist. An dieser Stelle macht sich für EduGIS auch die Trennung zwischen primärer Datenhaltung im Landesbehördennetz und den gespiegelten Daten zum Betrieb der Internetanwendung positiv bemerkbar. Bei regelmäßiger Aktualisierung wären selbst datenverändernde Zugriffe nur kurzzeitig aktiv (s.o.). Eine weitere Stufe der Absicherung ergibt sich durch die Einführung einer speziellen Security-Schicht ( Abbildung 5), die vor jeden Zugriff auf die Daten-Schicht zunächst prüft, ob der anfragende Nutzer berechtigt ist, die angefragte Aktionen auf einem bestimmten Datensatz auszuführen. Eine solche Security-Schicht muss hinsichtlich des verwendeten Protokoll transparent sein, um die Standardkonformität der im Rahmen von EduGIS bereitgestellten Dienste nicht einzuschränken. Datenzugriffe erfolgen so immer vermittelt, das heißt über einen Dienst (WMS, WFS). Dementsprechend sollten keine direkten Datenzugriffe vom Portal auf die Datenbank erfolgen. 29

30 Abbildung 5: Allgemeine Architektur zur Verwendung eines speziellen Proxies zur Absicherung von OGC Web Services (OWS) Um eine spezielle Security-Schicht für OGC Web Services (OWS) nutzen zu können, ist eine Nutzer- und Rechteverwaltung erforderlich. Wünschenswert ist ein single-sign-on Mechanismus, mit dem eine ggf. bereits erfolgte Authentifizierung bei einer anderen Web-Anwendung, beispielsweise einer Landesbehörde, übernommen werden kann. Dies scheint aus heutiger Sicht kaum realisierbar, da hier für ein Zugriff auf die Authentifizierungsmechanismen des Landesbehördennetzes erfolgen müsste. Ferner bliebe das Problem der Authentifizierung von Perso nen, die über keinen Account im Landesbehördennetz verfügen bestehen. Es ist daher davon auszugehen, dass für den Ausbau von EduGIS eine spezielle Nutzerund Rechteverwaltung einzurichten ist. Die Klärung der Frage ob diese in Bezug auf die registrierten Nutzer, ähnlich wie die Datenhaltung, regelmäßig gegen die primäre Nutzerverwaltung im Landesbehördennetz synchronisiert werden kann und soll, würde den Rahmen dieses Konzepts sprengen und ist zu gegebener Zeit im Detail zu evaluieren. Auch wenn die Umsetzung der beschriebenen Form der Absicherung von EduGIS nicht bereits in der ersten Version umgesetzt wird, ist sicher zu stellen, dass die eingesetzt Software grundsätzlich in der Lage ist, dies zu gewährleisten. Ob dies mittels Ergänzung durch andere Softwarekomponenten oder überschaubare Erweiterung der vorhandenen Implementierung geschieht, ist dabei zunächst uner heblich; die Entstehung von Abhängigkeiten zu lizenzkostenbehafteten Softwarekomponenten sollte aber entsprechend den Anforderungen des Betreibers von EduGIS auf alle Fälle vermieden werden. 30

31 4 Umsetzung 4.1 Zeitplan und Umsetzungsphasen Wie bereits dargestellt, wird die Aufgliederung der Umsetzung von EduGIS in mehrere Phasen/Ausbaustufen als sinnvoll erachtet. Dadurch wird es möglich, in mehreren Schritten die tatsächlichen Nutzer und deren Anforderungen zu ermitteln und die Anwendung gezielt um fehlende Funktionen zu erweitern. Dem hierdurch anscheinend zunächst entstehenden Mehraufwand stehen Einsparungen gegenüber, die sich aus dem Gewinn an Übersichtlichkeit, der Verringerung der Verwaltungsaufwände durch kleinere Projektgrößen sowie die Vermeidung der Realisierung nicht genutzter Funktionen resultieren. Dabei kann davon ausgegangen werden, dass die Einsparungen in der Regel überwiegen werden. Empfohlen wird die Aufteilung in zunächst drei Projektphasen. In der ersten Phase erfolgt die Initialisierung von EduGIS als Internetanwendung sowie die Bereitstellung eines Kartendienstes gemäß GDI Brandenburg. Im Verlauf einer sich an schließenden sechs bis zwölf Monate währenden Phase, wird die Anwendung pro duktiv betrieben. Während dieser Zeit werden das Nutzerverhalten sowie zusätz liche Anforderungen durch den Betreiber erfasst und in einem Anforderungskatalog für die dritte Projektphase zusammengestellt. In der dritten Umsetzungsphase werden die zuvor ermittelten zusätzlichen Anforderungen umgesetzt. Ist die verwendete Software (insbesondere der Portalsoftware), wie gefordert, modular aufgebaut, ist es möglich, die als Ergebnis der zweiten Umsetzungsphase be stimmten Anforderung sortiert nach ihrer Bedeutung schrittweise in EduGIS zu integrieren. Dadurch entfällt die Notwendigkeit und die damit verbundenen Risiken ein eingeführtes und funktionierendes System durch ein anderes zu ersetzen. Ferner ergibt sich aus der Möglichkeit, Ergänzungen in kleinen Schritten umzusetzen, ein höheres Maß an Flexibilität bei der Finanzierung. 4.2 Empfohlene Software Prämisse bei der Umsetzung von EduGIS ist die Verwendung von lizenzkostenfreier Software, wo immer dies möglich ist. Als Ergebnis der Evaluierung der Anforderungen an eine entsprechende Fachanwendung kann festgestellt werden, dass entsprechend den Anforderungen des Auftraggebers zur Umsetzung ausschließlich auf Open Source-Lösungen zurückgegriffen werden kann. Wie bereits dargestellt, stehen als Datenbanken mit PostgreSQL/Postgis und MySQL zwei in der Praxis bewährte Systeme zur Verfügung, wobei die Verwendung von PostgreSQL mit der PostGIS-Erweiterung aufgrund des umfangreicheren Funktionsangebots im Bereich Geodatenverarbeitung und weiteren Verbreitung im GIS-Umfeld empfohlen wird. 31

32 Zur Umsetzung des EduGIS Portals sowie des Kartendienstes sollte eine java-basierte Lösung zum Einsatz kommen. Ursächlich hierfür ist zum einen, dass entsprechende Komponenten beim federführenden Schulamt Wünsdorf bereits im Einsatz sind und Erfahrungen mit Java, JSP und Apache Tomcat vorliegen. Zum anderen ist Java im Umfeld von Open Source GIS-Lösungen weit verbreitet, so dass zahlreiche Komponenten zur Verfügung stehen. Durch Nutzung eines Apache Webservers als Fassade vor einem Tomcat ist es aber auch möglich, auf anderen Technologien (z.b. PHP) basierende Portale mit Java-basierte Diensten zu kombinieren. Bei Apache Tomcat handelt es sich zwar nicht um die einzige Open Source Implementierung einer Java Servlet Engine, doch bietet sie ein großes Maß an Flexibili tät und Stabilität. Aufgrund der weiten Verbreitung kann zudem davon ausgegan gen werden, dass für die meisten möglicherweise auftretenden Probleme eine Lösung über entsprechende Mailinglisten oder kommerziellen Support gefunden werden kann Geoportale Die folgende Tabelle gibt einen Überblick über verbreitete Open Source Lösun gen für Geoportale, die als Basis des EduGIS Portal genutzt werden können. Name Hersteller/ Verantwortlichkeit Lizenz GPL Technik CartoWeb Camptocamp deegree igeoportal lat/lon GmbH und Geogr. Institut der Universität Bonn LGPL/ GPL Java, JSP, HTML, JavaScript GeoExt Community Project GPL/ BSD JavaScript geomajas geosparc AGPL Java, GWT, JavaScript MapFish MapBender WhereGroup PHPJava, JSP, HTML, JavaScript GPL JavaScript, Python GPL PHP, HTML, JavaScript Tabelle 2: Verbreitete Open Source-Pakete für Geoportale Um vollständige Portale handelt es sich bei igeoportal, geomajas, CartoWeb und MapBender. MapFish und GeoExt sind eher als Komponentenbibliotheken anzuse hen, mit deren Hilfe sich Geoportale in unterschiedlichen Kontexten realisieren lassen. Die Vorteile der Nutzung eines vollständigen Geoportals zum Aufbau von EduGIS bestehen vor allem in der bereits aufeinander abgestimmten Zusammen stellung einer größeren Zahl von Komponenten und Modulen in einem Produkt. Die Konfiguration der Anwendungen ist einheitlich und in sich konsistent. 32

33 Insbesondere bei der Realisierung eines Portals, das vor allem Standardfunktionen bereitstellt, ergeben sich mit großer Wahrscheinlichkeit Kostenvorteile, da lediglich Anpassungen hinsichtlich des Layouts und der einzubindenden Datenquellen vorgenommen werden müssen. Das deegree igeoportal und MapBender sind seit über fünf Jahren auf dem Markt vertreten und werden in zahlreichen Projekten mit unterschiedlicher thematischer Ausrichtung und in verschiedenen Größenordungen erfolgreich eingesetzt. Sie verfügen daher über eine relativ große Auswahl an Modulen und Funktionen. Beide Projekte werden maßgeblich von deutschen Organisationen/Firmen entwickelt; die Realisierung von Projekten und der Support wird von mehreren Firmen angeboten. Die von der Firma Camptocamp betreute Portal-Software CartoWeb ist ebenfalls bereits seit mehreren Jahren verfügbaren, auf dem deutschen Markt allerdings kaum präsent. Dies ist wahrscheinlich dem Umstand geschuldet, dass das Projekt von einer Firma betrieben wird, deren Standorte in der Schweiz und in Frankreich liegen. Bei geomajas handelt es sich noch um ein recht neues Produkt, das vor allem von einer belgischen Firma betreut und vertrieben wird. Trotz der hohen Qualität der Anwendung sehen wir jedoch zur Zeit noch Probleme beim Funktionsangebot und Support; zurzeit gibt es keine deutsche Firma, die auf geomajas beruhende Portal-Lösung aktiv vermarktet. Bei MapFish und GeoExt handelt es sich wie gesagt vor allem um Komponentenbibliotheken. Sie ermöglichen den flexiblen Aufbau von Web-Anwendungen und Geoportalen, die über eine sehr individuelle Struktur und Funktionalität verfügen und/oder vollständig in einer bereits vorhandene Anwendung integriert werden sollen. Dieser Vorteil führt allerdings in der Regel dort, wo es um die Um setzung von Standardfunktionen geht, zu einem höher Aufwand und damit auch zu höheren Kosten. Exkurs Open Source-Lizenzmodelle An dieser Stelle kann keine umfassende Darstellung und verbindliche Bewertung von Open Source-Lizenzmodellen erfolgen. Eine Übersicht über die verbreitetsen Open Source-Lizenzmodelle findet sich unter: Es wird dringend empfohlen, die von der eingesetzten Software verwendeten Lizenzen genau zu prüfen. Aufgrund des zum Teil sehr unterschiedlichen Charakters besteht die Möglichkeit, dass einige Linzenzen den geplanten Einsatz einer Software nicht gestatten. In der Praxis bereiten die Apache License (Apache webserver und Apache Tomcat), BSD und LGPL in den meisten Situationen die wenigsten Probleme, da sie am wenigsten re striktiv bzw. viral sind. Im Fall der BSD-Linzenz ist aber genau zu prüfen welche Version verwendet wird. Problematischer ist Software, die unter der GPL veröffentlicht ist, da diese Lizenz einen viralen Charakter hat. Das heisst, eine Anwendung die eine unter der GPL veröffentlichte Bibliothek oder entsprechenden Code verwendet, muss ebenfalls unter der GPL veröffentlicht werden. Bei der Entwicklung von Software als aufführbare Pro33

34 gramme ist der Begriff 'verwenden' relativ eindeutig definiert, im Fall von Web-Anwendungen gilt dies jedoch nicht. Dem entsprechend liegen unterschiedliche Interpretationen hierzu vor. Unter anderem aus diesem Grund wurden mehrere Open SourceLizenzmodelle entwickelt, die speziell für Web-Anwendungen konzipiert wurden; die von geomajas verwendete AGPL ist ein Beispiel hierfür. Eine weitere Besonderheit stellt die von deegree igeoportal, GeoExt und MapFish verwendete JavaScript library extjs dar. Diese ist zunächst unter der GPL veröffentlich; es besteht jedoch die Möglichkeit, eine alternative unter einer speziellen Lizenz veröffentlichte Version beim Hersteller zu erwerben. Dadurch kann ein extjs nutzendes Portal alternativ unter einer weniger restriktiven bzw. viralen Lizenz bereitgestellt werden. Alle vorgestellten Portal-Lösungen können je nach Basistechnologie über einen Apache Web Server oder einen Apache Tomcat betrieben werden. Beide Server stehen sowohl für Linux/Unix als auch für Windows zur Verfügung. Die Unterstützung von 32 bit und 64 bit Betriebsystemen ist ebenfalls gewährleistet. Neben den genannten Portal-Lösungen und Komponentenbibliotheken existieren noch eine Reihe weiterer Projekte, die im Zusammenhang mit EduGIS aber zu vernachlässigen sind, da sie entweder thematische Nischen besetzen und/oder über keine angemessene Unterstützung im Umfeld des Landes Brandenburg ver fügen Kartendienste Zur Realisierung des Kartendienstes von EduGIS stehen im Wesentlichen vier Open Source-Lösungen zur Verfügung, die in der Tabelle 3 aufgeführt sind. Alle vier Kartendienste genügen den Anforderungen, wie sie im Sollkonzept GIB fest gelegt sind. Unterschiede ergeben sich vor allem hinsichtlich der zugrundeliegenden Konzepte und der verfügbaren zusätzlichen Softwarekomponenten (s.u.). Ein auch nur ansatzweise vollständiger Vergleich der vier Produkte würden den Rahmen dieses Konzepts bei weitem sprengen, es wird daher auf die Web-Seiten der entsprechenden Projekte verwiesen. Name Hersteller/ Verantwortlichkeit Lizenz Technik deegree WMS lat/lon GmbH und Universität Bonn LGPL Java Geoserver - GPL Java MapGuide Open Source Autodesk LGPL C++ UMN MapServer University of Minnesota Tabelle 3: verfügbare Open Source Kartendienste 34 MapServer License C

35 Innerhalb Deutschlands haben wahrscheinlich der deegree WMS, Geoserver und der UMN mapserver die weiteste Verbreitung. Da MapGuide Open Source sehr eng mit dem Softwarehersteller Autodesk verknüpft ist, kommt dieser vor allem im Umfeld Autodesk-basierten Lösungen zum Einsatz; die Verwendung im Umfeld von vollständig auf Open Source Basis realisierten WebGIS-Lösungen ist nicht üblich. Der deegree WMS zeichnet sich vor allem durch seine große Funktionalität und Flexibilität sowie den Umstand aus, dass er die offizielle Referenzimplementie rung des OGC für die WMS Spezifikationen und darstellt. Der von Geoserver realisierte Kartendienst unterscheidet sich hinsichtlich seiner Kernfunktionalität kaum vom deegree WMS, hat hinsichtlich der Einfachheit der Konfiguration aber Vorteile, da er standardmäßig mit einer web-basierten Konfiguration-An wendung ausgeliefert wird. Eine entsprechende Funktion steht für den deegree 2 WMS zurzeit in Form eines Plugins für OpenJump zur Verfügung. Beide Kartendienste sind als Java-Lösungen umgesetzt. Der UMN mapserver unterscheidet sich hinsichtlich seiner Funktionalität ebenfalls kaum vom deegree und Geoserver WMS ist jedoch nicht in Java sondern in C implementiert und erfordert zum Betrieb daher zwingend einen Apache Web Server (oder ein vergleichbares Produkt). Ferner bietet er aufgrund seiner Geschichte zahlreiche nicht zum OGC Standard gehörende Fähigkeiten, die jedoch nur von einer kleinen Zahl, zum Teil speziell für den UMN mapserver entwickelter Clients, genutzt werden können. Für den UMN mapserver stehen mehrere sowohl web-basierte als auch selbständige Anwendungen zur Verfügung, mit deren Hilfe Konfigurationen (mapfiles) erzeugt werden können. Unterstützung für alle drei Dienste wird von mehreren Firmen in Deutschland angeboten. Hinsichtlich der angebotenen Funktionalität ergeben sich bei den genannten Kartenserver in Bezug auf die Anforderungen von EduGIS keine signifikanten Unterschiede. Bzgl. der grafischen Qualität der produzierten Karten bietet der MapGuide WMS gegenüber seinen Konkurrenten zwar klare Vorteile, doch sind diese an die Verwendung von DWG-Dateien gebunden, die nur mittels AutoCAD Map oder eines vergleichbaren Programms erzeugt werden können. Unterschiede existieren vor allem im Umfang zusätzlich angebotener Funktionen, wie sie ggf. für wei tere Ausbaustufen von EduGIS wichtig sind. Während es sich bei MapGuide Open Source und UMN mapserver im wesentlichen um reine Kartendieste handelt (der UMN MapServer stellt auch einen rudimentären WFS bereit), lassen sich mit Geoserver und deegree weitere Dienste betreiben. Gemeinsam ist beiden Projekten die Unterstützung der OGC Web Coverage Service und Web Feature Service Spezifikationen zum Zugriff auf Raster- und Vektordaten. Mechanismen zum Datenschutz sowie eine Nutzer- und Rechteverwaltung werden dagegen nur von deegree angeboten. Die einzige zurzeit verfügbare freie Alternative diesbzgl. wird durch das Security Modul des Open Source Projekts 52 North bereitgestellt 35

36 Wie für die vorgestellten Portal-Lösungen gilt auch für die vier in Frage kommenden Kartendienste, dass sie in Abhängigkeit zur verwendeten Basistechnologie entweder über einen Apache Webserver oder einen Apache Tomcat betrieben werden können. Im Fall des Geoserver WMS gehört ein Jetty-Servlet-Container (Web-Server) zum Lieferumfang, doch hat sich dieser zumindest bei Verwendung der Voreinstellungen als nicht sonderlich stabil erwiesen, so dass entweder eine entsprechende Anpassung oder ein Umzug auf einen Apache Tomcat vorgenommen werden sollte (letzteres ist problemlos möglich). Alle vier Kartendienste sind zudem unter Windows und Linux lauffähig, wobei der MapGuide WMS bevorzugt unter Windows zu betreiben ist. 36

37 4.3 Aufwände und erforderliche Hardware Die in der ersten Phase umzusetzende Funktionalität bezieht sich vor allem auf Standardfunktionen, wie sie durch die meisten am Markt verfügbaren freien Lösungen realisiert werden. Ferner kann auf bereits bestehende Mechanismen der Datensynchronisation zurückgegriffen werden. Aufwände resultieren daher vor allem aus der Anpassung der Anwendung hinsichtlich Benutzbarkeit und einheitlichem Erscheinungsbild ("corporate identity"), der Installation und Konfiguration sowie der Umsetzung der Datenbank im Internetbereich inkl. der Synchronisation der Daten. Für die Realisierung der ersten Phase von EduGIS wird daher das folgende Vorgehen empfohlen: Vorbereitung 1. Erstellung eines Anforderungskatalogs auf Basis dieses Konzenpts 2. Erstellung der Ausschreibung Umsetzungsphase 3. Erstellen des Feinkonzepts 4. Implementierung fehlender Funktionen 5. Installation und Konfiguration Testphase 6. Durchführung der im Feinkonzept definierten Tests 7. Behebung von Fehlern Projektabschluß 8. Abnahme der Anwendungen 9. Start der Produktionsbetriebs 37

38 Der Zeitplan für die erste Realisierungsphase ist in der folgenden Abbildung wiedergegeben: Abbildung 6: Zeitplan für die Umsetzung der ersten Phase von EduGIS Die Umsetzung von EduGIS stellt keine besonderen Anforderungen an die verwendete Hardware. Als Server kann sowohl eine Workstation als auch ein BladeServer zum Einsatz kommen. Sollen Datenbank, Portal und Kartendienst auf einer Maschine betrieben werden, ist eine Ausstattung mit mindestens 4 GB Hauptspeicher erforderlich. Da die Datenmenge auch bei Berücksichtigung der Erstel lung von Zeitscheiben vergleichsweise übersichtlich ist, ist die Verwendung einer handelsüblichen Festplatte in der Größenordnung von 150 GB völlig Ausreichend. Im Hinblick auf mögliche Ausbaustufen sollte vor allem die Ergänzung des Haupt speichers möglich sein. Besondere Anforderungen an die Grafikkarte werden nicht gestellt. 38