Re: CRS specification

Dear all,

This is a very interesting discussion. Indeed, the CRS information is 
tied with the geometry serialization, you need to have it to understand 
how to interpret the coordinates ... but the fact that those two 
informations are tied does not mean they should be conflated (and 
obfuscated) into the same literal property ... all the contrary IMHO ! 
One can think of a geometry as a complex compound object that requires 
both information: a CRS and a set of coordinates. I believe this should 
be made explicit in the representation. This enables to query for 
geometries represented in a particular CRS as Frans already pointed out.

Let's take again the French example. Because the French departments are 
spread in many parts of the world, the CRS used to represent their 
geometries varies: Lambert93 for France Metropolitan, RGFG95 in Guyanne 
(French Antilles), RGR92 in Réunion (near Madagascar), RGM04 in Mayotte, 
RGSPM06 in St-Pierre-et-Miquelon, etc. If the CRS is buried in the 
literal representation of the geometry, then I need a complex regex 
pattern query to filter out some geometries. A specific property would 
definitively triggers simpler SPARQL queries.

Kostis argues that the CRS information could be computed with a specific 
function (basically, as implemented in stSPARQL). I'm on the side that 
then, it should also be possible to make it explicit.

Finally, as Clemens pointed out, each geometry encoding has a default 
CRS but one can change it, i.e. specifies a different URI. How one is 
supposed to do this without a specific property?
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/

Received on Friday, 3 January 2014 10:12:47 UTC