Schlussbericht DELPHI IMM GmbH. -gemäß Nr. 8.2 NKBF_98- Gesamtlaufzeit: Förderkennzeichen 50EE0909

Transkript

1 Schlussbericht DELPHI IMM GmbH -gemäß Nr. 8.2 NKBF_98- Gesamtlaufzeit: Förderkennzeichen 50EE0909 DeCOVER Konsortium Vertraulich Seite 1 von 66

2 Tabelle 1 - Autorenliste Name Datum Unterschrift Verfasser Ingrid Christ Prüfvermerk Rolf Lessing Freigabe Rolf Lessing Tabelle 2 - Dokumenthistorie Version Status: [F]inal/ [E]ntwurf Datum Durchgeführte Änderungen: Art, betroffene Seiten: 1.2 F Einarbeitung der Prüfvermerke Christ 1.1 E Prüfvermerke Lessing 1.0 E Erstellung des Abschlussberichtes Christ durch DeCOVER Konsortium Vertraulich Seite 2 von 66

3 Tabelle 3: Abkürzungsverzeichnis Abkürzung Bedeutung AD Ausgangsdienst DeCOVER umbenannt in Aktualisierungsdienst (AK) AK Aktualisierungsdienst DeCOVER AP Arbeitspaket ATKIS Amtliches Topographisch-Kartographisches Informationssystem BKG Bundesamt für Kartographie und Geodäsie CLC CORINE Land Cover CS-W Catalogue Service for the Web DIMM DELPHI IMM GmbH DLM Digitales Landschaftsmodell DLM-DE Digitales Landschaftsmodell für Deutschland ED Ergänzungsdienst DeCOVER umbenannt in Thematischen Dienst (TD) EW Erweiterungsdienst FAO Food and Agriculture Organization of the United nations FFH Flora Fauna Habitat FFH-LRT Flora-Fauna-Habitat, Lebensraumtypen LCCS 3 Land Cover Classification System, Version 3 LRT Lebensraumtypen MKB Mindestkartierbreite MKF Mindeskartierfläche MKF-E Mindestkartierfläche für Erweiterungen OAK Objektartenkatalog RE RapidEye AG SFE Satellitenfernerkundung TD Thematischer Dienst TÜP Truppenübungsplatz TZP Thematisches Zwischenprodukt WFS Web Feature Service (OGC-konforme Standard-Schnittstelle für Vektordaten) WMS Web Map Service (OGC-konforme Standard-Schnittstelle für gerasterte Bilder) DeCOVER Konsortium Vertraulich Seite 3 von 66

4 INHALT 1 Kurzdarstellung Partnerspezifische Aufgabenstellung(en) Voraussetzungen Planung und Ablauf Ausgehender wissenschaftlicher und technischer Stand Zusammenarbeit mit anderen Stellen Eingehende Darstellung Ergebnisse AP 1500: Aufbau DeCOVER Geodatenportal AP 1600: Entwicklung einer Marke DeCOVER AP 2100: Überführung sowie Integration in bestehende Systeme AP 2300: Weiterentwicklung Interoperabilität AP 3300: Entwicklung des Objektartenkataloges - Aktualisierungsdienst AP 4300: Entwicklung des Objektartenkataloges Thematischer Dienst Spezifischer Verwertungsplan Anlagen Anlage 1 Berichtsblatt Anlage 2 Erfolgskontrollbericht Anlage 3 Document Control Sheet DeCOVER Konsortium Vertraulich Seite 4 von 66

5 Abbildungsverzeichnis Abbildung 1: MapClient des Geodatenportals Abbildung 2: Architektur des DeCOVER Geodatenportals Abbildung 3: Metadaten-Editor Abbildung 4: Layer-Verwaltung Abbildung 5: Gruppieren und Bewerten von Objektarten Abbildung 6: Zusammenhänge zwischen Produkten und Marken (aus wikipedia.org) Abbildung 7: Darstellung der Fläche einer kleineren Gemeinde (ca. 50 km²), RapidEye Aufnahme Abbildung 8: Interoperabilität im Rahmen des DeCOVER Prozesses Abbildung 9: Basismodell einer Objektart für den Interoperabilitätsansatz in DeCOVER (vereinfacht) Abbildung 10: Basismodell einer Klassen-Ebene nach dem LCCS 3 Modell (vereinfacht). 36 Abbildung 11: Entscheidungsbaum für die Generalisierung nach der CLC Spezifikation Abbildung 12: Klassifikation auf Basis der DeCOVER Spezifikation Abbildung 13: Generalisierung auf Basis der CLC Spezifikation Abbildung 14: Vergleich der CLC 2000 Linien (in schwarz) und in DeCOVER erzeugten Linien auf Basis von RapidEye-Bildern (in rot) Abbildung 15: CLC 2000, Ausgangsdatensatz, 1: Abbildung 16: in DeCOVER aktualisierte CLC-Daten von 2009, 1: Abbildung 17: PointRemove mit 10 m Toleranz, 1: Abbildung 18: BendSimplify mit 10 m Toleranz, 1: Abbildung 19: PointRemove mit 50 m Toleranz, 1: Abbildung 20: BendSimplify mit 50 m Toleranz, 1: Abbildung 21: Smooth-PEAK mit 10 m Toleranz, 1: Abbildung 22: Smooth-PEAK mit 50 m Toleranz, 1: Abbildung 23: Interoperabilitäts-Prozesskette für die Rücktransformation Abbildung 24: Users accuracy der AAA-Klassen für Herne in aufsteigender Reihenfolge Abbildung 25: Klassen des DeCOVER Aktualisierungsdienstes, Stand Juni Abbildung 27: Basismodell in Protégé DeCOVER Konsortium Vertraulich Seite 5 von 66

6 Tabellenverzeichnis Tabelle 1 - Autorenliste... 2 Tabelle 2 - Dokumenthistorie... 2 Tabelle 3: Abkürzungsverzeichnis... 3 Tabelle 4: AP-Struktur der Vorhabensbeschreibung Tabelle 5: DeCOVER Arbeitspakete und Verantwortlichkeiten Tabelle 6: Einteilung des Diensteportfolios in die vorgeschlagenen Marken Tabelle 7: Anforderungen und Ergebnisse der Eingangskontrolle der rücktransformierten Herne-Daten (ATKIS AAA-Modell) sowie der rücktransformierten Zinna-Daten (DLM-DE) Tabelle 8: Überarbeiteter Stand der Basisanforderungen zur Interoperabilität Tabelle 9: Matrix zur Einschätzung der Topologie-Akzeptanz in Abhängigkeit der Toleranz und des Maßstabes für Daten basierend auf einer geometrischen Auflösung von 5m Tabelle 10: Mögliche Ursachen der falschen Klassenzuweisung bei Klassen < 50% Genauigkeit DeCOVER Konsortium Vertraulich Seite 6 von 66

7 1 Kurzdarstellung 1.1 Partnerspezifische Aufgabenstellung(en) AP 1500 DELPHI IMM hatte die Federführung für den Aufbau des DeCOVER Geodatenportals (Arbeitspaket [AP] 1500). Zu den Aufgaben des Geodatenportals gehörte die Weiterentwicklung des Portals durch die Integration von neuen Daten, der Entwicklung von Diensten zur Visualisierung des Projektfortschrittes sowie die Integration von Validierungsfunktionen der DeCOVER Produkte. Die Entwicklung der Validierungsfunktionen entstand für die Validierungsfunktion in enger Zusammenarbeit mit der GAF AG. AP 1600 DELPHI IMM war für die Entwicklung und Validierung der Marke DeCOVER zuständig. AP 2100 DELPHI IMM war in DECOVER 2 verantwortlich für den AP 2000 Bereich Interoperabilität und Datenvorbereitung. Innerhalb des Bereichs war DELPHI IMM zuständig für die zu aktualisierenden Datensätze und Überführung sowie der Integration der Daten in bestehende Systeme (AP 2100) und für die Weiterentwicklung der Interoperabilität (AP 2300). Die Arbeiten des AP 2100 umfassen die Vorbereitung der bestehenden Daten, die Hintransformation und die Integration der aktualisierten Daten in bestehende Systeme. AP2300 Für das AP 2300 wurden Methoden entwickelt, die eine Interoperabilität zwischen den Datenmodellen herstellt und Grenzen der Einsetzbarkeit aufgezeigt. AP 3300 Im Bereich der Weiterentwicklung und Umsetzung des Aktualisierungsdienstes (AP3000) hatte DELPHI IMM die Koordination der Definition und Optimierung des DeCOVER Aktualisierungsdienst (ehemals als Ausgangsdienst bezeichnet) inne. AP 4300 DELPHI IMM hatte die Koordination der Definition und Spezifikation der DeCOVER Thematischen Dienste (ehemals als Ergänzungsdienste bezeichnet) als Aufgabe. Aufgrund der festgelegten Nutzerwünsche und Zielsetzungen hatte DELPHI IMM jedoch keinen Einfluss auf die Festlegung der Definitionen von Klassen, wie dies ursprünglich vorgesehen DeCOVER Konsortium Vertraulich Seite 7 von 66

8 war. Es war jedoch möglich eine Analyse hinsichtlich der semantischen und geometrischen Interoperabilität an einem Thematischen Dienst durchzuführen und damit eine Sicht zu vermitteln. 1.2 Voraussetzungen Für das AP 1500 wurde von der Diensteintegration des bestehenden Geodatenportals ausgegangen. Aufgrund der veränderten technischen Anforderungen und veränderten technischen Möglichkeiten seit DeCOVER 1 bedurfte es jedoch einer technischen Überarbeitung. Die Integration der Validierung bezog sich zum einen auf die Funktionen des MapClients (wie die Kommentierung), zum anderen sollten die von der GAF AG und der Astrium GmbH erstellten Fragebögen integriert werden. Die fertige Erstellung (AP 5300) war Voraussetzung für die konzeptionellen Arbeiten und Implementierungsarbeiten. Die Integration eines Dienstes zur Visualisierung des Projektfortschrittes sollte zur besseren projektinternen Kommunikation und schnelleren Prozessanpassungen führen. Für diese Aufgabe erfolgten enge Absprachen in Bezug auf die Schnittstelle zur Prozesssteuerung (AP 3560) mit RapidEye AG (RE). Es hat sich herausgestellt, dass dieser Dienst redundant ist, da die RapidEye AG eine Webanwendung zur Überprüfung der Prozessschritte entwickelt hat, von der auch die Zwischenergebnisse runtergeladen werden können. Das AP 1600 Entwicklung einer Marke DeCOVER arbeitet sehr eng mit anderen Arbeitspaketen zusammen. Für die Definitionen von Markenkriterien war die Definition des Diensteportfolios, die Entwicklung des Objektartenkataloges sowie die Definition von Beschaffungsszenarien Voraussetzung. In einem rückkoppelnden Prozess wurden die Aufgaben mehrfach den gegenseitigen Anforderungen angepasst. Die Entwicklung von Interoperabilitätsmethoden (AP 2300) und die Integration der Aktualisierungen in bestehende Systeme (AP 2100) setzt die fertiggestellte Bearbeitung der Integrierten Veränderungskartierung voraus. 1.3 Planung und Ablauf Die Entwicklung von Interoperabilitätsmethoden und die Integration der Aktualisierungen in bestehende Systeme setzt die fertiggestellte Bearbeitung der Integrierten Veränderungskartierung voraus. Sowohl bei den Testkartierungen 1 als auch bei den Testkartierungen 2 kam es zu Verzögerungen. Die verspätete Lieferung führte auch zu Verzögerungen der Entwicklung der Interoperabilitätsmethoden als auch zur Durchführung der Transformation. DeCOVER Konsortium Vertraulich Seite 8 von 66

9 1.4 Ausgehender wissenschaftlicher und technischer Stand AP 1500: Bei der Entwicklung des Geodatenportal wurde die Spezifikation des OGC WMS berücksichtigt. Die Programmierung erfolgte mit der Standard-Programmiersprache für WebApplikationen JAVA. Die Browser Mozilla Firefox und InternetExplorer haben sich in den letzten Jahren rasant verändert. Damit waren die anfänglich betrachteten Browser-Versionen völlig überholt. Eine Anpassung des Geodatenportals an neue Browser-Versionen wurde vorgenommen, um weiterhin kompatibel zu bleiben. AP 3300: Das Land Cover Classification System FAO-LCCS wurde 1997 als universelles Bodenbedeckungssystem in einem hierarchischen System mit 8 Flächenbedeckungsklassen entworfen, wobei es mittels Detailinformationen noch weitere Subklassen gab. Ende 2009 entstand der Entwurf von LCCS 3, der sich auf einem generischen Ansatz begründet. Die FAO hat LCCS als internationalen Standard beim TC211 Technischen Komitee der Internationalen Organization for Standardization (ISO) beantragt. Die ISO spezifiziert eine Land Cover Meta Language (LCML), das erlaubt, dass mehrere Landbedeckungsklassifikationen erlaubt nach physiognomisch-strukturellen Gesichtspunkten beschrieben zu werden. Im vorliegenden Bericht wird ein Vergleich des LCCS 3 mit dem DeCOVER Klassifikationssystem (Aktualisierungsdienst) vorgenommen. 1.5 Zusammenarbeit mit anderen Stellen DeCOVER 2 ist sehr stark am Bedarf der Nutzer ausgerichtet. Deshalb macht es auch Sinn Nutzer für die Validierung der Ergebnisdaten mit einzubeziehen. Obgleich es nur eine geringe Teilnahme an aktiven Nutzern gab, waren doch viele Personen an der Präsentationen der Ergebnisse über das Portal interessiert. Die Einrichtung und Rechtevergabe (Daten, Dienste) lief bilateral zwischen den potenziellen Nutzern und DELPHI IMM. 2 Eingehende Darstellung 2.1 Ergebnisse In diesem Kapitel werden die durchgeführten Arbeiten und deren Ergebnisse entsprechend der AP-Struktur der Vorhabensbeschreibung erläutert. Tabelle 4 stellt die Gesamt-AP-Struktur des DeCOVER-Projektes dar. In diesem partnerspezifischen Bericht werden jene AP-Ergebnisse dokumentiert, die über den AP-Lead dem entsprechenden Partner zuzuordnen sind. Für die anderen AP-Teile sei auf die weiteren DeCOVER Konsortium Vertraulich Seite 9 von 66

10 partnerspezifischen Schlussberichte bzw. den übergreifenden Gesamtschlussbericht verwiesen. Tabelle 4: AP-Struktur der Vorhabensbeschreibung Haupt-AP Arbeitspakete Lead Partner AP 1000 Koordination EFTAS 1100 Administration EFTAS 1200 Öffentlichkeitsarbeit EFTAS alle 1300 Wirtschaftlichkeitsbetrachtung ITD alle 1400 Politikbereiche und Nutzerplattform EFTAS DIMM, ITD 1500 Geodatenportal DIMM GAF, ITD 1600 Entwicklung einer Marke DeCOVER DIMM alle AP 2000 Interoperabilität und Datenvorbereitung DIMM 2100 Datenvorbereitung / Integration in DIMM ITD bestehende Systeme 2200 SFE (Koregistrierung, Orthorektifizierung, IPI ITD, RE Bildaufbereitung) 2300 Weiterentwicklung Interoperabilität DIMM AP 3000 AK Weiterentwicklung & Umsetzung RE & ITD 3100 Weiterentwicklung zur Detektion von ITD alle Veränderungen 3200 Weiterentwicklung zur Erweiterung ITD GAF, RSS, EFTAS bestehender Landbedeckungsinformationen 3300 Weiterentwicklung des AK OAKs DIMM alle 3400 Weiterentwicklung zur Integration und RE ITD Prozesssteuerung 3500 Technische Umsetzung RE 3510 Objektverifizierung / ITD GAF, RSS, EFATS, RE Veränderungsindikation 3520 TZP Urban GAF 3530 TZP Gewässer und Naturnah RSS 3540 TZP Wald GAF 3550 TZP Agrar EFTAS 3560 Prozesssteuerung RE 3570 Integration RE AP 4000 Thematische Dienste Entwicklung EFTAS 4100 Methodenentwicklung zur Detektion von RSS IPI Veränderungen 4200 Methodenentwicklung zur Erweiterung IPI DeCOVER Konsortium Vertraulich Seite 10 von 66

11 bestehender Landbedeckungsinformationen 4300 Entwicklung der TD OAKs DIMM EFTAS, RSS 4400 Technische Umsetzung EFTAS 4410 TD Agrar EFTAS 4420 TD Naturnah RSS EFTAS AP 5000 Entwicklung einheitlicher Qualitätsstandards GAF 5100 Interne Qualitätskontrolle GAF 5110 Entwicklung interner Qualitätskriterien GAF 5120 Durchführung der Qualitätsprüfung intern GAF alle 5200 Externe Qualitätskontrolle GeoMLU 5210 Entwicklung von Methoden zur externen GeoMLU Qualitätskontrolle der DeCOVER Dienste 5220 Qualitätssicherung anhand eines GeoMLU unabhängigen Testgebietes (Blindtest) 5300 Produktvalidierung GAF 5400 Validierung der Funkionalitäten GeoMLU Tabelle 5: DeCOVER Arbeitspakete und Verantwortlichkeiten AP 1500: Aufbau DeCOVER Geodatenportal AP Ziele Das in DeCOVER 1 entwickelte Geodatenportal sollte für DeCOVER 2 als Diensteportal weiter betrieben und mit neuen Funktionen ausgestattet werden. Dabei wurden folgende Ziele verfolgt: Erhalt, Pflege und Betrieb des Portals Bereitstellung von webbasierten Komponenten, die in Phase 1 prototypisch umgesetzt wurden (Rechte- und Filemanagement) Entwicklung eines Dienstes zur Visualisierung des Projektfortschrittes Funktionen zur internen und externen Validierung der DeCOVER Endprodukte AP Ergebnisse DeCOVER Konsortium Vertraulich Seite 11 von 66

12 Abbildung 1: MapClient des Geodatenportals Abbildung 1 zeigt die letzte Version des DeCOVER Geodatenportals, bei dem sich auf der linken Seite alle einladbaren Layer (hängt von den Rechten ab) befinden. In der Mitte des MapClients wird die gerenderte Karte als Bild übertragen. Auf der rechten Seite sind die eingeladenen Layer dargestellt, die von hier aus für die Kartendarstellung gesteuert werden können (an/aus, Reihenfolge verändern, Layer entfernen). Diensteebene In der folgenden Skizze sind die wesentlichen Komponenten der Architektur des DeCOVER Geodatenportals aufgeführt. DeCOVER Konsortium Vertraulich Seite 12 von 66

13 Abbildung 2: Architektur des DeCOVER Geodatenportals Eine herausragende Eigenschaft der Applikationsebene ist, dass alle Komponenten so gestaltet sind, dass sie durch Komponenten z.b. eines anderen Anbieters im Prinzip ausgetauscht werden können. UMN-MapServer Web Map Service (WMS) Im Diensteportal wurde ein OGC-konformer Web Map Service (WMS) zum Abrufen von Kartenausschnitten implementiert. Der implementierte WMS liefert alle der drei charakteristischen Anfrage-Funktionen: o o o GetCapabilities, das dem Nutzer die abfragbaren Layer zurückliefert GetMap, das dem Nutzer ein georeferenziertes Rasterbild der karte zurückliefert GetFeatureInfo (optional), das dem Nutzer thematische Informationen für die angefragte Position zurückliefert geoway interface CS-W Die Entwicklung von geoway interface ist eine Implementierung der nach OGC- Standard CS-W Catalogue Service for the Web Specification für das ISO Application Profile Version 1.0 inklusive eines CS-W Server für Metadaten entsprechend der ISO und ISO (19139). Mit geoway interface wird auch DeCOVER Konsortium Vertraulich Seite 13 von 66

14 ein CS-W Client zur internen Abfrage und Prüfung es Servers ausgeliefert. Geoway interface wurde gegen die team engine des BKG auf Konformität gegenüber der Catalogue Service Implementation Specification und dem OpenGIS Catalogue Services Specification ISO Metadata Application Profile erfolgreich getestet. geoway mapclient-komponenten Der geoway MapClient wird in die Oberfläche integriert (Portal). Er basiert auf OpenLayers und stellt die nachfolgenden Funktionen zur Verfügung, wobei die Komponenten auf Serverseite verwaltet werden: o o o o o Navigation, Abfrage von thematischen Informationen, Anlegen von Projekten, Ausschalten der Hintergrundkarte, Möglichkeit der Kommentierung mit Raumbezug. Admin-Inferface Das Admin-Interface ermöglicht die Konfiguration des Systems: Benutzerverwaltung, Gruppen- und Regionenverwaltung Applikationsebene Die Applikationsebene beschreibt den Zugriff des Anwenders über eine Web-Oberfläche. Hier werden drei Zugänge unterschieden: DeCOVER-Portal Das Portal ist die eigentliche Web-Anwendung, die von jedem erreichbar ist. In Abhängigkeit vom Login hat der Nutzer die Möglichkeit o o o Daten auszuwählen (Ebenen) und diese nach eigenen Vorstellungen zu kombinieren und zu visualisieren Vordefinierte Projekte auszuwählen und mit diesen zu arbeiten oder Einen externen WMS in das Projekt zu integrieren Damit hat jeder Nutzer die Möglichkeit, die Daten nach eigenen Vorstellungen anzusehen und zu bewerten. Insbesondere die Integration eines WMS erlaubt einen Vergleich mit bekannten Daten. Damit kann die Validierung der Daten unterstützt werden. Als Hintergrunddaten dienen die OpenSource Daten von OpenStreetMap (OSM). Nach einem Login, der nur ausgewählten Nutzern gestattet ist, erweitern sich die Funktionalitäten und die verfügbaren Daten für den Nutzer. Jeder autorisierte Nutzer DeCOVER Konsortium Vertraulich Seite 14 von 66

15 hat die Möglichkeit, die Definitionen und die Zuordnung der Leserechte an den Informationen zu ändern. Metadaten-Editor Es wird ein ISO- und INSPIRE-konformer Metadateneditor zur Verfügung gestellt, mit dem die Metadaten für Datensätze und Services beschrieben und gepflegt werden können. Mittels eines Validators auf der Diensteebene wird sichergestellt, dass die Erzeugung der Metadaten konform den Vorgaben erfolgen kann. Der Zugang zu dieser Komponente wird reglementiert. Der Metdateneditor dient der Erhebung, Pflege und Veröffentlichung der Metadaten. Abbildung 3: Metadaten-Editor FTP-Manager Der FTP-Manager erlaubt autorisierten Nutzern Sicht auf die beim IPI verfügbaren Daten. Dieses dient zum Abgleich der beim IPI vorhandenen Daten mit den im Portal angemeldeten und zum Download der Daten. Weitere Funktionen sind: Layer-Verwaltung Der Zugang zum Reiter Verwaltung ermöglicht die Erstellung einer neuen DeCOVER Konsortium Vertraulich Seite 15 von 66

16 Layerebene, dem Editieren vorhandenen Ebenen oder dem Löschen einer Ebene. Abbildung 4: Layer-Verwaltung Export Der Export dient zum Download der ausgefüllten Fragebögen und zum Download von Marker-Shapefiles als Möglichkeit der räumlichen Kommentierung. Validierung Die Validierung bietet eine Schnittstelle zu den Online-Fragebögen in Bezug auf die Testdaten in den Testgebieten. Rechte- und Filemanagement Das Geodatenportal besitzt ein definiertes Rechtesystem für drei verschiedene Rollen (Nutzergruppen). Diese Komponente sorgt dafür, dass die Zugriffsrechte an die entsprechenden Komponenten weitergereicht werden. Die Kommunikationsstrukturen existieren sowohl innerhalb der Diensteebene als auch zu der Applikationsebene. Gast: Der Gast kann ohne Einloggen auf den MapClient zugreifen. Dabei stehen ihm nur ausgewählte Layer zur Ansicht zur Verfügung. Er erhält keine Rechte für weitergehende Applikationen oder Verlinkungen, wie Export, Verwaltung oder den Zugang zum Metadaten-Editor. Nutzer: Der Nutzer benötigt ein Login, mit dem er neben dem Standard-MapClient auch weitere Funktionen, wie Validierung, Anleitung Validierung und Handbuch nutzen kann. Der Nutzer erhält Zugang zu den Layern für die DeCOVER Ergebnisse und für alle Satellitendaten, die für die Produkte verwendet wurden. Partner: Die Partner haben Zugang zu allen Applikationen und zu den meisten Daten. Das Filemanagement beinhaltet sowohl die Verwaltung der Daten, als auch den Up- und Download-Prozess der Geodaten. Dabei ist die Verwaltung der Daten ist relativ komplex, da DeCOVER Konsortium Vertraulich Seite 16 von 66

17 die Zugriffsrechte jedes einzelnen Layers für Einzelpersonen und/oder Personengruppen zugewiesen werden können. Darüber hinaus können Zugriffsrechte für Datengruppen (z.b. CORINE-Daten von allen Testgebieten) und auch für Regionen gesetzt werden. Der Reiter FTP-Zugriff erlaubt eine Sicht auf die Daten vom IPI-Server und ermöglicht auch einen Download zum Abspeichern der physischen Daten auf dem lokalen Speichersystem. Für das Anmelden von neuen Ebenen im Portal besitzt jeder Projektpartner die notwendigen Rechte, so dass bei neuen Ergebnissen, Problemen und Absprachen eine schnelle Diskussion und bessere Absprachen ermöglicht wurden, denn ein Bild sagt mehr als 1000 Worte. Für das Anmelden von neuen Ebenen ist das Aufsetzen eines Map Servers und die Definition von MapDateien erforderlich. In einem WebMeeting wurde das Verfahren der Layer-Einstellung ins Portal vermittelt und die Dokumentation als PowerPoint-Folien sowie das Geodatenportal-Handbuch zur Verfügung gestellt. Pflege des Portals Eine kontinuierliche Pflege des Portals war während der gesamten Projekt-Laufzeit erforderlich für die Struktur: Neue Testgebiete mussten angelegt werden. Eine komplette Umstrukturierung erfolgte, da sich die alte Ebenenstruktur als überholt erwies. die Daten: Neue Daten wurden (meist) von DELPHI eingestellt. Dazu gehört die Definition der MapDatei, die Aufbereitung der Legende sowie die Erzeugung von Metadaten. Nicht verwendete Satellitendaten (für den Aktualisierungsdienst oder einen Thematischen Dienst) wurden wieder abgemeldet. die Software: Durch die Verwendung von neuen Browser-Versionen kam es auch immer wieder zur notwendigen Software-Anpassungen, um das Portal weiterhin lauffähig zu halten. Dienst zur Visualisierung des Projektfortschrittes Zur Visualisierung des Projektfortschrittes wurde ein Konzept entworfen und ein erster Prototyp implementiert. Durch die enge Abstimmung mit RapidEye konnte festgestellt werden, dass gleichzeitig das dashboard als internes Web-Tool für den Stand und Download von Zwischenergebnissen auch weiter ausgebaut wurde. Die Funktion der Projektfortschrittsfunktion stellte sich als redundant heraus und wurde in Abstimmung mit den Projektpartnern nicht weiter implementiert. Statt dieser Aufgabe wurde aufgrund der geringen Validierungsteilnahme (für Testumsetzung 1) die Funktionen zur Validierung nochmals verbessert und auch der Fragebogen gekürzt. DeCOVER Konsortium Vertraulich Seite 17 von 66

18 Funktionen zur Validierung In Abstimmung mit den Projektpartnern GAF und ITD wurde die Komponente der Produktvalidierung in das Portal integriert. Die Komponente besteht aus der Integration von Fragebögen sowie in der Ergänzung von spezifischen Validierungs-Funktionalitäten. Über den Reiter Validierung erhält der Nutzer eine Übersicht der vorhandenen Fragebögen (pro Dienst und Region) und die Information, wie viele Fragen bereits beantwortet sind. Die Auswahl des Fragebogens führt zu einer Zusammenstellung an Fragebogen-Blättern. Das Ausfüllen aller Fragen ist freiwillig, so dass es keine Pflichtfelder gibt und der Fragebogen auch völlig unausgefüllt beendet werden kann. Es erscheint lediglich ein Hinweis, dass noch nicht alle Fragen ausgefüllt wurden. Diese geringe Restriktion soll die Teilnahme an einer Validierung erleichtern. Neben den üblichen Online-Feldern, wie Freitext, Auswahl, numerische Felder, Datum gibt es noch die Möglichkeit mehrere Objektarten gemeinsam auszuwählen, zu gruppieren und gemeinsam zu bewerten. Die Fragbögen zeichnen sich durch besondere Nutzerunterstützung aus, wie beispielsweise die Farbzuordnungen aller Objektarten zu ihrer jeweiligen Objektgruppe (Wasser, Vegetation, Urban, etc.) und die Tooltips für die meisten Buttons. Abbildung 5: Gruppieren und Bewerten von Objektarten Weitergehende Information zum Nutzung des Geodatenportals stehen ausführlich im Geodatenportal Handbuch (RD-1) oder in der Validierungs-Anleitung (RD-2). Beides kann im Geodatenportal runtergeladen werden kann. DeCOVER Konsortium Vertraulich Seite 18 von 66

19 AP Bewertung Das Geodatenportal DeCOVER stellt mit dem aktuellen Versionsstand eine sehr gute, ausgereifte Portallösung dar. Es sind sehr viele Funktionen integriert, dennoch ist die Übersichtlichkeit erhalten geblieben. Die Standards wurden eingehalten und ein Datenaustausch mit Partnern stellt eine praktikable Lösung dar. Die Nutzung für projektinterne Absprachen erreicht leider nicht die erwartete Zugriffshäufigkeit. Dies liegt vermutlich an dem Punkt der Einhaltung der Standards für Externe. Dies bedeutet, dass ein WMS aufgesetzt und MapDateien konfiguriert werden müssen. Vielen Partnern fehlt es hierzu an Know-how. Deshalb wurde das flexible und offene Verfahren zur Einstellung von neuen Daten insofern abgeändert, dass die Layer-Ebenen durch DELPHI IMM eingestellt werden. Die Partner können sich für ihre relevanten Daten und Gebiete Projekte anlegen, und darüber in Kommunikation treten. Die Verfahrensänderung mit diesen in obwohl das System damit ein bisschen an Flexibilität verliert. Die Nutzung durch externe Validierer zeigt ebenfalls keine besondere Relevanz. Die Gründe hierzu können vielfältig sein: Von Zeitmangel, über mangelhafte Ergebnisdaten bis zur schlechten Bedienerführungen des Geoportals. Die Rückmeldungen zum Portal sahen aber so aus, dass die Nutzung als intuitiv eingeschätzt wurde. Es wurden keine wesentlichen Probleme genannt oder Fragen gestellt, die Hinweise auf Bedienungsprobleme sein könnten AP 1600: Entwicklung einer Marke DeCOVER AP Ziele Folgende Ziele wurden im AP 1600 verfolgt: Entwicklung und Validierung des Begriffs DeCOVER konform Erarbeitung von Kriterien zur Definition der Marke DeCOVER aus den Anforderungen der Interoperabilität, den Definitionen und Spezifikationen der Objektartenkataloge von Prüfverfahren und der Implementierung von Service Levels (SLA) AP Ergebnisse Die Vermarktung von Produkten im Bereich der Fernerkundung verläuft derzeit noch immer sehr stark projektbezogen. Wenn ein Kunde für ein definiertes Gebiet eine Aktualisierung eines bestehenden Katasters oder eine komplette Neuerhebung benötigt, dann schreibt er diese Leistungen aus. Dabei ist zu beobachten, dass die Anforderungen an die Produkte von Auftrag zu Auftrag unterschiedlich ausfallen können, oftmals bedingt durch die Tatsache, dass zwischenzeitlich neue Sensoren auf dem Markt sind, die eine weitergehende Produktdefinition erlauben. Für die Anbieter dieser Dienstleistungen ist es daher ein aufwendiges Geschäft: Er läuft sozusagen den Kundenanforderungen hinterher und muss sich immer wieder auf neue Entwicklungen einstellen bei gleichzeitigem Trend zu immer günstigeren Preisen. Damit DeCOVER Konsortium Vertraulich Seite 19 von 66

20 kommt der Anbieter in die Situation, nur für relativ große Auswertungsgebiete rentabel anbieten zu können. Gleichzeitig ist die Anzahl potentieller Kunden (bei großen Gebieten) relativ klein. Eine mögliche Strategie ist die Etablierung der Produkte als Marke. Sie ist dann dem Kunden über Namen und Logo bekannt, der Kunde kennt den Inhalt und den Einsatzbereich des Produktes. Markendefinition Abbildung 6: Zusammenhänge zwischen Produkten und Marken (aus wikipedia.org) Für die Klärung von weitergehenden Fragen war es zunächst unerlässlich die Begrifflichkeiten zu klären. Dabei stellte sich heraus, dass eine Marke laut Wikipedia in erster Linie in rechtlicher Sicht beschrieben ist. Eine Marke stellt ein rechtlich geschütztes Zeichen für Waren oder Dienstleistungen dar (Wikipedia). Erst in zweiter Linie wird mit dem Begriff Marke die Marketing-Sicht definiert. Dabei steht die Marke für alle Eigenschaften von Markenobjekten (Waren, Dienstleistungen oder auch Unternehmen), die sich von konkurrierenden Markenobjekten unterscheiden. Die Abbildung 6 zeigt sehr anschaulich die Zielstellung des Markeninhabers gegenüber den potentiellen Kunden. Über das Fremdbild werden die Produkte den Zielgruppen angepriesen. Dieses Fremdbild kann natürlich vom Selbstbild als auch von den tatsächlichen Eigenschaften des Produkts abweichen. An DeCOVER Konsortium Vertraulich Seite 20 von 66

21 zentraler Stelle stehen jedoch die Eigenschaften der Markenobjekte, die wettbewerbsdifferenzierend Objekte, die einen Markennamen repräsentieren, von konkurrierenden Objekten anderer Markennamen abgrenzen. Darüber hinaus existiert noch der Begriff der Dachmarke, der in Wikipedia als übergeordnete Marke mit besonders hohem Wiedererkennungswert und Akzeptanz, aber ohne eigene Produkte / Dienste beschrieben wird. Ausgestaltung der Marke DeCOVER Bei der Ausgestaltung der Marke wurden folgende Thesen aufgestellt: These 1: Eigenschaften als zentraler Aspekt. These 2: Differenzierung als wesentliches Element These 3: Rechtliche Aspekte: Das Schützen einer Marke ist mit viel Aufwand und Kosten verbunden und garantiert nicht so viel Schutz wie ein Patent. Da die Zielgruppe im Geobereich relativ klein ist, scheint eine Auseinandersetzung mit diesem Thema sekundär. These 4: Selbstbild und Fremdbild: Der Aufbau einer Markenidentität wird meistens anbieterbezogen aufgebaut und stellt das Selbstbild dar. Dieses ist in der Regel getrieben durch die Eigenschaften des Produkts. Auf Seiten der Nutzer stellt sich ein Fremdbild ein, das nur in geringem Maß steuerbar ist. Dieser Aspekt muss bei einer möglichen Realisierung beachtet werden. These 5: Dachmarke: Die Einführung einer Dachmarke könnte sinnvoll sein, um der Vielzahl an unterschiedlichen Auswertungen in der Fernerkundung gerecht zu werden. Dann könnten die einzelnen Produkte eigene Marken darstellen, die unter einer Dachmarke wiederzufinden sind. These 6: Nutzung des Begriffs DeCOVER als Markennamen. Die Hochschule Beuth, die sich mit dem Thema Markenbildung und als Beispiel DeCOVER beschäftigt haben, kamen zu dem Schluss, dass der Begriff DeCOVER bereits für ein Forschungsvorhaben mit noch unscharfen Eigenschaften und Ergebnissen etabliert hat. Damit ist das Fremdbild bereits geschaffen; die Beuth-Gruppe rät zum neuen Markenbegriff. Der große Vorteil der Beibehaltung der Bezeichnung DeCOVER liegt jedoch in der großen Verbreitung. Sehr viele in der Fernerkundungswelt haben schon davon gehört. Bei Beibehaltung der Bezeichnung besteht die große Aufgabe in der Verankerung von definierten positiven Eigenschaften. Eine abschließende Benennung kann das AP innerhalb des Projektes nicht leisten. Dies sollte bei Bedarf im Anschluss an das Projekt von einer externen Namensagentur durchgeführt werden. DeCOVER Konsortium Vertraulich Seite 21 von 66