Re: CRS specification

Dears,

I'm not sure we have reached an agreement about the issue concerning CRS
specification. However, a number of use cases have been thoroughly
described, highlighting when it is useful to have the CRS in the
serialisation of a geometry and when it is useful to keep it separate.

I wonder whether this can be reflected in the LOCN vocabulary, by
recommending the best ways of expressing a geometry depending on the use
case. So, users will be able to choose the one that most fits their
requirements. We can use the wiki page concerning class locn:Geometry [1]
to work on this.

IMHO, both Frans and Raphaël illustrated strong use cases in favour of the
possibility of specifying the CRS (also) outside the serialisation of a
geometry. The discussed solution was defining a specific property in the
LOCN vocabulary, since there's no suitable candidate in existing
vocabularies. So, I would like to ask the group whether there are still any
objections in defining it, as an "optional" property that can be used in
one of the ways recommended by the LOCN vocabulary to express a geometry.

I may be wrong, but, as far as I can tell, all the objections have been
discussed, with the exception of the one raised by Clemens about the
specification of "potentially conflicting" CRSs [2].

My last point. Frans outlined a use case concerning the use of CRS
specifications in dataset metadata [3]. I think this introduces a possible
new work item for our group, i.e.: is anybody interested in working on
possible geospatial extensions to dataset vocabularies (as DCAT, VoID)? But
it may be worth discussing this in a new thread.

Best,

Andrea

----
[1]http://www.w3.org/community/locadd/wiki/LOCN:_Class_Geometry
[2]http://lists.w3.org/Archives/Public/public-locadd/2014Jan/0000.html
[3]http://lists.w3.org/Archives/Public/public-locadd/2014Jan/0031.html



On Tue, Jan 7, 2014 at 12:30 PM, Raphaël Troncy
<raphael.troncy@eurecom.fr>wrote:

> Dear Kostis,
>
>      True, if you only have the literal, e.g. "POLYGON((97372
>>     487152,97372 580407,149636 580407,149636 487152,97372 487152))", you
>>     can not get the CRS. But is that a problem? If you have the triple
>>     you can get the CRS (provided one is specified).
>>
>> You cannot rely on two triples to interpret a single RDF term. See my
>> comment on the formal definition of a datatype. On the other hand, since
>> we adopt the open world assumption we certainly cannot assume that only
>> a single pair of coordinates and CRS will exist in a knowledge base.
>>
>
> This really comes back to the class vs datatype representation issue that
> has already been pointed out by Frans.
>
> In your view, if I understand well, you want the geometry value to be of a
> (complex) datatype, therefore, putting the CRS information *and* the
> coordinates into a literal that needs to be (correctly) parsed to be used.
> This has some limitations as we already shown in other threads, e.g. 1/ use
> of regular expression for some SPARQL queries, 2/ hard-coded interpretation
> of the value if no CRS is provided, i.e. your software relies on a default
> CRS, but this default is not made explicit in the vocabulary definition,
> etc.
>
> In Frans view (and also mine), a geometry can be a class, that has
> explicit attributes such as a list of coordinates and a CRS. The CRS and
> the set of coordinates are still tied together in the definition of this
> class. Do you see the difference?
>
>  Well, I do not agree with you in this. We will definitely have multiple
>> CRS and there is a good reason for this. Each CRS consider a different
>> approximation of the earth. For example, WGS84 consider the earth to be
>> spheroidal, which is perfect in some cases and absolute disaster for
>> others. It may sound a bit funny at first, but there is also the need in
>> some cases to model extraterrestrial coordinates :)
>>
>
> +1 for this! We definitively need multiple CRS depending on the use case.
> WGS84 is fine for many use cases, but a disaster when you need precision.
>
> 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
> Fax: +33 (0)4 - 9000 8200
> 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.