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

Hi all,
We had a similar discussion on what is the best way to incorporate
information about the
CRS that is tied with a geometric object when we designed stSPARQL [1] and
we ended
up taking the same decision with the GeoSPARQL WG!

A CRS and a geometry serialization are not two separate things. On the
contrary, the
interpretation of the coordinates of a geometry serialization depends on
the coordinate reference
system that is associated with the geometry serialization. A sequence of
coordinates does
not have any meaning, when not associated with a CRS. For this reason,
recent standards
like GML and GeoSPARQL force the association of a geometric object with a
CRS while
other standards like KML have this information hard-coded (as Clemens also
pointed out!).

(We could have a similar discussion regarding decimal numbers. Should we
represent a decimal
number using a single literal and use two functions to access each part of
the number that is
before and after the decimal mark, or should we use two separate literals?)

For this reason, in GeoSPARQL (similarly to OGC-SFA and SQL MM) you can
find out the
CRS that has been used for encoding the serialization of a geometric object
using the
function geof:getsrid.

If you want to use multiple serializations of a geometry by using various
CRS, you can use
multiple triples. Now, the problem of having multiple CRS is that
tranformations between
compatible CRS always introduces some error. I agree with the approach of
GeoSPARQL,
that essentially adopts that fact that geometries may be implicitly
transformed to a different
CRS at query time. For example, when defining topological functions like

geof:sfOverlaps(geom1: ogc:geomLiteral,geom2: ogc:geomLiteral): xsd:boolean

the standard says "Each function returns an xsd:boolean value of true if
the specified relation
exists between geom1 and geom2 and returns false otherwise. In each case,
the spatial
reference system of geom1 is used for spatial calculations". My opinion is
that this design choice
makes things much easier for a user that do not care about CRS involved in
answering her query
and just want an (possibly imperfect) answer over the complete information
stored in a graph.
This is not restrictive however, since a user that do care about which CRS
are being used when
answering a query, she can add one or more filter expressions to specify
exactly which CRS
should be considered.

What is currently missing from GeoSPARQL regarding CRS (but can be easily
added to a next
version), is a function like the function TRANSFORM defined in SQL-MM 3
(which we also
implemented as the function strdf:transform(geom: ogc:geomLiteral,
targetCRS: anyURI) in our
system Strabon [2]) that can be used at the SELECT part of a SPARQL query
to return to the
user the geometry serialized according to a specific CRS.


Best regards (and a happy new year!),
Kostis

[1] http://www.strabon.di.uoa.gr/stSPARQL
[2] http://www.strabon.di.uoa.gr

===================================================
Kostis E. Kyzirakos, PhD
Centrum voor Wiskunde en Informatica
DB Architectures (DA)
Office L320
Science Park 123
1098 XG Amsterdam  (NL)
tel: +31 (20) 592-4039
mobile: +31 (0) 6422-95345
e-mail:  kostis@cwi.nl
===================================================


On Thu, Jan 2, 2014 at 10:23 AM, Frans Knibbe | Geodan <
frans.knibbe@geodan.nl> wrote:

>  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><http://www.opengis.net/def/crs/EPSG/0/28992>;
>     ex2:CRS <http://www.other.org/srs/12345><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<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> 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 & raphael.troncy@gmail.com
>> Tel: +33 (0)4 - 9300 8242 <%2B33%20%280%294%20-%209300%208242>
>> Fax: +33 (0)4 - 9000 8200 <%2B33%20%280%294%20-%209000%208200>
>> Web: http://www.eurecom.fr/~troncy/
>>
>>
>
>
>  --
> 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 | disclaimer <http://www.geodan.nl/disclaimer>
> --------------------------------------
>