[udig-devel] Fwd: [Freegis-list] Binary Format For Features

["Sunburned Surveyor" <sunburned.surveyor@xxxxxxxxx>]

---------- Forwarded message ----------
From: Sunburned Surveyor <sunburned.surveyor@xxxxxxxxx>
Date: Mar 30, 2007 9:15 AM
Subject: Re: [Freegis-list] Binary Format For Features
To: Frank Warmerdam <warmerdam@xxxxxxxxx>

Frank,

 

Thank you for your comments. I am going to forward your e-mail to the JPP Developer and GeoTools lists. Please see my comments below.

 

You wrote: "For instance, the header appears to be a feature header, rather than file
header, is that right?  Shouldn't there be some sort of file level header
or is it intended that a file is just a collection of features appended?"

 

I should have explained this better. For my immediate purposes I only need to store a single feature in a binary file. (This has to do with a system I'm trying to design for OpenJUMP that will allows us to access features stored in permanent memory instead of in RAM.) However, I realize an important and practical use of this format would be storage of multiple features in a single binary file. I would be more than willing to expand the format specification to include this. In fact, I think it might be a good idea to specify a way to do both. Specify a single feature in a binary file, and multiple features in a single file. (Or perhaps you would use the same format, and would only store a single feature in a file when needed???)
 

You wrote: "I'd like some options for efficient access.  The most obvious thing needed
for this is an index to the features relating feature id with offset in
the file.  This also gives the opportunity to add a spatial index, perhaps
as a seperate file, at some point in the future."

 

I agree. This is something that would be important for storage of multiple features in a single file format and should be included. I left it out because I was only thinking of storing a single feature initially.

 

You wrote: "This also gives the opportunity to add a spatial index, perhaps
as a seperate file, at some point in the future."

 

This would also be a good idea if we are storing multiple features in a single file. An index for attribute values coulb be stored in the same way. These could be future additions to the format as you suggest. I do, however, think there is wisdom in storing the feature geomtries separately. I'll be using JTS in WKB format, but there may be other types of geometry definitions that people would like to use. If we can keep the storage of feature geometries segragrated I think the format will be more flexible.

 

You wrote: "Is there a good place to discuss this?"

 

I think we can have the discussion on the JPP Developer Mailing List for the time being. You can subscribe here:

 

https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

 

I'm open to other forums for discussion if you have a suggestion.

 

You wrote: "I think it would be great if a Java implementation of this could be done
in a way that would easily drop into Geotools without license conflicts.
I think Geotools is LGPL, is that right?"

 

I'm open to negotiation on the license for the parser. I don't think I'd have a problem with the LGPL, but I'd need to get a little more familiar with its terms.

 

Landon (A.K.A. - The Sunburned Surveyor)

 

 

 

 

On 3/30/07, Frank Warmerdam <warmerdam@xxxxxxxxx > wrote:

Sunburned Surveyor wrote:
> I'm currently talking with some of the other OpenJUMP developers about a
> simple binary format that we can use to store Features in a way that
> complements the storage of geometries in the OpenGIS
> Well-Known-Binary WKB format. I thought this might be of interest to
> other open source GIS projects, so I am sending a brief message here.
> I'd be willing to work with developers from other projects on a format
> that could be used by other applications.
>
> I've put a rough draft of the format here:
> http://thejumppilotproject.pbwiki.com/OpenJUMP-Binary-Feature-Format
>
> Let me know if your interested, or if you have any suggestions. I hope
> to finalize the format in the next week or two. In the next month or two
> I hope to have a working parser for the binary format in Java that will
> be released under the GPL through the SurveyOS SourceForge Project.

Landon,

I am interested in this effort.  I think a binary "simple features" file format
with the potential for efficient access is interesting, and valuable, and I
might like to implement support for it in OGR as well.

I reviewed http://thejumppilotproject.pbwiki.com/OpenJUMP-Binary-Feature-Format
and what is there looks good, but it seems incomplete.

For instance, the header appears to be a feature header, rather than file
header, is that right?  Shouldn't there be some sort of file level header
or is it intended that a file is just a collection of features appended?

I'd like some options for efficient access.  The most obvious thing needed
for this is an index to the features relating feature id with offset in
the file.  This also gives the opportunity to add a spatial index, perhaps
as a seperate file, at some point in the future.

Is there a good place to discuss this?

PS. I think it would be great if a Java implementation of this could be done
in a way that would easily drop into Geotools without license conflicts.
I think Geotools is LGPL, is that right?

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@xxxxxxxxx
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org