[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [udig-devel] Local File Format
|
Carl,
"Limited" as in "none" or "limited" as in "bbox only"? Because the
latter is perfectly acceptable (and all we are likely to get with any
local format).
P.
On 5-Mar-06, at 7:15 AM, Carl Anderson wrote:
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
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel