[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [udig-devel] Local File Format
|
Jesse,
At the moment we have no plans to create a DXF based provider, although
it is an interesting idea.
Bob
-----Original Message-----
From: udig-devel-bounces@xxxxxxxxxxxxxxxxxxxxx
[mailto:udig-devel-bounces@xxxxxxxxxxxxxxxxxxxxx] 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:pramsey@xxxxxxxxxxxxxxx]
> 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
