Re: CRS specification

Hi Andrea,

I agree with the suggestion of adding a specific optional property for
specifying the CRS.

Oscar
 
-- 

Oscar Corcho
Ontology Engineering Group (OEG)
Departamento de Inteligencia Artificial
Facultad de Informática
Campus de Montegancedo s/n
Boadilla del Monte-28660 Madrid, España
Tel. (+34) 91 336 66 05
Fax  (+34) 91 352 48 19

De:  Andrea Perego <andrea.perego@jrc.ec.europa.eu>
Fecha:  lunes, 13 de enero de 2014 08:26
Para:  Raphael Troncy <raphael.troncy@eurecom.fr>
CC:  Kostis Kyzirakos <Kostis.Kyzirakos@cwi.nl>, Frans Knibbe | Geodan
<frans.knibbe@geodan.nl>, LocAdd W3C CG Public Mailing list
<public-locadd@w3.org>
Asunto:  Re: CRS specification
Nuevo envío de:  <public-locadd@w3.org>
Fecha de nuevo envío:  Mon, 13 Jan 2014 07:27:58 +0000

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 <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/
> 



-- 
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.