FW: [Java-collab] Simple Text Exchange Format
mmontesinos at prodevelop.es
Wed May 28 05:21:50 EDT 2008
I replied to, but the list is not set-up for relaying replies to the list. Is it possible to fix this? Thanks
I forward the message.
>From: Miguel Montesinos
>Sent: Wednesday, May 28, 2008 10:09 AM
>To: 'Andreas Schmitz'
>Subject: RE: [Java-collab] Simple Text Exchange Format
>In gvSIG we are finishing support for BXML (Binary XML),
>which (in case you don't know about it) is a kind of binary
>version of GML.
>Bandwith usage is reduced and processing throughput is
>increased several times. It's binary and it's near standards,
>as it an OGC Best Practice. It's also suitable for OGC
>protocols which use GML like WFS.
>The libraries which offer support for BXML are decoupled from
>gvSIG core, so that they can be easily used by other projects.
>If we need readable format, my choose is GML.
>If we want binary format, I propose BXML.
>C/ Conde Salvatierra, 34 - 10
>46004 Valencia. Spain
>e-mail: mmontesinos at prodevelop.es
>Tlf: +34 963510612
>>From: java-collab-bounces at lists.osgeo.org
>>[mailto:java-collab-bounces at lists.osgeo.org] On Behalf Of Andreas
>>Sent: Wednesday, May 28, 2008 9:43 AM
>>To: java-collab at lists.osgeo.org
>>Subject: Re: [Java-collab] Simple Text Exchange Format
>>Paul Austin wrote:
>>> I saw in one of the other posts there was a discussion of binary
>>> format to replace shape files quick random access to data. Someone
>>> suggested using an embedded database such as H2 with a spatial
>>> extension. I think that using a database is a much better way to go
>>> for this kind of access. Otherwise if we come up with our
>>> format we'll need to deal with all the issues such as storage
>>> management and indexing that databases already do for us.
>>I must say that I agree with Landon here (in the other post),
>>like to see a binary format that is more portable through
>>platforms. That said, I'm sure that a way to store data in an
>>database has it's own charm.
>>Storing data in that way would also enable (more or less
>>of the data to a "real" spatial database like PostGIS (and
>>> I do however think that we need a simple format for exchange
>>> Exchanging data may be via files or via a web service. GML
>>in my view
>>> is very verbose and complex to read and write and does not
>>> embedded schema.
>>> I have been working on a CSV derivative which I'm calling
>>> Basically it's a CSV file where the format is strict about
>>> of commas and use of "". It also has two header sections. The first
>>> section is a list of properties about the file, such as type name,
>>> projection, author and a list of which attribute headers
>>> The next header is the attribute header (schema). There can be
>>> multiple attribute headers including the name,type, length,
>>> required flag of the attribute. There is one entry for each data
>>> column (attribute). Finally there is the data section which is just
>>> all your rows of data encoded as CSV. Geometries are encoded as WKT
>>Sounds easy and simple - I like it!
>>> I'm working on a specification for this format and hopefully should
>>> have a draft up in the next month or so. I have developed a
>>> writer and a JUMP plug-in which I'll make available when I've
>>> finalized the specification.
>>> Is this something that would interest any one else?
>>Definitely. Will the reader/writer be OpenSource? Which license?
>>Best regards, Andreas
>>l a t / l o n GmbH
>>Aennchenstrasse 19 53177 Bonn, Germany
>>phone ++49 +228 18496-12 fax ++49 +228 1849629
>>On June 17 is deegree day - Am 17. Juni ist deegree day
More information about the Java-collab