Local File Format (was on udig list)

[jgarnett at refractions.net]

Well Paul that is starting to make a great deal more sense. I would love to
build a bridge to the C++ community, are they actually lining up behnid this one?

And I can't imagine them pushing this without BBox support. Now for laughs and
giggles check out this slashgeo poll on the topic:
- http://slashgeo.org/pollBooth.pl?qid=13&aid=-1

I liked the entry where OSGeo saves the day, seems a bit more likly then OGC.
Jody

> 
> 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
> > 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?
> 
> Sure, Bob Bray at Autodesk is a friendly soul and can provide
> pointers.  They may already have some Java wrappers on FDO, for all
> we know.
> 
> > 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.
> 
> Yeah, exactly, there is a cacophony of talk about other on-disk
> formats for our Java GIS community, and it is really dumb!  If we
> create another format, we create another walled garden for users to
> try and break out of.  If we start with a format that already has (a)
> translator support and (b) application support, we add value to
> everybody, rather than just to ourselves.  I also respectfully
> disagree on porting, since wrapping the FDO API gives us access to
> anything that someone happens to add to FDO in the future, while
> 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
> > 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.
> 
> PostGIS cannot be a local data-store, since using it involves
> installing a whole RDBMS.  SDF is on top of SQLLite (which, like BDB,
> can run inside the application process), so there is a SQL engine
> inside there.
> 
> Paul
> 
> >
> > 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
>