- From: Andrea Perego <andrea.perego@jrc.ec.europa.eu>
- Date: Thu, 28 Jul 2016 16:26:05 +0200
- To: Frans Knibbe <frans.knibbe@geodan.nl>
- Cc: W3C SDW WG - Public <public-sdw-wg@w3.org>
(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/ > > -- 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:26:49 UTC