Frank,
I think we can work together towards a solution that will work for the both
of us. I'll revisit the specification I posted earlier and make some changes
that it supports multiple features. I will also sketch up a format for a
binary index.
For my needs in OpenJUMP I can just use the same specification, only my
files will only contain a single feature.
You wrote: "I'm essentially interested in
a replacement format for Shapefiles with none of their limitations for field
types and with a geometry that is directly the simple features geometry
model
instead of a relatively close analog."
This is basically my goal as well. However, I'd like to keep the feature
geometries in a separate file so that we can "swap" geometry models if
necessary. We can make the default geometry format OGC WKB, and I'll write
the Java parser/writer to work using that format for feature geometries. The
features will store only an identifier for there respective geometries. This
will allow different geometry models to be supported.
I'm thinking a "binary open feature format" will have 4 separate binary
files.
[1] The .fea file will contain the feautures/feature attributes.
[2] The .find or .fin will contain the index for the features in the .fea
file.
[3] The .geom or .geo file will contain the featue geometries.
[4] The .gind or .gin will contain the index for the features geometries
stored in the .geom file.
Would it be too much to add a fifth file for some simple metadata?
You wrote: " I'm essentially interested in
a replacement format for Shapefiles with none of their limitations for field
types..."
Would there be a way to allow addition of custom data types for attributes?
I'm not sure exactlty how this would work. We could have a text file where
developers could match an ID stored as the attribute type with the
specification for the format.
If we did this I could make the parser pluggable so feature attributes with
a custom data type could be parsed without the need for recompilation of the
parser.
But perhaps this is too complex and we should stick with something simple
for now.
Let me know what you think.
Landon
On 4/2/07, Frank Warmerdam <[EMAIL PROTECTED]> wrote:
Sunburned Surveyor wrote:
> This message is directed mostly at Frank, but I included the JPP mailing
> list in case other JPP Developers want to comment.
>
> I've been thinking some more about a binary format for the exchange of
> features, and I have been taking a look at the API for Java's
> DataInputStream class and DataOutputStream class. They contain methods
> that can read and write primitive Java datatypes. They can even read and
> write String objects as seqences of Unicode character values with a
> character count. At first glance it looked like this was everything we
> needed to create a parser and writer for a binary feature exchance
format.
>
> However, I'm concerned about how interoperability with other programming
> languages of a binary file written with these Java classes. For example,
> if you create a file with a computer that has a 64-bit microprocessor
> does the writeInt() method write an integer to the file using 4 bytes or
> 8 bytes? (The API documentation says it only uses 4 bytes.) I also think
> we would want to stay away from the writeUTF() and readUTF() methods,
> since it sounds like they write a funky character encoding that other
> programming languages might have trouble with. I think we'll want to
> write our own character counter byte and the individual unicode
> character values with writeChar() or writeChars() method instead.
>
> Do you guys have any comments on this?
Landon,
UTF-8 is fine with other languages, and is essentially ASCII when no
unusual
characters are used. For binary types it is important to be very precise
about their sizes the the format specification.
You mentioned earlier that you current interest is in the a "single
feature"
format, which is of little interest to me. I'm essentially interested in
a replacement format for Shapefiles with none of their limitations for
field
types and with a geometry that is directly the simple features geometry
model
instead of a relatively close analog.
It is also important to me that it be indexable, though I'm happy to
handle the
indexes as separate files that are specified later.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam,
[EMAIL PROTECTED]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
