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

[Robert B. <rob...@au...>]

Paul,

Thanks for sending this my way. I'll pipe in and provide a little
background on SDF. You guys can then decide if it's the right format or
uDig or not.

SDF stands for Spatial Database Format. It supports multiple feature
classes per file with fully typed properties and multiple geometry
properties per feature class. Each geometry property is indexed via an
R-Tree. As for spatial operations, the SDF query engine supports
Intersects, Contains, Within, Disjoint, and Inside.

The format is built on SQLite, but does not use any of the relational
aspects of SQLite, hence you cannot use any of the SQLite client tools
for viewing / querying an SDF file. We are just using the low level
storage components of SQLite.

If you have questions or want more details on any of this just respond
on the udig-devel list, I joined that list today.

Bob=20

-----Original Message-----
From: Paul Ramsey [mailto:pr...@re...]=20
Sent: Sunday, March 05, 2006 9:22 AM
To: User-friendly Desktop Internet GIS
Cc: GeoTools Devel List; Robert Bray
Subject: Re: [udig-devel] Local File Format


On 5-Mar-06, at 5:33 AM, Jody Garnett wrote:

> I did try to review the FDO API, as I had heard good things about =20
> it. But at the time it was locked away behind click through =20
> agreements. I trust our new feature model we are rolling out will =20
> be a superset of what they can support. Do we have any contacts in =20
> the FDO community?

Sure, Bob Bray at Autodesk is a friendly soul and can provide =20
pointers.  They may already have some Java wrappers on FDO, for all =20
we know.

> I possible I would prefer to port their C++ code rather then go for =20
> another set of wrappers. HSQL is nice and small but lacks many =20
> normal database features, derby was also floated as an option.  Our =20
> firends at OpenJUMP also had a discussion of creating an analog of =20
> the Geodatabase format.

Yeah, exactly, there is a cacophony of talk about other on-disk =20
formats for our Java GIS community, and it is really dumb!  If we =20
create another format, we create another walled garden for users to =20
try and break out of.  If we start with a format that already has (a) =20
translator support and (b) application support, we add value to =20
everybody, rather than just to ourselves.  I also respectfully =20
disagree on porting, since wrapping the FDO API gives us access to =20
anything that someone happens to add to FDO in the future, while =20
porting the FDO support for SDF to Java gives us support for just SDF.


> If I can phrase this another way I would rather use PostGIS as a =20
> local datastore, as I don't need C++ wrappers to talk to it. Indeed =20
> if we limited the local datastore to being SFSQL happy we would =20
> have a better baseline for some of the join work gabriel is working =20
> on.

PostGIS cannot be a local data-store, since using it involves =20
installing a whole RDBMS.  SDF is on top of SQLLite (which, like BDB, =20
can run inside the application process), so there is a SQL engine =20
inside there.

Paul

>
> Jody
>
>> One of the things our recent MoF project has highlighted to me is =20
>> that as we start adding serious geoprocessing abilities to uDig we =20
>> are not going to be able to dodge the need for a local file format =20
>> to hold intermediate results.  The MoF project was lucky in that =20
>> Shape format was not too constraining, and there was really only =20
>> no intermediate file anyways.
>>
>> We have sort of initially drifted towards the idea of using a =20
>> beefed up version of the existing hsql datastore, adding some =20
>> spatial indexing ability.  I want to put another, better (harder!) =20
>> option on the table.
>>
>> How about using Spatial Data Format (SDF)?
>>
>> What is SDF?  It is the "native" format that the new Autodesk =20
>> 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 =20
>> people who create SDF files in uDig can translate them easily to =20
>> other formats using tools other than uDig.  This will not be true =20
>> if we roll our own on hsql.
>> - The whole Autodesk product line has support for SDF, so even =20
>> AutoCAD will be able to open uDig files.
>> - The SDF format lives behind an abstraction called FDO (Feature =20
>> Data Objects).  If we can read/write from SDF via FDO, we can read/=20
>> write from all the other FDO formats too.  Because OGR is getting =20
>> an SDO bridge, this also provides us a route into all the OGR =20
>> formats as well.  (From an implementation PoV, this also gives us =20
>> two routes to choose from: implement an OGR datastore and get to =20
>> SDF via OGR's FDO support; implement an FDO datastore and do the =20
>> reverse.)
>>
>> I think the "network effects" argument for doing SDF (and FDO) is =20
>> very compelling.
>>
>> Why not use it?  I guess the problem of doing more C++ wrapping is =20
>> part of it.  And ignoring an hsql datastore that is 80% done hurts =20
>> too.
>>
>> Another option would be to use the new ESRI Geodatabase format, =20
>> which does not use Access any more.  That format is not fully =20
>> baked yet though, and I do not think it is an open one.  In =20
>> general though, I am becoming enthralled with the idea of using, =20
>> 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