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.

DotSpatial Architektur

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.

Feature Data Objects ArchitekturUnter 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..

6 thoughts on “Feature Data Object API und DotSpatial in .NET (1)”

  1. Hi BorutS,
    Thank you. You can download the FDO API at OSGeo: http://fdo.osgeo.org/ and the GUI for the library (FDO Toolbox) at http://code.google.com/p/fdotoolbox/.
    But: FDO is not an extension for DotSpatial. It has been discussed using FDO as a Data Provider extension for DotSpatial at http://dotspatial.codeplex.com/discussions/227263 but it has not been implemented yet. Hopefully it will be in future releases.
    At the moment you have to do it the – not quick – but dirty way as I have described it in http://www.sommer-forst.de/blog/2011/05/29/feature-data-object-und-dotspatial-in-net-2/ and http://www.sommer-forst.de/blog/2011/05/29/feature-data-object-und-dotspatial-in-net-3/

    Regards,
    Johannes

  2. Ok.
    So I will try to write a plugin by myself.
    Do you have any link, which would help me to start?
    How to write DotSpatial plugin (data provider) …

    Thank you in advance!

    1. Hi BorutS,

      I’m not sure if I understand you. Do you want to write a generic FDO data provider for DotSpatial? That would be really tricky I think, because the object model of FDO is quite complicated and abstract.
      Because of my limited knowledge with FDO and DotSpatial I’m only able to point you to examples how to access Shapefiles or ArcSDE through the FDO API in DotSpatial.I mentioned the articles in my last reply, where you can find useful information.
      Additionally I can provide you with a link of a „sort of ArcSDE-FDO data provider“ for DotSpatial in C# which could be a good way to start (please scroll all the way down):
      http://www.sommer-forst.de/blog/2011/05/30/arcsde-lesen-mit-opensource-gis-in-net/

      regards,
      Johannes

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert