[Geotools-devel] Re: [udig-devel] Local File Format

[Carl A. <car...@va...>]

While investigting a PostGIS driver for FDO a month or so ago I found.....

The SDF fomat is a SQLite database with limited spatial filters.

C.

Jody Garnett wrote:

> Hi Paul, CCing the GeoTools list as that is where datastores happen.
>
> I did try to review the FDO API, as I had heard good things about it. 
> But at the time it was locked away behind click through agreements. I 
> trust our new feature model we are rolling out will be a superset of 
> what they can support. Do we have any contacts in the FDO community?
>
> I possible I would prefer to port their C++ code rather then go for 
> another set of wrappers. HSQL is nice and small but lacks many normal 
> database features, derby was also floated as an option.  Our firends 
> at OpenJUMP also had a discussion of creating an analog of the 
> Geodatabase format.
>
> If I can phrase this another way I would rather use PostGIS as a local 
> datastore, as I don't need C++ wrappers to talk to it. Indeed if we 
> limited the local datastore to being SFSQL happy we would have a 
> better baseline for some of the join work gabriel is working on.
>
> Jody
>
>> One of the things our recent MoF project has highlighted to me is 
>> that as we start adding serious geoprocessing abilities to uDig we 
>> are not going to be able to dodge the need for a local file format to 
>> hold intermediate results.  The MoF project was lucky in that Shape 
>> format was not too constraining, and there was really only no 
>> intermediate file anyways.
>>
>> We have sort of initially drifted towards the idea of using a beefed 
>> up version of the existing hsql datastore, adding some spatial 
>> indexing ability.  I want to put another, better (harder!) option on 
>> the table.
>>
>> How about using Spatial Data Format (SDF)?
>>
>> What is SDF?  It is the "native" format that the new Autodesk 
>> Mapguide Open Source uses.
>> Why would we want to use it?  Let me count the ways:
>> - There is already support for SDF being added to OGR and FME, so 
>> people who create SDF files in uDig can translate them easily to 
>> other formats using tools other than uDig.  This will not be true if 
>> we roll our own on hsql.
>> - The whole Autodesk product line has support for SDF, so even 
>> AutoCAD will be able to open uDig files.
>> - The SDF format lives behind an abstraction called FDO (Feature Data 
>> Objects).  If we can read/write from SDF via FDO, we can read/write 
>> from all the other FDO formats too.  Because OGR is getting an SDO 
>> bridge, this also provides us a route into all the OGR formats as 
>> well.  (From an implementation PoV, this also gives us two routes to 
>> choose from: implement an OGR datastore and get to SDF via OGR's FDO 
>> support; implement an FDO datastore and do the reverse.)
>>
>> I think the "network effects" argument for doing SDF (and FDO) is 
>> very compelling.
>>
>> Why not use it?  I guess the problem of doing more C++ wrapping is 
>> part of it.  And ignoring an hsql datastore that is 80% done hurts too.
>>
>> Another option would be to use the new ESRI Geodatabase format, which 
>> does not use Access any more.  That format is not fully baked yet 
>> though, and I do not think it is an open one.  In general though, I 
>> am becoming enthralled with the idea of using, not inventing, a local 
>> format.
>>
>> P
>> _______________________________________________
>> User-friendly Desktop Internet GIS (uDig)
>> http://udig.refractions.net
>> http://lists.refractions.net/mailman/listinfo/udig-devel
>
>
>
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel