[OSGeo-Discuss] idea for an OSGeo project -- a new, open data format

[Landon Blake]

Puneet,

You wrote: "Is this too crazy?"

I don't think this idea is crazy at all. In fact, I think it is a very
good idea. I do have a couple of comments, which you can read below:

You wrote: "What if we came up with a new and improved data format --
call it
"Open Shapefile" (extension .osh)..."

I think we would have to completely avoid the term "Shapefile" as it is
probably an ESRI trademark.

You wrote: " that would be completely Free,
single-file based (instead of the multiple .shp, .dbf, .shx, etc..."

Is there a problem with a multiple file format? I have tinkered with
some different binary file formats, and it seems that separating some
information in a spatial data set (like indexes, for example) makes it
easier to create programs that parse and write the format.

You wrote: " ...and based on SQLite, giving the .osh format complete
relational data
handling capabilities."

I would prefer tightly integrating any software package, even if it was
FOSS, into a new data format. SQLite is written in the C programming
language, as an example, and that doesn't do me a lot of good as a Java
programmer. Tightly integrating a Java library or program wouldn't do
much good for a programmer using C. That is the real beauty of an open
file format: If it is designed properly your programming language
doesn't matter!

I did a little brainstorming for a binary file format that could replace
Shapefiles. Its called BOFF, or Binary Open Feature Format. I talked
over small bits of the design for BOFF with Frank Wammerdam, who
expressed some small interest in it at the time.

Perhaps it would offer some ideas?

I'd be very interesting in offering Java support for a shapefile
replacement endorsed by the OSGeo.

The Sunburned Surveyor

-----Original Message-----
From: discuss-bounces at lists.osgeo.org
[mailto:discuss-bounces at lists.osgeo.org] On Behalf Of P Kishor
Sent: Tuesday, November 13, 2007 6:53 AM
To: OSGeo Discussions
Subject: [OSGeo-Discuss] idea for an OSGeo project -- a new, open data
format

So, I am thinking, Shapefile is the de facto data standard for GIS
data. That it is open (albeit not Free) along with the deep and wide
presence of ESRI's products from the beginning of the epoch, it has
been widely adopted. Existence of shapelib, various language bindings,
and ready use by products such as MapServer has continued to cement
Shapefile as the format to use. All this is in spite of Shapefile's
inherent drawbacks, particularly in the area of attribute data
management.

What if we came up with a new and improved data format -- call it
"Open Shapefile" (extension .osh) -- that would be completely Free,
single-file based (instead of the multiple .shp, .dbf, .shx, etc.),
and based on SQLite, giving the .osh format complete relational data
handling capabilities. We would require a new version of Shapelib,
improved language bindings, make it the default and preferred format
for MapServer, and provide seamless and painless import of regular
shp data into .osh for native rendering. Its adoption would be quick
in the open source community. The non-opensource community would
either not give a rat's behind for it, but it wouldn't affect them...
they would still work with their preferred .shp until they learned
better. By having a completely open and Free single-file based, built
on SQLite, fully relational dbms capable spatial data format, it would
be positioned for continued improvement and development.

Is this too crazy?

-- 
Puneet Kishor
_______________________________________________
Discuss mailing list
Discuss at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss


Warning:
Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately.