This project is read-only.

FDO Support

Sep 15, 2010 at 7:15 AM

Hi All,

Allow me to introduce myself. My name is Jackie Ng.

I am a developer and Project Steering Committee member of the FDO (http://fdo.osgeo.org) and MapGuide Open Source (http://mapguide.osgeo.org) projects.

I am also the developer of FDO Toolbox (http://fdotoolbox.googlecode.com)

I have only recently started to follow this project with some interest, I have extensive knowledge of FDO, and would like to offer my abilities in adding FDO support to the DotSpatial project.

With introductions out of the way, I have some questions about the current data interfaces (namely IVectorProvider and IFeatureSet).

  1. The IVectorProvider interface seem to assume file-based data sources. FDO is agnostic about the data source. It could be file-based (SDF, SHP, SQLite), dbms-based (Oracle, SQL Server, PostGIS) or server-based (WMS, WFS). Is there a way to address this impedence mismatch? Or should I set my sights lower and just support file-based FDO providers for the time being?
  2. Is the FeatureSet class a good enough base-class to build FDO specific functionality on? Implementing IFeatureSet from scratch could take a while.
  3. FDO has a rich data model.
    • A FDO data store can have multiple feature schemas
      • Each schema can have multiple feature classes
        • Each feature class can have multiple data properties (attributes) and geometric properties
    • A layer would be mapped to a specific feature class and base its stylization and filters on the data and geometric properties of that feature class. However there doesn't seem to be anything remotely similar in DotSpatial. Implemeting the current IVectorProvider interface to support FDO would present lots of ambiguities. For example, I see a problem trying to implement  IVectorProvider.GetFeatureTypes(). It expects a file name, but my file could have multiple feature classes, each with various levels of geometry storage support (eg. One feature class could be points-only, another one could be polygons only, another may be a combination, etc). How can something like this be addressed?

The way I'm currently looking at DotSpatial, I could add FDO support but this support would only be available for a subset of all the FDO providers that are available due to the restrictiveness of the current data interfaces.

I'm potentially looking at DotSpatial to replace SharpMap in FDO Toolbox for my map rendering needs. So let's help each other ;-)

- Jackie

Sep 15, 2010 at 3:13 PM

A year ago i wrote a dataprovider for sharpmap in order to work along with FDO. FDO is really great i hope to support it really soon. I am currently developing a gis desktop application using mapwindow and FDO. My data are on ArcSde. This integration is what i am waiting for at least 2 years since i discovered mapwindow.

Sep 15, 2010 at 3:32 PM

While on the discussion of data sources.  What vector data source should be used to get the best performance out of DotSpatial?  I have been assuming shapefile, but I would sure love to find a way to greatly improve the layer load/display times and memory footprint.

Thanks.  Kyle

Sep 15, 2010 at 5:13 PM

Yes, this is something I have been thinking about as well.  We could certainly change the shapefile to load content on demand, render and then forget, rather than storing the data in ram.  Originally, our load times were so slow that we couldn't even think about this approach.  Now, it might be possible.  However, without some thought into creating extent trees (possibly R+ trees) in a file to serve as a geospatial lookup, I suspect that the linear process of working with entire shapefiles from disk would be substantially slower than what we have now and that people would complain about the diminished performance.  With extent trees, at least if you were zoomed in, it should be reasonably fast, even loading from disk.  Also, I haven't investigated the potential of the 4.0 Framework feature of "memory mapped files" yet, which might offer a way to host data from the disk for heavily used files faster than what we are currently doing.  The memory limitations for vectors seem to fall secondary to the memory demands produced by Rasters and Images.  Since large shapefiles only load the vector content (and page through attributes on demand), we can host fairly large shapefiles, but the memory performance shows the penalty.  The other thing is that potentially complex symbology schemes can be involved.  The strong point about the existing framework setup is that each "category" uses a filter expression.  Even though for our current implementation this boils down to building a lookup that ties each shape to a category, in the future we might not bother to assign this sort of lookup, but rather use the query itself to pull members from the database.  This approach would only make sense for cases like SQL Server where performing multiple, separate SQL queries can be performed faster than a linear cycle through the set and pulling out the ones that match.

Definitely things like SQL Spatial with built in extent queries have the potential to handle much bigger vector datasets.  I don't know about performance, but I assume it would be pretty good.  One thing that is good about the IImage interface is that it queries the extent and provides the pixel resolution required.  This allows data providers the ability to use their own optimizations to figure out whether they can show an overview or whether they should show a small part of a detailed view.  So far those implementations aren't ideal, but that technique allows for future optimizations to be handled from outside the framework itself.  We might be able to rework the vector interface to follow the same model, allowing data providers themselves to pick the best way to cycle features, and simply give them the instruction that they must draw a certain geographic extent at a certain resolution.

Our current "IFeatureSet" is mostly for users working with data and letting them cycle through each feature, especially in order to do topology calculations.  For rendering, we need much less information, and could make things substantially simpler and perhaps memory mapped, even when working with shapefiles.  Anyway, these are just some ideas swirling around in my head.

Ted

 

 

 

 

Feb 24, 2011 at 10:41 AM
xterm wrote:

A year ago i wrote a dataprovider for sharpmap in order to work along with FDO. FDO is really great i hope to support it really soon. I am currently developing a gis desktop application using mapwindow and FDO. My data are on ArcSde. This integration is what i am waiting for at least 2 years since i discovered mapwindow.

Me too, I would like to use MapWindow with ArcSde. Do you success in doing that ? If yes, how and in read/write mode or only read mode ?

Jun 5, 2011 at 8:45 PM
Edited Jun 6, 2011 at 6:07 AM

Hi,

I posted an example of connecting to a ArcSDE through the FDO API in .NET and getting the data & geometry in a DotSpatial.FeatureSet in my Blog.

The text is in german, but if you read the code you should not have troubles to understand.

FDO API in .NET with ESRI Shapefiles as an example:

http://www.sommer-forst.de/blog/2011/05/29/feature-data-objects-und-dotspatial-in-net-1/

http://www.sommer-forst.de/blog/2011/05/29/feature-data-object-und-dotspatial-in-net-2/

http://www.sommer-forst.de/blog/2011/05/29/feature-data-object-und-dotspatial-in-net-3/

FDO API with ArcSDE and DotSpatial:

http://www.sommer-forst.de/blog/2011/05/30/arcsde-lesen-mit-opensource-gis-in-net/

 

greetings,

Johannes