<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=windows-1256"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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>