Jesse, At the moment we have no plans to create a DXF based provider, although it is an interesting idea.
Bob -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jesse Eichar Sent: Wednesday, March 08, 2006 5:14 PM To: User-friendly Desktop Internet GIS Cc: GeoTools Devel List Subject: Re: [udig-devel] Local File Format Hi, I see that FDO will support shapefile and SDO. Do you know if FDO will support DXF format in the near future? Cheers, Jesse 8-Mar-06, at 2:15 PM, Robert Bray wrote: > 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 > > -----Original Message----- > From: Paul Ramsey [mailto:[EMAIL PROTECTED] > 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 >> 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 _______________________________________________ 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
