Feature Data Object API und DotSpatial in .NET (1)

DotSpatial

DotSpatial ist eine sehr gut dokumentierte, quelloffene GIS – Bibliothek für .NET 4. In diesem Projekt sind einige Open Source basierte GIS-Bibliotheken zusammen geflossen – unter anderem MapWindow6, ProjNET oder GPS.NET3. Auch Entwickler von SharpMap sind bei dem groß angelegten Projekt dabei. Gute Tutorials zu DotSpatial für den Einstieg findet man hier. SharpMap ist zwar ganz toll – es existiert ja auch schon länger für .NET. Aber DotSpatial ist wirklich der Hammer!

Project Vision: DotSpatial aims to provide a free, open source, consistent and dependable set of libraries for the .NET, Silverlight and Mono platforms, enabling developers to easily incorporate spatial data, analysis, and mapping into their applications thereby unleashing the massive potential of GIS in solutions for organizations and communities of all types in a nonrestrictive way.

Mit DotSpatial kann man – ohne viel Programmierkenntnisse zu besitzen – ein kleines GIS zusammenbasteln. Mit der entsprechenden Entwicklungsumgebung (MS Visual Studio Express oder SharpDevelop) kommt man schon mit Drag&Drop so weit, dass man die meisten Funktionen von DotSpatial nutzen kann. Bei DotSpatial werden die entsprechenden GIS-Controls mitgeliefert – so wie man es vielleicht von anderen kommerziellen GIS-Bibliotheken kennt. Man merkt schon: Ich bin begeistert..

Im aktuellen Release von DotSpatial kann die Bibliothek mehrere Geodatenformate (sowohl Vektor- als auch Rasterformate) lesen. Schreiben kann es auf jeden Fall ESRI Shapefiles. Seit kurzem gibt es auch einen experimentellen lesenden Datenprovider für PostGIS und SpatiaLite. Schöne Sache – aber es gibt ja noch mehr Geodatenbanken bzw. Middleware auf diesen.  Ich wollte also lesenden Zugriff auf die ESRI ArcSDE in einem eigenen GIS-Viewer realisieren.

Nach etwas Recherche kam ich auf die Feature Data Object API.

Feature Data Object API

Die Feature Data Object API ist ein OSGeo-Projekt, das ursprünglich von Autodesk entwickelt wurde. Es stellt ein abstraktes Objektmodell für Geodaten dar, das viele Geodatenformate lesen und schreiben kann.

FDO Data Access Technology is an API for manipulating, defining and analyzing geospatial information regardless of where it is stored. FDO uses a provider-based model for supporting a variety of geospatial data sources, where each provider typically supports a particular data format or data store. FDO (“Feature Data Object”) is free, open source software licensed under the LGPL.

Unter anderem liest diese Bibliothek ESRI ArcSDE, OGR/GDAL, OGC Web Services, MySQL und mit einem proprietären Provider auch Oracle Spatial. Eine vollständige Liste und die Möglichkeiten der Provider findet man hier.

Interessanterweise setzt auch safe die FDO API in ihrer FME-Software ein. Auf jeden Fall ist die Bibliothek Open Source und sowohl in C++ als auch in .NET einsetzbar. Eine GUI für die API ist die FDO Toolbox.

So wunderbar die Dokumentation von DotSpatial für den Anfang auch ist – bei FDO fuer .NET muss man schon länger suchen und einiges ausprobieren. Zwar gibt es einiges an Doku auf der Seite der FDO. Allerdings fehlten mir praktische Beispiele für den schnellen Einstieg. Hilfreich war aber dieses Tutorial:

„Taking Geospatial Data Access to the next level with the FDO API“

Voraussetzungen für die Verwendung der FDO API in .NET

Im Ausgabeverzeichnis (bin\Debug oder bin\Release) des Visual Studio-Projekts müssen folgende Assemblies von FDO liegen:

• Fdo.dll
• FDOCommon.dll
• FDOGeometry.dll
• FDOMessages.dll
• FDOSpatial.dll
• OSGeo.FDO.dll
• OSGeo.FDO.Common.dll
• OSGeo.FDO.Geometry.dll
• Xalan-C_1_11.dll
• XalanMessages_1_11.dll
• xerces-c_3_1.dll

Direkt arbeitet man in .NET nur mit den Assemblies im Namespace OSGeo, die dem entsprechend auch im Projekt referenziert werden müssen. Die anderen oben aufgeführten DLLs werden von diesen Assemblies jedoch auch im selben Verzeichnis benötigt. Darüber hinaus existieren noch mehr Assemblies der Provider für die FDO, die jedoch nicht im Ausgabeverzeichnis sein müssen. In der Datei providers.xml werden die Datenprovider und der Pfad zu diesen DLLs und den weiteren abhängigen DLLs angegeben. Dieses XML sollte den Bedürfnissen (v.a. beim Tag LibraryPath) entsprechend angepasst werden und auch im Ausgabepfad der Anwendung gespeichert sein.

Eine mögliche Konfiguration ist dabei, dass die Core-Assemblies (s.o.) und die Datei providers.xml im Ausgabeverzeichnis sind und die eigentlichen Datenprovider mit deren Abhängigkeiten in einem Unterverzeichnis des Ausgabepfads. Im Beispiel oben habe ich einen Unterordner FDO_3.6.0 angelegt.

Außerdem sollte man gleich alle Namespaces von FDO per using-Direktive ins eigene Projekt einbinden:

//FDO
using OSGeo.FDO;
using OSGeo.FDO.Connections;
using OSGeo.FDO.Common;
using OSGeo.FDO.Schema;
using OSGeo.FDO.Commands;
using OSGeo.FDO.Geometry;
using OSGeo.FDO.ClientServices;
using OSGeo.FDO.Commands.DataStore;
using OSGeo.FDO.Commands.Schema;
using OSGeo.FDO.Expression;
using OSGeo.FDO.Commands.Feature;
using OSGeo.FDO.Filter;

Weiter gehts im nächsten Teil..