Zusammenfassung
Amtliche Geodaten und Webdienste werden heutzutage unter Beachtung von Richtlinien (z. B. Produktspezifikationen) erstellt und auf Richtigkeit, also auf Konformität zu diesen Vorgaben geprüft. Komm en automatisierte Prüfwerkzeuge zum Einsatz, erfolgt dieser Prüfprozess meist durch die verwendete GIS-Software mehr oder weniger in einer Blackbox, wobei oft nicht klar ist, was genau getestet wird und welche Fehler möglicherweise von einer Produktionssoftware toleriert werden. Wie auch immer, aufgrund fehlerhafter Daten und nicht konformer Webdienste kommt es bei der Zusammenführung von Datenbeständen immer wieder zu Problemen, obwohl sie eigentlich einen Qualitätssicherungsprozess beim Datenerfasser durchlaufen haben müssten.
Das Testen von Geodaten unabhängig von einer GIS-Software in einer Testumgebung im Internet (auch Test Framework oder Testsuite genannt) ist im Vergleich zum Testen von Webdiensten eine vergleichsweise neue, komplexe und technisch sehr aufwendige Disziplin, mit oft noch unbekannten Folgen für die Performance von Prüfläufen. Daher sollte zunächst im Rahmen eines Pilotprojektes die Realisierbarkeit anhand repräsentativer Prüfkriterien nachgewiesen werden. Vorranging sollte dies für AFIS-ALKIS-ATKIS-Bestandsdaten gemacht werden, da hier aufgrund der nunmehr flächendeckend verfügbaren Daten ein erheblicher Handlungsbedarf im Hinblick auf eine nachhaltige Qualitätssicherung besteht.
Mit der Pilotierung einer Testsuite für Datentests verfolgte die Arbeitsgemeinschaft der Vermessungsverwaltung der Länder der Bundesrepublik Deutschland (AdV) zwei wesentliche Ziele:
1. Die Ermittlung technischer Möglichkeiten und Grenzen von unabhängigen Datentests.
2. Die Initiierung der Erstellung eines umfassenden abgestimmten Katalogs mit zu prüfenden Testkriterien, damit ein Datensatz vollständig den Anforderungen der NAS und des AAA-Anwendungsschemas der GeoInfoDok entspricht.
Das AAA-Anwendungsschema enthält bereits in verschiedenen Bereichen Qualitätsanforderungen. Schwerpunkt dieses Projekts ist die automatische Überprüfung von Anforderungen, die oft nur textlich in Form von Konsistenzbedingungen und Bildungsregeln in der GeoInfoDok formuliert sind. Qualitätsanforderungen, die schon jetzt relativ einfach mit Standardwerkzeugen überprüft werden können, wie z. B. die Validität einer XML-Datei, wurden nur am Rande betrachtet. Dieser Bericht dokumentiert die bisherigen Ergebnisse dieser Pilotierung.
Summary
Since the early beginning official data is collected following requirements of consolidated product specifications and their correctness (conformance to the requirements) is checked. Usually this quality check is done by the GIS implementation, which can be considered as a black box testing, where as it is often not clear, what is tested in detail and which errors are tolerated by the software. The result is, that problems occur when central data providers try to merge data sets coming from different states, although they have passed a quality check by the responsible data collector.
The software-independent test of spatial data with an online test framework is a fairly new discipline compared to the test of web services. Additionally, it is very complex and technically demanding, with up to now unknown consequences for the performance of such test processes. Therefore, it should be figured out in a pilot project how feasible an implementation is by using representative test criteria.
With this pilot project, the surveying and cadastral authorities in Germany wanted to address the following two issues:
1. Evaluation of technical possibilities and limits of software independent data tests.
2. Starting a common process on the definition of a comprehensive and consolidated set of test criteria in order to allow reliable conformity statements of the produced data.
The German data model for reference data (AAA application schema) comprises quality requirements in several areas. The main focus of this project is the automated test of requirements which are only textually formulated consistency requirements as well as data capture rules. Quality requirements, which can already be tested by commercial tools, such as a valid XML document, are not focus of this presented work. This article documents the results of the pilot project.
