FW: [Java-collab] Simple Text Exchange Format

[Miguel Montesinos]

Same problem with replies.

I forward the message.

Miguel
 

>-----Original Message-----
>From: Miguel Montesinos 
>Sent: Wednesday, May 28, 2008 10:17 AM
>To: 'Francisco José Peñarrubia'
>Subject: RE: [Java-collab] Simple Text Exchange Format
>
>Hi Fran,
>
>Good to see you here
>
>Miguel Montesinos
>gvSIG
>
>>-----Original Message-----
>>From: java-collab-bounces at lists.osgeo.org
>>[mailto:java-collab-bounces at lists.osgeo.org] On Behalf Of Francisco 
>>José Peñarrubia
>>Sent: Wednesday, May 28, 2008 9:59 AM
>>To: java-collab at lists.osgeo.org
>>Subject: Re: [Java-collab] Simple Text Exchange Format
>>
>>Hi.
>>
>>About this format, I would recommend some suggestions:
>>1.- Take care about encoding.
>>2.- At least, set a default date / time format or specify also in 
>>header.
>>3.- If you include an index file (for example, longs with the 
>position 
>>in file where each record starts, it may allow you to spatially index 
>>the file, random access and edit each record without rewriting the 
>>whole file. Even to set a order (to put a feature below other, for 
>>example).
>>
>>About metadata, I think it will be better an already existent format, 
>>but I'm not sure. And maybe a good idea would be to allow 
>distribution 
>>of those files in .zip file.
>>
>>
>>Thanks for your formats, Paul and Landon. Good to see people 
>with this 
>>kind of interests here.
>>
>>PS: Anyone has compared SQLite and H2?. (Spatial)
>
>PS: Has anyone thought about db4objects[1], which is an 
>open-source object-oriented DB with Java native engine? There 
>is an interesting comparison of Java DB-engines [2], but I'm 
>not sure how up to date it is.
>
>[1] http://www.db4o.com/
>[2] http://www.polepos.org/
>>
>>Fran.
>>gvSIG team.
>>
>>Paul Austin escribió:
>>> All,
>>>
>>> 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 
>own binary 
>>> format we'll need to deal with all the issues such as storage 
>>> management and indexing that databases already do for us.
>>>
>>> I do however think that we need a simple format for exchange
>>of data. 
>>> 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
>>include an
>>> embedded schema.
>>>
>>> I have been working on a CSV derivative which I'm calling 
>>> Enhanced-CSV. Basically it's a CSV file where the format is strict 
>>> about placement 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 will follow. The next header is the attribute header
>>(schema).
>>> There can be multiple attribute headers including the name,type, 
>>> length, precision, 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
>>>
>>> Below is a sample of a ECSV file with the three sections.
>>>
>>> {http://ns.ecsv.org/ecsv}typeName,QName,{GFT}GFT_CAPTURE_METHOD_CODE
>>> {http://ns.ecsv.org/ecsv}srid,QName,{http://epsg.org}3005
>>> 
>>{http://ns.ecsv.org/ecsv}attributeHeaderTypes,list,"{http://ns.
>ecsv.org/ecsv}attributeName,{http://ns.ecsv.org/ecsv}>attribute
Type,{http://ns.ecsv.org/ecsv}attributeLength,{http://
>ns.ecsv.org/ecsv}attributeScale,{http://ns.ecsv.org/ecsv}>attri
buteRequired" 
>>>
>>>
>>> CAPTURE_METHOD_CODE_ID,CODE_VALUE,WHO_CREATED,WHEN_CREATED
>>> integer,string,string,dateTime
>>> 3,255,255,2147483647
>>> 0,0,0,0
>>> false,false,false,false
>>>
>>> 1,Photogrammetric,PROXY_GFT,2008-05-26T00:00:00
>>> 2,Differential Gps,PROXY_GFT,2008-05-26T00:00:00 3,Tablet 
>>> Digitizing,PROXY_GFT,2008-05-26T00:00:00
>>>
>>>
>>> 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
>>reader and
>>> 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?
>>>
>>> Paul
>>> _______________________________________________
>>> Java-collab mailing list
>>> Java-collab at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/java-collab
>>
>>_______________________________________________
>>Java-collab mailing list
>>Java-collab at lists.osgeo.org
>>http://lists.osgeo.org/mailman/listinfo/java-collab
>>