Re: CRS specification (was: Re: ISA Core Location Vocabulary)

Hello Clemens, All,

First I would like to wish everyone a healthy and fruitful new year!

Secondly, thanks to Clemens for stating his doubts about a separate CRS 
property. All change proposals should be well thought over.

In a previous message I tried to explain what I think are good reasons 
to keep it separate. Of course, whether the CRS is an intrinsic part of 
a geometry all depends the exact definition of what a geometry is. I 
don't know where the official OGC specification can be found, but if 
someone can provide a pointer that would be nice. The definition in the 
LOCN vocabulary seems to be quite open.

I think a reasonable definition would be that a geometry defines a shape 
of a geographic object by means of a series of coordinates. A single 
geographic object can have multiple geometries, each a different 
approximation of the true shape of the geographic object. The series of 
coordinates naturally depends on the CRS. But if you look more closely, 
there is a lot more that can be stated about the geometry. For example, 
and I think that is an important one too, there is the level of detail 
(LOD), which could perhaps be defined as a resolution in meters. And 
there are other things too. Let's have an example in turtle:

ex1:myGeometry
     a ex2:geometry ;
     ex2:asWKT "POLYGON((97372 487152,97372 580407,149636 580407,149636 
487152,97372 487152))"^^ex2:wktLiteral ;
     ex2:CRS <http://www.opengis.net/def/crs/EPSG/0/28992> ;
     ex2:CRS <http://www.other.org/srs/12345> ;
     ex2:levelOfDetail "10.5"^^xsd:decimal ;
     ex2:horizontalAccuracy "1.2"^^xsd:decimal ;
     ex2:verticalAccuracy "0.8"^^xsd:decimal ;
  .

I have added some data that helps to put the string of coordinates in 
perspective. Maybe others would like to add still more, like the 
generalisation method used, if any. Or whether the geometry was measured 
in the field or computed. Now imagine us having to put all these data in 
a single literal, and make sense of it...

By the way, looking at this example I am getting the notion that keeping 
the specification of the geometry type ("POLYGON" in this case) separate 
too might be a good idea :-)

Regards,
Frans


On 2013-12-30 3:55, Clemens Portele wrote:
> Hi Andrea,
>
> I would propose to support only http URIs. The use of literals like 
> EPSG:4326 or URNs like urn:ogc:def:EPSG::4326 has been deprecated by 
> OGC. There is no need to support legacy in the core location 
> vocabulary. (As an aside, the notation EPSG:nnnnn was also meant to be 
> a URI - after registering the URI scheme "EPSG" with IANA, which never 
> happened.)
>
> In addition, and that is my main concern, I am not sure I understand 
> the proposed property. The CRS information is intrinsic to the 
> geometry representation, which is kept open in LOCN, so how exactly 
> would this property be defined or be useful? Of course, every geometry 
> representation should be explicit about its CRS - or specify the 
> standard CRS, if no CRS is or can be specified explicitly in the 
> geometry representation. This is already the case in most of the 
> sample encodings mentioned at http://www.w3.org/ns/locn#locn:geometry, 
> e.g.:
>
> - WKT (GeoSPARQL): CRS info optional, a URI, default is 
> http://www.opengis.net/def/crs/OGC/1.3/CRS84
> - GML: CRS info mandatory, a URI
> - RDF+WKT (GeoSPARQL): CRS info optional, a URI, default is 
> http://www.opengis.net/def/crs/OGC/1.3/CRS84
> - RDF+GML (GeoSPARQL): CRS info mandatory, a URI
> - KML: fixed to 2D or 3D geodetic WGS84 with long/lat(/alt) axis 
> order, decimal degrees for lat and long, metres for alt
> - geo URI: optional, but discouraged (values not specified), default 
> is 2D or 3D geodetic WGS84 with lat/long(/alt) axis order, decimal 
> degrees for lat and long, metres for alt
>
> So each of these geometry representations already includes the 
> information about the CRS. It is not clear to me what the value of an 
> additional, potentially conflicting CRS property would be.
>
> In addition, the CRS is strictly not a property of a geometry, but of 
> a particular representation / serialisation.
>
> In the GeoSPARQL Standards Working Group in OGC we had also discussed 
> having a CRS property. Actually earlier drafts had a separate geo:srid 
> property, but this has been removed in the final version for exactly 
> these reasons (plus this approach results in simpler SPARQL queries).
>
> Best regards,
> Clemens
>
>
> On 30 Dec 2013, at 00:13, Andrea Perego 
> <andrea.perego@jrc.ec.europa..eu 
> <mailto:andrea.perego@jrc.ec.europa.eu>> wrote:
>
>> Dears,
>>
>> Based on the discussion on the original thread (see mails [1-5]), I 
>> would kindly ask your feedback on the following proposal:
>>
>>
>> *Proposed resolution*
>>
>> Add to the LOCN voc an optional property to specify the CRS of a 
>> geometry. The range of such property can be either a literal (e.g., 
>> EPSG:4326), a URN (e.g., urn:ogc:def:EPSG::4326) or an HTTP URI 
>> reference (e.g., http://www.opengis.net/def/crs/EPSG/0/4326).
>>
>>
>> Intentionally, I've not included the following two points, since the 
>> position of the group is still unclear on them:
>>
>> 1. Should the use of HTTP URIs be recommended? BTW, on this, 
>> Krzysztof posted a question that has not been yet answered [1].
>>
>> 2. Should we recommend a specific CRS URI register?
>>
>> I kindly ask you to use this thread to post any relevant comments.
>>
>> Thanks!
>>
>> Andrea
>>
>> ----
>> [1]http://lists.w3.org/Archives/Public/public-locadd/2013Dec/0022.html
>> [2]http://lists.w3.org/Archives/Public/public-locadd/2013Dec/0027.html
>> [3]http://lists.w3.org/Archives/Public/public-locadd/2013Dec/0028.html
>> [4]http://lists.w3.org/Archives/Public/public-locadd/2013Dec/0029.html
>> [5]http://lists.w3.org/Archives/Public/public-locadd/2013Dec/0030.html
>>
>>
>>
>> On Sun, Dec 22, 2013 at 11:13 PM, Raphaël Troncy 
>> <raphael.troncy@eurecom.fr <mailto:raphael.troncy@eurecom.fr>> wrote:
>>
>>         @Raphaël, could you please provide some more details about
>>         the CRS
>>         conversion service you are about to publish?
>>
>>
>>     This is a REST service that implements a number of algorithms for
>>     doing projections between CRS, similar to what the Circé software
>>     is doing, but implemented as a web-based service, see
>>     http://fr.wikipedia.org/wiki/Circ%C3%A9_%28logiciel%29
>>     (unfortunately, only in French).
>>     More details in Jan/Feb when we actually publish the service.
>>     Best regards.
>>
>>
>>       Raphaël
>>
>>     -- 
>>     Raphaël Troncy
>>     EURECOM, Campus SophiaTech
>>     Multimedia Communications Department
>>     450 route des Chappes, 06410 Biot, France.
>>     e-mail: raphael.troncy@eurecom.fr
>>     <mailto:raphael.troncy@eurecom.fr> & raphael.troncy@gmail.com
>>     <mailto:raphael.troncy@gmail.com>
>>     Tel: +33 (0)4 - 9300 8242 <tel:%2B33%20%280%294%20-%209300%208242>
>>     Fax: +33 (0)4 - 9000 8200 <tel:%2B33%20%280%294%20-%209000%208200>
>>     Web: http://www.eurecom.fr/~troncy/
>>     <http://www.eurecom.fr/%7Etroncy/>
>>
>>
>>
>>
>> -- 
>> Andrea Perego, Ph.D.
>> European Commission DG JRC
>> Institute for Environment & Sustainability
>> Unit H06 - Digital Earth & Reference Data
>> Via E. Fermi, 2749 - TP 262
>> 21027 Ispra VA, Italy
>>
>> DE+RD Unit: http://ies.jrc.ec.europa.eu/DE
>>
>> ----
>> The views expressed are purely those of the writer and may
>> not in any circumstances be regarded as stating an official
>> position of the European Commission.
>


-- 
--------------------------------------
*Geodan*
President Kennedylaan 1
1079 MB Amsterdam (NL)

T +31 (0)20 - 5711 347
E frans.knibbe@geodan.nl
www.geodan.nl <http://www.geodan.nl> | disclaimer 
<http://www.geodan.nl/disclaimer>
--------------------------------------