[OSGeo-Standards] Simple Text Format For Transfer of Simple Spatial Features (Killing the GML 3 Beast)

[Jody Garnett]

Do look at the SimpleFeature profile and what ESRI did to make GML3 
"useful". Out of your list [3] is in contradiction with [1]... unless 
you want to use a hack I though of. Make a generic spatial index that 
tracks file offsets, use this to "filter" an input stream of your simple 
format (text?) (jumping around the file as needed) presenting the result 
as a flat stream that can be parsed in a simple manner. It will be 
murder to keep that index udpated.

You also left out one; do you need to edit the file? If so fixed length 
records is a good thing ...  and so on. You can see why most projects 
are taking an embeded database (making a file format is so 70s).

Cheers,
Jody
> We really don't want to pass around databases for various reasons. One
> of my own personal reasons is the added complexity of JDBC. We also want
> to support data transfer between programs written in languages other
> than Java.
>
> We know we want a file format that meets the following requirements:
>
> [1] Simple, Simple, Simple
> [2] Human readable, not binary.
> [3] Ability to be indexed for faster access to features.
> [4] No need for an external schema.
> [5] Easy to write and read (parse).
>
> If there is an existing format that meets these requirements please let
> me know. Jody is correct when he says we want to avoid duplicating a
> file format that already does this.
>
> I have my suspicions about the existence of such a format. I would think
> someone in the OpenJUMP community would have pointed it out by now, but
> I could be wrong.
>
> Maybe the C/C++ folks have an idea.
>
> Landon (A.K.A. - The Sunburned Surveyor)
>
> -----Original Message-----
> From: Jody Garnett [mailto:jgarnett at refractions.net] 
> Sent: Wednesday, August 29, 2007 2:50 PM
> To: Landon Blake
> Cc: standards at lists.osgeo.org
> Subject: Re: [OSGeo-Standards] Simple Text Format For Transfer of Simple
> Spatial Features (Killing the GML 3 Beast)
>
> Yet another format is never a great idea :-) If you really want another 
> format why not punt H2 databases around? It is what the SQLLite file 
> format crazy in the C++ world is all about ... think even FDO does 
> something like that?
>
>   
>> [1] A CSV file in which the first row contains feature attribute 
>> names, the second row identifies feature attribute data types using 
>> standard XML data types and WKT for geometry attributes, and in which 
>> the other rows contain the actual attribute values, one feature per
>>     
> row.
>   
> You are welcome to look at the property file format we use as an example
>
> in GeoTools.
>   
>> [2] A restricted form of GML 2 that will eliminate the need for an 
>> external schema and simplify parsing. Think of this as "GML 2 
>> Resurrected".
>>
>>     
> This is the way to go;
> - you will find that the OGC has a SimpleFeature profile of GML3 that 
> can be put to good use.
> - ESRI also has something insane to the same effect
>
> Not sure you will every eliminate the need for an external schema - but 
> why not put it inline at the top of the document? Consider it a "header"
>
> for the rest of the file ... that is how WSDL and MS does it.
>
> Cheers,
> Jody
>
>
> 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.
>