Re: Good practice for RDF publishing of multiple geometries with different CRSs?

Hello Matt, Raphaël,

Thank you for your answers! It is nice to see that Matt's first solution
aligns with Raphaël's solution. The GeoSPARQL query will work, but I think
it is a less general solution, it depends on a particular API (SPARQL) and
support of a particular function (getSRID) by the SPARQL engine.

It's also nice to see Matt signalling the need for standardization and
Raphaël providing some or all of it next. I do notice a difference in
approach: In Matt's example a set of coordinates using a particular CRS is
a serialization of a geometry, while in Raphaël's example it is the
geometry itself. Is any of these two approaches based on core semantics of
geometry (e.g. the OGC simple features model)? It seems important that we
use the same definitions in this group.

Given that in Raphaël's variant there is no need for an extra concept
(serialization of a geometry), and because the needed semantics are online
and ready for use I will use Raphaël's pattern in my data set.

The pattern seems extensible too, which is good because different CRSs is
not the only way in which many geometries for a single object can exist.
Others are:

   - different resolutions (generalisation levels)
   - different geometry types (e.g. linestring, polygon, multicurve,...)
   - different number of dimensions (1, 2, 3)

So the geometry (or serialization of the geometry) can be dependent on
multiple variables. And it must be possible to express each of those, and
to use any combination in a query filter.

@Raphaël, the semantics provided by IGN France have proven to interesting
to our community in several discussions. But the fact that human readable
explanations are in French makes it hard for people with insufficient
knowledge of the language to fully understand the vocabularies. Do you
think it is possible for IGN France to provide explanations in English?

Regards,
Frans



2016-04-07 17:49 GMT+02:00 Raphaël Troncy <raphael.troncy@eurecom.fr>:

> Dear Frans, all,
>
> We have resolved this exact problem that we have documented in this paper
> co-authored with IGN (the French National Institute of Geographic and
> Forestry Information), read
> http://www.eurecom.fr/~troncy/Publications/Atemezing_Troncy-terra14.pdf.
>
> This comes to what Matthew wrote:
>   - we defined the property http://data.ign.fr/def/geometrie#crs that has
> for domain a http://data.ign.fr/def/geometrie#Geometry which is a
> subclass of http://www.opengis.net/ont/sf#Geometry
>   - we defined an entire vocabulary to properly define anyone's CRS, see
> http://data.ign.fr/def/ignf/
>   - we published a list of CRSs, commonly used by IGN, with proper URI to
> identify them
>
> Hence, the example of Matthew becomes:
>
> ex:location1234
>   a dcterms:Location ;
>   locn:geometry ex:geom1234 ;
>   locn:geometry ex:geom6789 ;
>
> ex:geom1234
>   a geom:Geometry ;
>   geom:crs <http://www.opengis.net/def/crs/EPSG/0/28992> ;
>   gsp:asWKT "<http://www.opengis.net/def/crs/EPSG/0/28992> POINT(139715
> 476443)"^^geosparql:wktLiteral.
>
> ex:geom6789
>   a geom:Geometry ;
>   geom:crs <http://www.opengis.net/def/crs/OGC/1.3/CRS84> ;
>   gsp:asWKT "<geosparql:asWKT "POINT(5.1633
> 52.2758)"^^geosparql:wktLiteral.
>
> Where:
> @prefix sf: <http://www.opengis.net/ont/sf#>.
> @prefix gsp: <http://www.opengis.net/ont/geosparql#>.
> @prefix ignf: <http://data.ign.fr/def/ignf#>.
> @prefix geom: <http://data.ign.fr/def/geometrie#>.
>
>   Raphaël
>
> --
> Raphaël Troncy
> EURECOM, Campus SophiaTech
> Data Science 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/
>