- From: matthew perry <matthew.perry@oracle.com>
- Date: Thu, 28 Jul 2016 10:51:16 -0400
- To: public-sdw-wg@w3.org
I agree with Andrea. Being able to attach a CRS URI to something (geometry, whole dataset, etc.) is a good thing. Including CRS info in a geometry serialization literal is a good thing too. This is not an "either or" choice. It should be fine to do both. - Matt On 7/28/2016 10:26 AM, Andrea Perego wrote: > (re-directing this conversation to the SDW mailing list) > > On 28/07/2016 15:41, Frans Knibbe wrote: >> Hi Andrea, >> >> Yes, it depends what the right level of granularity is. That is why I >> think it would be good idea to allow some freedom there. Sometimes the >> right place is a single geometry (if there is only one geometry, for >> instance), but in other cases distributions, datasets, graphs or classes >> could be an appropriate level. Having the CRS be a mandatory part of the >> coordinate string is too restrictive in my opinion. > > I agree about some freedom is needed, in the (inclusive) sense that a > CRS can be attached to dataset, distributions as well as geometries. > But this does necessarily not mean that if you have a CRS for a > dataset, this needs to be excluded from the geometries belonging to it. > >> About the text and languages: I tried to use text strings as an example, >> an example of something that is complex but for which the world did >> manage to find a workable solution. I hope that we can raise the level >> of interoperability of geometry data on the web to the same level that >> text and numbers currently have, so it could help to look at those >> examples. >> >> An aside: I just looked up some info about datatypes and language >> strings (here >> <https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal>): they can >> coexist, in fact a literal can only have a language tag if the datatype >> is rdf:langString. Because of that, having the language tag implies >> having datatype rdf:langString, and the datatype specification can be >> omitted. >> >> Of course the language tag should be used for text only. I think Marco >> hinted at something similar to language tags. Datatypes could perhaps be >> used. Datatypes are now assigned to literals to specify that a literal >> represents a geometry. Perhaps it makes sense to let the data type also >> identify the CRS? Something like "50 6"^^geo:crs84geometry? The >> specification of the datatype could then refer to a certain definition >> of the CRS (a CRS URI), for example an OGC registry. > > But in this case you're loosing the information about the geometry > serialisation used. So, you know the CRS, but you have to infer how > the geometry is encoded. > > Andrea > >> Greetings, >> Frans >> >> >> On 27 July 2016 at 13:57, Andrea Perego <andrea.perego@jrc.ec.europa.eu >> <mailto:andrea.perego@jrc.ec.europa.eu>> wrote: >> >> Hi, Frans. >> >> My comments inline. >> >> On 27/07/2016 12:47, Frans Knibbe wrote: >> >> Hi Matt, Josh, >> >> Whether or not it makes sense to have a CRS reference be part of >> a WKT >> literal is a returning point of debate. It has been discussed at >> length >> in the Locations and Addresses community group. No clear >> conclusion was >> found, so I would really welcome further discussion. >> >> I am in favour of removing the CRS reference from the WKT string >> (or any >> other geometry datatype). Here are some reasons why: >> >> 1. A CRS reference should be a URI, not part of a string >> literal. >> 2. A geometry is characterised by many attributes (coordinates, >> geometry type, level of detail, CRS, number of >> dimensions,..). To >> conflate all in a single text string would be inflexible. >> 3. In many cases it makes sense to define a CRS at a higher >> level, for >> instance for a dataset/graph, or for a class (e.g. class >> GeomCRS84). >> >> >> Well, that's a tricky ground - I mean identifying the right level of >> granularity. >> >> Just an example: >> >> In the GeoDCAT-AP WG there was a discussion on whether the CRS >> should be specified at the dataset or distribution level (i.e., you >> may have multiple distributions of the same dataset, each using a >> different CRS - or different sets of CRSs). >> >> Eventually, to be in line with ISO 19115, the CRS was associated >> with the dataset, but without preventing people from specifying CRSs >> also for distributions. >> >> 4. It seems to me that GML, GeoJSON and KML are more elaborate >> schemes >> than WKT, which is a single text string, a data type. So it >> makes >> more sense for GML, GeoJSON and KML to include some sort >> of CRS >> reference. >> 5. The orginal WKT did not have a CRS part (although CRS can be >> desribed in WKT, but that is another matter). >> >> >> True, but, besides GeoSPARQL, we have also other examples of CRS >> included in WKT - as the Extended WKT (EWKT) format used in PostGIS: >> >> http://postgis.net/docs/using_postgis_dbmanagement.html#EWKB_EWKT >> >> Said that, I'm not against having the CRS out of geometry literal. >> Only, I don't think we should say if CRSs should be out or in. We >> can support both the approaches. >> >> We know how to include the CRS in geometry literals. What is missing >> is guidance / BPs on how to specify it outside geometry literals. >> >> I have to admit it is a not an easy topic. It has to do with the >> nature >> of geometry: which attributes of a geometry are its intrinsic >> parts? Can >> a geometry exist as a naked string of coordinates? I think >> it can. >> >> I see a parallel with text. Take the word "map". You will >> probably have >> interpreted the word, and probably the interpretation was wrong. >> I meant >> the Dutch word "map", which means "folder" in English. I >> should have >> written "map"^^nl, that would have prevented the >> misunderstanding... >> This example shows that language is an essential attribute of >> text >> strings. Omitting it causes errors. But still it works in >> practice. We >> have the freedom to attach languages to text strings, or to >> infer the >> language from context. I think it would not hurt to have the >> same >> freedom with geometric coordinate strings. >> >> >> I'm not sure, but I guess your point is about Marco's proposal to >> specify the CRS as done with language tags. >> >> If this is the case, I would just like to note that, AFAIK, in RDF a >> literal is either a plain literal (in such a case you can use the >> lang tag) or a typed literal (and then you should specify the >> datatype). >> >> In GeoSPARQL, :asWKT and :asGML are datatype properties - i.e., take >> as value typed literals. And so is locn:geometry, when used with >> geometry literals. >> >> I'm not aware of examples / proposals to associate both a datatype >> and a language tag with a literal - although I may see the rationale >> in relation to having "localised typed literals". >> >> (Sorry for being pedantic here) >> >> Cheers, >> >> Andrea >> >> >> Matt's arguments against are valid, of course. Backward >> compatibility is >> a problem, but not insolvable. And I can imagine that a >> solution for >> triple store management can be found too, with some creative >> thought >> (named graphs for all supported CRSs?). I wonder if modern index >> management in triple stores always assumes that all relevant >> data is >> contained in a single triple. What if you would want to have an >> index of >> names of people, or of toponyms? Some form of distinction >> between types >> of text strings would be needed. What if a recommendation takes >> the form >> of having CRS-typed predicates, something like (<ex:geom1234> >> <geo:crs84Coordinates> "6 50")? >> >> Greetings, >> Frans >> >> >> >> On 25 July 2016 at 17:03, matthew perry >> <matthew.perry@oracle.com <mailto:matthew.perry@oracle.com> >> <mailto:matthew.perry@oracle.com >> <mailto:matthew.perry@oracle.com>>> wrote: >> >> 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> >> <mailto: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 >> <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> >> <mailto: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> >> <mailto:Rein.vanVeer@kadaster.nl >> <mailto:Rein.vanVeer@kadaster.nl>>); Farla, Joost >> (Joost.Farla@kadaster.nl >> <mailto:Joost.Farla@kadaster.nl> >> <mailto:Joost.Farla@kadaster.nl >> <mailto:Joost.Farla@kadaster.nl>>); >> Maria, Pano (Pano.Maria@kadaster.nl >> <mailto:Pano.Maria@kadaster.nl> >> <mailto: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 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 >> <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> >> <mailto:Rein.vanVeer@kadaster.nl >> <mailto:Rein.vanVeer@kadaster.nl>>); >> Farla, Joost (Joost.Farla@kadaster.nl >> <mailto:Joost.Farla@kadaster.nl> >> <mailto:Joost.Farla@kadaster.nl >> <mailto:Joost.Farla@kadaster.nl>>); Maria, Pano >> (Pano.Maria@kadaster.nl >> <mailto:Pano.Maria@kadaster.nl> >> <mailto:Pano.Maria@kadaster.nl >> <mailto:Pano.Maria@kadaster.nl>>) >> *CC:* Brattinga, Marco >> (Marco.Brattinga@kadaster.nl >> <mailto:Marco.Brattinga@kadaster.nl> >> <mailto: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. >> >> >> >> >> >> -- >> Andrea Perego, Ph.D. >> Scientific / Technical Project Officer >> European Commission DG JRC >> Directorate B - Growth and Innovation >> Unit B6 - Digital Economy >> Via E. Fermi, 2749 - TP 262 >> 21027 Ispra VA, Italy >> >> https://ec.europa.eu/jrc/ >> >> >
Received on Thursday, 28 July 2016 14:51:54 UTC