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

[John Herring]

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