Re: geosparql:asWkt feedback from NL

Hello Marco,

Could you explain why "regular" webdevelopers want to have geometries using
CRS84? If it is because they want spherical coordinates (degrees lon/lat),
you would be better off with ETRS89, the recommended coordinate system for
European geographic data.

CRS84 is a difficult CRS for coordinates that are not in North America. If
you have decimeter/centimeter level precision or higher, all geometries
should have very tightly linked temporal data, because you need to account
for continental drift if you want to plot those geometries on European
territory.

Regards,
Frans

On 25 July 2016 at 09:22, Linda van den Brink <l.vandenbrink@geonovum.nl>
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.
>
>
>
>