DotSpatial, SharpMap/MapsUi and FdoToolbox... a bit confused

Jan 28, 2011 at 9:42 PM

Hi everyone,
in this period I'm evaulating the main open source projects for GIS .NET development. I've found DotSpatial to be an interesting effort to wrap various developments, and I've studied it's data model as it is my main concern: having something similar to Qgis data providers, or FDOToolbox. I've found that MapWindow hasn't implemented a generic provider mechanism, nor a plugin/extension architecture, while I've found a more mature model in SharMap/MapsUi project (I though they had converged in DotSpatial too, but I see it continues an independent development), or FDOToolbox... 
So I'm wondering about these two main aspects: providers and extensions. Are they on the DotSpatial roadmap? Are you considering them? And, last, a questin I should ask the other two projects too: are you consideing a convergence of the efforst to realize a common base model (at least geometries, features, etc.) like Geotools and JTS are in the Java world?

Thanks for you attention and forgive the question, maybe too generic and wide! 
Giovanni 

Developer
Jan 28, 2011 at 10:21 PM
Edited Jan 28, 2011 at 10:25 PM

We currently use data extensions that can be dynamically set up (like a plug-in).  That is, you can build your own dll file that implements IVectorProvider, IRasterProvider or IImageDataProvider in order to host conventional data formats.  Drop the dll into the "Data Extensions" folder and it can give DotSpatial the ability to read new formats without having to recompile DotSpatial.  The main example of this is the GDAL data extension.  Plugins or Apps are done the same way.  That is, you can implment the IMapPlugin interface, and I think you must mark your assembly as a plugin with the appropriate attribute in the assembly properties.  The main example of how to do this is the ShapeEditorApp.  This plug-in shows how to create a custom dll that can be dropped into the Apps folder or Plugin folder in order to provide the user with new functionality.  Both of these concepts are portable to other applications by the use of a component.  If you create a new project and introduce the AppManager component to your project, you bring along with it automatically the ability to support Data Extensions.  You can use properties on the AppManager to wire up or connect together controls that are part of DotSpatial.

MapWindow also supports plugins.  It is not quite as generic since it requires you to be working from within the MapWindow application itself, rather than with the ActiveX map.  However, if you implement the IPlugin interface found in MapWindow.Interfaces.dll, you can create a plug-in that MapWindow will recognize.  You can effectively create a data provider in that context by translating the original source data into a shapefile, image or grid.  For MapWindow 4.x you will need to have a file based shapefile.  For DotSpatial, the FeatureSet can be entirely in ram.

As far as merging with NTS and SharpMap, we we are hopefully drawing people into the idea of using at least some parts of DotSpatial and merging it with our other open source initiatives in .Net.  Obviously the more connected our open source ventures can become, the more benefit we all gain.  That process is quite young and hasn't had a lot of paid energy directed towards it.  DotSpatial is open and ready for modification, and "DotSpatial.Topology" is essentially just a version of NTS, and "projections" is just a port of the parts of proj4 that coincide with supported ESRI projections.  The roadmap hopefully will feature a merger of our Topology version with the current NTS, but there may be advantage to keeping our own variant alive.  The first aim of the ISU group that started the project is to try to meet the objectives of our paying clients.  These focus on hydrologic analysis, terrain analysis, and some fairly conventional GIS use-cases.  So you can expect to see a fleshing out of the toolbox in those areas.  However, we are seeing a lot of talented outside contributions that have completely different priorities, like getting WMS support online and updating our GDAL library aspects etc.  All parties benefit from the basic testing and debugging that happens the more we use the tools.

I am not all that familiar with what you can get from FDOToolbox (I think for Feature Data Object right?).  I have heard of FDO and know that it might be useful to incorporate it as a data access tool.  I believe there is work being done by a group to get the OGR feature data provider online in DotSpatial and have seen updates pertaining to that in several posts, but I'm not sure where that effort stands at the moment.

This library is not yet "mature" as you phrased it.  It is still in it's alpha stages and will probably see some further rearrangement, but hopefully it will be minor.  Dan hopes for us to have a stable release by our conference in San Diego this summer.  That should represent something that will have a more or less fixed architecture and we should be seeing much more in the way of geoprocessing and modeling tools being developed and less emphasis on the core framework design.

Ted

 

 

Jan 29, 2011 at 12:46 PM

Thanks Ted for the thorough answer. I will follow with great interest the development of the future months, hoping to have the occasion to contribute. 
About IVectorProvider, it assumes a simple file based data access interface  (as it was stated in a previous discussion http://dotspatial.codeplex.com/Thread/View.aspx?ThreadId=227263), a bit naive for a general model (db providers, network, etc.). Anyway I understand it's a work in progress, so don't consider this a critic, obviously.
I didn't notice the progresses with plugins/extension management, forgive me. 

I hope a more coherent and shared data access interfaces will be estabilished in the future. I think this is one of the great strength of Geotools: almost every Java OS software is using it, basing their development on a shared founded base, which also helps in exchanging experience, code, etc...

Thanks for you effort, and your support.
Giovanni 

 

Coordinator
Jan 31, 2011 at 5:08 AM
Ted may have more to add to this, but I can tell you that the data provider model we are using is definitely NOT constrained to simple file formats. Indeed that's the main reason why we've moved to a data provider model. In MapWindow we continue to struggle to add new file formats, databases, etc, since they pretty much all require some modification of the core C++ activeX component. We prefer not to make major modifications to this component all the time because of a desire to maintain stability. The DotSpatial model was born from the idea of wanting to provide new data sources, layer types, and indeed to support most elements of the project through an interface so that developers can rethink various aspects of the project without having to modify the full thing - much in the same way as GeoTools has done.

One other quick note. Ted pointed out the need for our various teams of programmers to "follow the money". Well as it turns out, one of our key partners has requested that our next funded activity will be creating a clear roadmap for the project. I'll be working on a draft of this in the coming week and will be interested in feedback from all users and developers on the project.

- Dan

On Sat, Jan 29, 2011 at 6:47 AM, giohappy <notifications@codeplex.com> wrote:

From: giohappy

Thanks Ted for the thorough answer. I will follow with great interest the development of the future months, hoping to have the occasion to contribute.
About IVectorProvider, it assumes a simple file based data access interface (as it was stated in a previous discussion http://dotspatial.codeplex.com/Thread/View.aspx?ThreadId=227263), a bit naive for a general model (db providers, network, etc.). Anyway I understand it's a work in progress, so don't consider this a critic, obviously.
I didn't notice the progresses with plugins/extension management, forgive me.

I hope a more coherent and shared data access interfaces will be estabilished in the future. I think this is one of the great strength of Geotools: almost every Java OS software is using it, basing their development on a shared founded base, which also helps in exchanging experience, code, etc...

Thanks for you effort, and your support.
Giovanni

Read the full discussion online.

To add a post to this discussion, reply to this email (DotSpatial@discussions.codeplex.com)

To start a new discussion for this project, email DotSpatial@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
Daniel P. Ames, Ph.D. PE
Associate Professor, Geosciences
Idaho State University - Idaho Falls
amesdani@isu.edu
geology.isu.edu
www.mapwindow.org


Developer
Jan 31, 2011 at 3:42 PM

I think what he means is that right now the GUI is only really set up to allow for file based extension support.  That is, we are using an open file dialog and the provider tells us what file extensions the support.  The basic concept is not restricted to this, but we don't have a GUI that is set up to allow for database connections.  This functionality can easily be accommodated currently through a more standard Plugin/App which would provide a menu or button or something so that the user could set up their data connection.  I'm not sure how the guys that are working on OGR are handling it yet.  What we have not done is created a standard form for linking into databases or a standard form for linking to WMS, WFS, WCS, or WPS.  We have discussed this sort of idea in some kind of comprehensive custom data source browser, but there has always been more pressing stuff and re-inventing the file browser would be a non-trivial amount of coding to get it up and running.  It wouldn't take as much to set it up with a separate open capability that handles database connections though.  But there is a lot to think about there.  What kinds of database connectivity can we support etc.  Before we go too far in that direction I was hoping to get the FeatureRow/FeatureTable pair in use by the Map.  This newer set of tools is very cool and built through inheritance.  It is much more tightly synchronized with a standard DataRow than IFeature.  IFeature is very easy to break apparently because it's link to DataRows can get desynchronized from the DataTable on the FeatureSet.  But in the FeatureRow/FeatureTable setup, the FeatureTable is like the FeatureSet, except that each feature IS a datarow, rather than simply pointing to one.  This is way more stable, but required advanced techniques that may not even have existed when we first got started thinking about how to tie features to attributes.  It's what I had envisioned early on, and would work very well in the database case.  So I think the next step in the whole standardized database support is to make sure that this new set of classes can be rendered in the map correctly in layers.  Anyway, some thought and development here is in progress, so in the meantime, people are simply loading the data into our FeatureSet class.  Many people have set up this kind of behavior independantly.  I believe people have written not just links to OGR, but also to SQL Spatial.  You simply handle the database access like you normally would and then you can use the WKBFeatureReader and other helper classes in order to create FeatureSets, which can be used.  However, some coding is required there, and no standardized approach has been set up to do that for you.

So the to do list for a standardized support of database models reads:

1) Layers to draw from existing FeatureTable.

2) A standard form for connecting databases

3) Setting up a demonstration database plug-in like a SQL Spatial or Spatial Lite plug-in.

4) Translation code between FeatureSet and FeatureTable in case it's desired.

5) Optionally for getting fancy we can look at a custom file browser that shows shapefiles with cute icons for point/line/polygon identification that would hide all the associated files (or maybe allow them to be expanded using a tree or something.)  While nice, this is the sort of thing that tends to burn developers in the future as windows puts out ever-fancier open file dialogs and developers would be forced to try to re-create this fanciness.  I'm not sure how much energy is worth being invested here, but I think there is a FileBrowser control, and it might be customizable, but I doubt it because I think it uses the WIN32 API under the hood.  That is when you drag and drop a "FileBroser" dialog, you are actually not using pure .Net, but are cheating.  Fortunately for us, it's such a convenient and frequently used use-case that Mono has implemented the file browser in such a way that it will run cross platform.

Ted

 

 

 

Feb 1, 2011 at 9:26 AM

Thanks again for the explanations, and forgive me for the delay in my reply - I was away for a congress - 

I see a lot of core work in progress, and I perfectly understand and agree that the efforts must be directed toward this. The FeatureRow/FeatureTable model is a great approach that can bring interesting features. I thought you had already estabilished these core things, but I see a lot has to be done yet, and that's a great opportunity to setup a smart architecture. I come from the QGis and Geotools world, so I'm biased toward their solutions, but I'm conscious that new, and more .NET oriented, approaches can lead the project toward great results.

I hope to find founds to contribute to it, first of all to the roadmap you're going to provide.

Thanks again,
Giovanni