- From: Frans Knibbe <frans.knibbe@geodan.nl>
- Date: Thu, 28 Jul 2016 17:27:04 +0200
- To: Andrea Perego <andrea.perego@jrc.ec.europa.eu>
- Cc: W3C SDW WG - Public <public-sdw-wg@w3.org>
- Message-ID: <CAFVDz41uwmANG9vEqFySmGY4=wg+NXunyKob-KeoVH8uRSfL4Q@mail.gmail.com>
On 28 July 2016 at 16:26, Andrea Perego <andrea.perego@jrc.ec.europa.eu> wrote: > (re-directing this conversation to the SDW mailing list) Probably a good idea. > > > 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. > That is true. But that does not necessarily mean the CRS reference should be part of a literal. In case of a single geometry, the CRS reference could be coupled in another way, for instance as a triple if the geometry is an object, or in the datatype specification. > > [snip] >> >> 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. > Not if the geometry encoding is also part of the datatype specification. Perhaps I could have written "50 6"^^geo:crs84WKTliteral. I more or less assumed that the WKT encoding of the coordinates already is a best practise. Regards, Frans > 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/ >> >> >> > -- > 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 15:27:47 UTC