Re: CRS specification

Hi,
We also had the same problem in Greece, where we were using geospatial data
published using the projected Greek Grid (EPSG:2100), the geographic Greek
Grid (EPSG:4121), WGS84, ETRS89/ETRS-LAEA (EPSG:3035) etc.

Let's say that we have information about Syntagma square in Athens and an
urban area:

ex:SyntagmaSquare geo:hasGeometry ex:SyntagmaSquareGeo .
ex:SyntagmaSquareGeo geo:asWKT "<http://.../EPSG/2100/>
POLYGON(....)"^^sf:wktLiteral .

ex:UrbanArea1 rdf:type ex:UrbanArea .
ex:UrbanArea1 geo:hasGeometry ex:UrbanArea1Geo .
ex:UrbanArea1 geo:asWKT "<http://.../EPSG/3035>
POLYGON((...))"^^sf:wktLiteral .
ex:UrbanArea1 geo:asWKT "<http://.../EPSG/4326>
POLYGON((...))"^^sf:wktLiteral .
ex:UrbanArea1 geo:asWKT "<http://.../EPSG/2100>
POLYGON((...))"^^sf:wktLiteral .

If we want to ask for urban areas that contain Syntagma square we can write
the following GeoSPARQL/stSPARQL query:

SELECT ?ua ?uageo
WHERE {
ex:SyntagmaSquare geo:hasGeometry ?sgeo .
?sgeo geo:asWKT ?sgeometry .

?ua rdf:type ex:UrbanArea .
?ua geo:hasGeometry ?uageo .
?uageo geo:asWKT ?uageometry .

FILTER (geof:sf-contains(?uageometry, ?sgeometry)) .

}

This query, relies to the definition of the geo:sf-contains functions that
states that bindings to ?sgeometry will be converted to the CRS used by a
?uageometry binding. So, the user do not have to worry about conversions
between CRS and automatically they get an answer by taking into account all
geographic information available.

If the user wants to specify exactly which CRS are to be involved, she can
write the following GeoSPARQL/stSPARQL query (actually both GeoSPARQL and
stSPARQL define such a function):

SELECT ?ua ?uageo
WHERE {
ex:SyntagmaSquare geo:hasGeometry ?sgeo .
?sgeo geo:asWKT ?sgeometry .

?ua rdf:type ex:UrbanArea .
?ua geo:hasGeometry ?uageo .
?uageo geo:asWKT ?uageometry .

FILTER (geof:sf-contains(?uageometry, ?sgeometry)) .
FILTER (geof:getSRID(?sgeometry) = <http://.../EPSG/2100>) .
FILTER (geof:getSRID(?uageometry) = <http://.../EPSG/2100>) .
}

If the user wants to get the results in WGS84, she could use the
strdf:transform function that he have introduced (following the SQL-MM
standard) in stSPARQL (I assume that GeoSPARQL will also add this function
in the next version) as follows:


SELECT ?ua (strdf:transform(?uageo, <http://.../EPSG/4326>) AS ?uageo)
WHERE {
ex:SyntagmaSquare geo:hasGeometry ?sgeo .
?sgeo geo:asWKT ?sgeometry .

?ua rdf:type ex:UrbanArea .
?ua geo:hasGeometry ?uageo .
?uageo geo:asWKT ?uageometry .

FILTER (geof:sf-contains(?uageometry, ?sgeometry)) .
}


Now, if you try writing the first query but use an extra triple to identify
a CRS, we would have to write something like this:

SELECT ?ua ?uageo
WHERE {
ex:SyntagmaSquare geo:hasGeometry ?sgeo .
?sgeo geo:asWKT ?sgeometry .
?sgeo sth:useCRS ?sgeometryCRS .

?ua rdf:type ex:UrbanArea .
?ua geo:hasGeometry ?uageo .
?uageo geo:asWKT ?uageometry .
?uageo sth:useCRS ?uageometryCRS .

FILTER (newgeo:sf-contains(?uageometry, ?uageometryCRS, ?sgeometry,
?sgeometryCRS)) .

}

In this case I do not see how one could define precise semantics for
functions like newgeo:sf-contains without incorporating the CRS to the
parameters. I think that this will just be a more complex version of the
GeoSPARQL functions. For this reason, I have a strong opinion on that the
CRS has to be embeded to the spatial literal. Otherwise we will have to
define a new query language as well :)

Whether it is worth having an *extra* triple with the CRS is a different
question. My opinion is that there should not be such a triple, because
this information can be derived (similarly to properties geo:isEmpty,
geo:isSimple). However, in practice some operations can be very expensive
(e.g., length, area, checking for self intersections) and many people opt
for having this information asserted even if this may introduce
errors/inconsistencies at some point. I do not have a strong opinion
against having an extra triple for the CRS, but I feel that it will
introduce inconsistencies at some point in time (e.g., when merging
datasets that use different CRS but share some identifiers).


Best,
Kostis


===================================================
Kostis E. Kyzirakos, Ph.D.
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 Fri, Jan 3, 2014 at 11:12 AM, Raphaël Troncy
<raphael.troncy@eurecom.fr>wrote:

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