Re: geosparql:asWkt feedback from NL

Josh,

I'm all for a CRS property outside of the literal as an additional 
property for the Geometry, with a distinct Geometry URI for each CRS 
used. The 1-to-many cardinality would be from Feature to Geometry and 
then a cardinality of 1 for the asWKT property. From what I understand, 
this is what GeoSPARQL intended.

I just think we need to keep the encoded CRS reference inside the 
wktLiteral. Any potential inconsistencies between the CRS property of 
the geometry and the encoded CRS in the literal cannot be eliminated 
because the CRS reference is already part of GML and GeoJSON.

Thanks,
Matt


On 7/27/2016 9:43 AM, Joshua Lieberman wrote:
> Matt,
>
> There is clearly value for some purposes in keeping a CRS option 
> within the WKTLiteral. It is also valuable, though, to have a crs 
> property outside of the literal. Whether or not the internal label is 
> there, the CRS of the coordinates would need to match the geometry CRS 
> property. One could clearly debate whether to load the encoding 
> property further with attributes and increase the cardinality, but my 
> feeling is that the advantages would be outweighed by the complexity. 
> I prefer that we concentrate on enabling choice of geometries for a 
> feature according to CRS, geometry type, geometry role, etc., but use 
> the encoding properties only for choice of specific encodings (WKT vs 
> GML vs …).
>
> Josh
>
>> On Jul 25, 2016, at 11:03 AM, matthew perry <matthew.perry@oracle.com 
>> <mailto:matthew.perry@oracle.com>>rote:
>>
>> Hi Josh,
>>
>> I would be pretty strongly opposed to removing the encoded CRS 
>> reference from wktLiteral.
>>
>> If you look at other formats like GML and GeoJSON, those geometry 
>> literals include encoded CRS information, and it is implicitly 
>> encoded in KML because there is only one possible CRS. WKT is really 
>> the only major serialization that lacks CRS information, so to me it 
>> seems better to add CRS information to WKT so that it is consistent 
>> with the other serializations instead of depending on some other 
>> property of the geometry that may or may not exist in a particular 
>> dataset.
>>
>> From a triplestore implementer's point of view, creating a spatial 
>> index for a GeoSPARQL dataset would be an order of magnitude harder 
>> if CRS information is not encoded in the geometry literal itself and 
>> you have to resort to looking for other triples to determine the CRS, 
>> as these triples may be missing and will be updated over time. Plus, 
>> such a change for GeoSPARQL 1.1 would not be backwards compatible 
>> with GeoSPARQL 1.0, which would cause a lot of headaches.
>>
>> Thanks,
>> Matt
>>
>>
>> On 7/25/2016 10:30 AM, Joshua Lieberman wrote:
>>> Hi,
>>>
>>> I am a bit concerned about proliferating versions of geomLiteral and 
>>> asWKT properties. It’s a big step already to make a geometry a 
>>> first-class object with a global identifier and all the management 
>>> issues that raises. Others have also noted that queries get 
>>> considerably more complicated if one has to peer into the literals 
>>> in order to get the right result. The alternative is to treat the 
>>> asWKT and other coordinate properties as the data properties they 
>>> are, dependent on the geometry object they are a part of. Then the 
>>> coordinate system is defined by the crs property of the geometry. It 
>>> may even be best to remove the CRS reference from the WktLiteral to 
>>> improve interoperability between that and “regular” WKT that is 
>>> returned by database functions.
>>>
>>> Another consideration is to make it easier for software systems to 
>>> provide the right CRS and translate between CRS’s as needed. One way 
>>> might be to negotiate CRS as part of the content format for the 
>>> geometry, as we have proposed for encoding format (e.g. 
>>> application/ttl; geomLiteral=“WKT”; crs=“CRS84"). This at least 
>>> doesn’t proliferate encodings or languages.
>>>
>>> It would also, I think, simplify making queries that don’t have to 
>>> explicitly select a geometry to test spatial relations or filters 
>>> and allow the responding system to select or transform CRS’s as 
>>> needed to process the query.
>>>
>>> Josh
>>>
>>>> On Jul 25, 2016, at 9:34 AM, Brattinga, Marco 
>>>> <Marco.Brattinga@ordina.nl <mailto:Marco.Brattinga@ordina.nl>> wrote:
>>>>
>>>> Hi Matt,
>>>> Thanks for pointing us to the geof:getSRID, this is indeed what we 
>>>> need for that particular requirement.
>>>> As for the encoding of CRS: we propose to encode the CRS into the 
>>>> language tag, not the datatype. But you could argue that this would 
>>>> proliferate the set of languages…
>>>> Marco
>>>> *Van:*matthew perry [mailto:matthew.perry@oracle.com]
>>>> *Verzonden:*maandag 25 juli 2016 15:26
>>>> *Aan:*Linda van den Brink; public-sdw-comments@w3.org 
>>>> <mailto:public-sdw-comments@w3.org>
>>>> *CC:*Brattinga, Marco; Veer, Rein van (Rein.vanVeer@kadaster.nl 
>>>> <mailto:Rein.vanVeer@kadaster.nl>); Farla, Joost 
>>>> (Joost.Farla@kadaster.nl <mailto:Joost.Farla@kadaster.nl>); Maria, 
>>>> Pano (Pano.Maria@kadaster.nl <mailto:Pano.Maria@kadaster.nl>)
>>>> *Onderwerp:*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 forgeom.
>>>>
>>>> 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 <mailto:Rein.vanVeer@kadaster.nl>);
>>>>     Farla, Joost (Joost.Farla@kadaster.nl
>>>>     <mailto:Joost.Farla@kadaster.nl>); Maria, Pano
>>>>     (Pano.Maria@kadaster.nl <mailto:Pano.Maria@kadaster.nl>)
>>>>     *CC:*Brattinga, Marco (Marco.Brattinga@kadaster.nl
>>>>     <mailto: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.
>>>>
>>>>
>>>>
>>>>
>>>> Disclaimer
>>>> Dit bericht met eventuele bijlagen is vertrouwelijk en uitsluitend 
>>>> bestemd voor de geadresseerde. Indien u niet de bedoelde ontvanger 
>>>> bent, wordt u verzocht de afzender te waarschuwen en dit bericht 
>>>> met eventuele bijlagen direct te verwijderen en/of te vernietigen. 
>>>> Het is niet toegestaan dit bericht en eventuele bijlagen te 
>>>> vermenigvuldigen, door te sturen, openbaar te maken, op te slaan of 
>>>> op andere wijze te gebruiken. Ordina N.V. en/of haar 
>>>> groepsmaatschappijen accepteren geen verantwoordelijkheid of 
>>>> aansprakelijkheid voor schade die voortvloeit uit de inhoud en/of 
>>>> de verzending van dit bericht.
>>>>
>>>> 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.
>>>
>>
>