[GeoJSON] To GML, or not to GML, that is the question

[Bernard Snyers]

John,

Some clarifications

About srs:
I agree that usually all features of a feature collection are expressed 
in the same SRS. But this the geometry property who carries the  srs 
information not another property of the feature. That allows (and it is 
case in gml) to have several geometry properties expressed in different 
SRSes and to have a feature collection which is not homogeneous  in 
respect of srs.

About the model:
I simply do not want a model where properties cannot be  a feature or a 
feature collection.  (like  the  simple profile for GML)

Hope this help

Bernard
 

John Herring wrote:
> Bernard, 
>
> You said »  The simple feature model is not enough, our customers need
> feature, feature collection properties
>
> Actually, the feature model in Simple Features has all this - it has a full
> blown ISO 19109 feature model. It is the geometry restrictions that put the
> simple in simple features. 
>
> You said » the geometry property should be self encoding, do not mention the
> srs property elsewhere.
>
> What exactly does this get you? SRS's are usually assigned by data
> collection, or at least by feature-attribute  (as part of the feature
> schema) not by individual values. Not using this in GML is based on a
> (rather silly) assumption that you have to be able to take attribute values
> out of context and still maintain all semantics. But semantics is context
> (that is why object classes have static attributes), and while this is a
> valid XML processing restriction because XML is structure not semantics, it
> makes no sense in any larger arena, especially anything with an object
> flavor. What is your requirement that this view of schemata misses? 
>
> BTW, standalone documents are nice to be able to do, but so are external
> application schemata. 
>
> Regards,
> John
>
> You do what you can when you can because you can.
>
> The opinions expressed in this email are 
> purely my own and do not necessarily 
> represent the opinions of any organization
> or otherwise sane person or persons.
>
> John R. Herring
> Architect, Spatial Products
> Oracle Corporation
> One Oracle Drive
> Nashua, New Hampshire 03062
> ph: 1 603 897 3216
> fx: 1 603 897 3334
>
> Annue cœptis - Novus Ordo Seclorum
>   
>
>
> -----Original Message-----
> From: geojson-bounces at lists.geojson.org
> [mailto:geojson-bounces at lists.geojson.org] On Behalf Of Bernard Snyers
> Sent: Wednesday, March 28, 2007 8:31 AM
> To: Martin Daly
> Cc: geojson at lists.geojson.org
> Subject: Re: [GeoJSON] To GML, or not to GML, that is the question
>
> In my understanding which is heavily influenced by the real needs of our
> customers is that we should have a reasonable feature model. That's what I
> tried to propose in my previous document.
> The simple feature model is not enough, our customers need feature, feature
> collection properties and they use it now (that's why we have developed this
> encoding) ..
> A geometry model has also been propose based on the OGC WKT specification.
> We could restrict the allowed types of geometry but in any case the geometry
> property should be self encoding, do not mention the srs property elsewhere.
>
> Note: in case of you didn't notice the proposed encoding can produce
> completely standalone documents (featurecollection + types definitions)
> which can be transmitted to a processing chain without references to any
> servers. This is not the case in GML where a GML document always carries
> references through schemalocation attribute
>
>
>
> Martin Daly wrote:
>   
>> We've had some skirting round this issue, but I think that before we 
>> get too much further (with GeoJSON Features at least) we need to have 
>> a consensus on what we are trying to achieve.
>>
>> The options that I see are:
>>
>> 1. Encode GML in JSON, with a reasonably faithful translation between 
>> XML and JSON.
>>
>> or
>>
>> 2. Encode OGC Simple Features in JSON, learning from, but not 
>> translating, GML.
>>
>> I'm in favour of 2.
>>
>> Any other opinions, or options?
>>
>> M
>> _______________________________________________
>> geojson mailing list
>> geojson at lists.geojson.org
>> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
>>   
>>     
> _______________________________________________
> geojson mailing list
> geojson at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20070328/accb4600/attachment.htm>