Re: geosparql:asWkt feedback from NL

Hi Linda,

Thanks for forwarding the comments.

One of the downsides of encoding the CRS info into the WKT literal is 
that you can't directly process the string with existing WKT tools, but 
it's pretty trivial to read a few bytes and strip the CRS URI off. I 
would be concerned with a proliferation of different datatypes if we 
encoded the CRS into the datatype URI. Creating subproperties of 
ogc:asWKT seems like a good, practical approach though.

By the way, GeoSPARQL already defines a function to return the CRS of a 
WKT literal:

*8.7.10 Function: geof:getsrid*

geof:getSRID (geom: ogc:geomLiteral): xsd:anyURI

Returns the spatial reference system URI for geom.

Cheers,
Matt


On 7/25/2016 3:22 AM, Linda van den Brink wrote:
>
> Hi all,
>
> From the developers at the Dutch Kadaster I got the email below, 
> detailing some of the problems they have with CRS detection and 
> selection in the current (web) standards. They also suggest some 
> interesting solutions.
>
> (sent to the comments list so they can participate in any discussion)
>
> Linda
>
> *Van:*Brattinga, Marco [mailto:Marco.Brattinga@ordina.nl]
> *Verzonden:* zaterdag 23 juli 2016 22:49
> *Aan:* Linda van den Brink; Veer, Rein van (Rein.vanVeer@kadaster.nl); 
> Farla, Joost (Joost.Farla@kadaster.nl); Maria, Pano 
> (Pano.Maria@kadaster.nl)
> *CC:* Brattinga, Marco (Marco.Brattinga@kadaster.nl)
> *Onderwerp:* RE: geosparql:asWkt uitdaging icm CRS-en
>
> Linda,
>
> As you know, at the Dutch Land Registry, we are currently making all 
> our public data available as Linked Open Data. Because most of our 
> data contains a spatial component, we are very interested in the work 
> of the spatial on the web workgroup.
>
> We would like to raise some questions and have the opportunity to 
> share our concerns and experiences.
>
> The situation:
>
> -Our data should not only be available as Linked Open Data, but also 
> as JSON-LD and JSON data via REST API’s;
>
> -Currently, we store our spatial information as WKT strings;
>
> -Most of the original spatial data is represented as RD (the Dutch 
> CRS, EPSG:28992), and some geospatial experts would really like to use 
> the data in its original CRS;
>
> -But most “regular” webdevelopers would like to use the data as CRS84;
>
> -As far as we know, a “regular” WKT string doesn’t contain a reference 
> to the CRS, and this should be figured out from the context;
>
> -The current geosparql specification specifies that the asWKT object 
> is a WKT string, prefixed with a CRS, represented with its URI name, 
> or –if absent- CRS84 is assumed;
>
> We use the geosparql specification, so a particular resource will have 
> a property geosparql:hasGeometry, with a reference to a resource of 
> the class geosparql:Geometry, and this latter resource has a 
> geosparql:asWKT property, with a WKT string as the object.
>
> Our challenges:
>
> -We like the idea of a separate geometry. But we would like to include 
> multiple WKT-strings, each with its own CRS, just like you would have 
> an rdfs:label with multiple languages;
>
> -The current situation means that we would have to encode the CRS in 
> the WKT-string and that means that it is not really a WKT string any 
> more (which presents problems if we want to use it for our REST API, 
> which users don’t understand the encoding of the CRS);
>
> -Another problem is, that you’ll get multiple asWKT triples, you have 
> to parse the string if you want to select just one of the triples. 
> This is not nice (at least we would like to have a function available, 
> just like the lang() function)
>
> At this moment, we’ve solved the problem by introducing a 
> subPropertyOf asWKT, for every CRS:
>
> pdok:asWKT-RD rdfs:subPropertyOf geosparql:asWKT
>
> Every Geometry in our dataset has one geosparql:asWKT with a WKT 
> string without a CRS (meaning that it should be CRS84, which is fine), 
> and a property pdok:asWKT-RD with the semantics that it also shouldn’t 
> contain a CRS, because EPSG:28992 is assumed. It works and is 
> compliant to the standards, but not very nice.
>
> What we really would like is:
>
> -A more elegant way of encoding the CRS. Maybe you could do it just 
> like a language tag, for example: <Geo> geosparql:asWKT “POINT(53,2 
> 5,6)”@EPSG:28992;
>
> -A function to check for a particular CRS, similar to lang(), for 
> example: crs(?wkt) (which would result a literal or maybe a IRI 
> representing the CRS)
>
> Because most spatial encodings can be converted between each other, 
> even a better approach might be to have a transformation service 
> (toCRS(?wkt,?crs)).
>
> Last, but not least: it would be very much appreciated if a user could 
> request for a particular CRS, and the response could “tell” what the 
> CRS is. We would like to suggest using http-accept-crs and a 
> crs-content-type kind of headers, just like a language accept-header 
> or a serialization accept-header: having content negotiation available 
> for CRS’s as well.
>
> With regards,
>
> Marco
>
>
> This e-mail and any attachments are confidential and are solely 
> intended for the addressee. If you are not the intended recipient, 
> please notify the sender and delete and/or destroy this message and 
> any attachments immediately. It is prohibited to copy, to distribute, 
> to disclose or to use this e-mail and any attachments in any other 
> way. Ordina N.V. and/or its group companies do not accept any 
> responsibility nor liability for any damage resulting from the content 
> of and/or the transmission of this message.
>
>
>