<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content=text/html;charset=windows-1256>
<META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV dir=ltr align=left><SPAN class=046574216-28032007><FONT 
face="Times New Roman" size=4>Bernard;</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=046574216-28032007><FONT 
face="Times New Roman" size=4></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=046574216-28032007><FONT 
face="Times New Roman" size=4>    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.)</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=046574216-28032007><FONT 
face="Times New Roman" size=4></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=046574216-28032007><FONT 
face="Times New Roman" size=4>    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).</FONT></SPAN></DIV>
<DIV><FONT face="Times New Roman" size=4></FONT> </DIV>
<P align=left><FONT size=4><FONT 
face="Times New Roman">Regards,<BR>John<BR></FONT><BR></FONT><FONT size=3>You do 
what you can when you can because you can.<BR><BR>The opinions expressed in this 
email are <BR>purely my own and do not necessarily <BR>represent the opinions of 
any organization<BR>or otherwise sane person or persons.<BR><BR>John R. 
Herring<BR>Architect, Spatial Products<BR>Oracle Corporation<BR>One Oracle 
Drive<BR>Nashua, New Hampshire 03062<BR>ph: 1 603 897 3216<BR>fx: 1 603 897 
3334<BR><BR>Annue cœptis - Novus Ordo Seclorum<BR></FONT><FONT size=4>  
</FONT></P>
<DIV> </DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Bernard Snyers [mailto:bs@ionicsoft.com] 
<BR><B>Sent:</B> Wednesday, March 28, 2007 12:02 PM<BR><B>To:</B> John 
Herring<BR><B>Cc:</B> 'Martin Daly'; 
geojson@lists.geojson.org<BR><B>Subject:</B> Re: [GeoJSON] To GML, or not to 
GML, that is the question<BR></FONT><BR></DIV>
<DIV></DIV>John,<BR><BR>Some clarifications<BR><BR>About srs:<BR>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.<BR><BR>About the 
model:<BR>I simply do not want a model where properties cannot be  a 
feature or a feature collection.  (like  the  simple profile for 
GML)<BR><BR>Hope this help<BR><BR>Bernard<BR> <BR><BR>John Herring wrote: 
<BLOCKQUOTE cite=mid:001501c77138$8a05c650$c7fa950a@us.oracle.com type="cite"><PRE wrap="">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: <A class=moz-txt-link-abbreviated href="mailto:geojson-bounces@lists.geojson.org">geojson-bounces@lists.geojson.org</A>
[<A class=moz-txt-link-freetext href="mailto:geojson-bounces@lists.geojson.org">mailto:geojson-bounces@lists.geojson.org</A>] On Behalf Of Bernard Snyers
Sent: Wednesday, March 28, 2007 8:31 AM
To: Martin Daly
Cc: <A class=moz-txt-link-abbreviated href="mailto:geojson@lists.geojson.org">geojson@lists.geojson.org</A>
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:
  </PRE>
  <BLOCKQUOTE type="cite"><PRE wrap="">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
<A class=moz-txt-link-abbreviated href="mailto:geojson@lists.geojson.org">geojson@lists.geojson.org</A>
<A class=moz-txt-link-freetext href="http://lists.geojson.org/listinfo.cgi/geojson-geojson.org">http://lists.geojson.org/listinfo.cgi/geojson-geojson.org</A>
  
    </PRE></BLOCKQUOTE><PRE wrap=""><!---->_______________________________________________
geojson mailing list
<A class=moz-txt-link-abbreviated href="mailto:geojson@lists.geojson.org">geojson@lists.geojson.org</A>
<A class=moz-txt-link-freetext href="http://lists.geojson.org/listinfo.cgi/geojson-geojson.org">http://lists.geojson.org/listinfo.cgi/geojson-geojson.org</A>

  </PRE></BLOCKQUOTE></BODY></HTML>