[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] Local File Format
|
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
