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

Wed Mar 28 10:02:05 PDT 2007

Bernard;

    About SRS: ISO 19107 (which is the OGC abstract specification for
geometry)  is very clear that the SRS of a geometry can be a property of the
geometry or a property of a container for that geometry. That means if a
feature (geometry collection, feature collection or anything that act like a
container) has a SRS property (either set by the schema as a static, or as a
variable - non-static - attribute) then any contained geometric objects
without an overriding SRS property inherits by containment the SRS of it
most immediate parent container with an SRS property. By forcing SRS down
into geometry without exception, you are designing against the worse case,
and sacrifice flexibility to simplify and compress the data by floating up
common properties to larger containers. Nothing is lost in using the ISO
19107 options, since any geometry or any container for geometry can override
the "inherited" SRS.  A lot is lost by mimicking GML, which as far as I know
is the only standard using a profile of ISO 19107 forcing this option the
way you suggest. (Actually in a sense, GML may not be ISO 19107 compliant
for this reason; but there is enough flexibility in the way UML uses
interfaces that GML is probably covered by that flexibility.)

    About the model: Simple features is defined by the Simple Feature
specification, not by a profile of GML. Beside, we went through this in the
RWG for the profiles, and whatever you are thinking about is no longer
called "GML for Simple Features" unless it really does all of Simple
Features 1.1. (GML has yet to be profiled for the new Simple Features
specification, but that does not change the feature model, only adds some
geometry and other property types).

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

  _____  

From: Bernard Snyers [mailto:bs at ionicsoft.com] 
Sent: Wednesday, March 28, 2007 12:02 PM
To: John Herring
Cc: 'Martin Daly'; geojson at lists.geojson.org
Subject: Re: [GeoJSON] To GML, or not to GML, that is the question

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/fca4ab79/attachment.htm>