- From: Andrea Perego <andrea.perego@jrc.ec.europa.eu>
- Date: Thu, 28 Jul 2016 18:52:31 +0200
- To: Frans Knibbe <frans.knibbe@geodan.nl>
- Cc: W3C SDW WG - Public <public-sdw-wg@w3.org>
On 28/07/2016 17:27, Frans Knibbe wrote: > On 28 July 2016 at 16:26, Andrea Perego <andrea.perego@jrc.ec.europa.eu > <mailto: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 wonder how this can be addressed, practically. Last time I checked the OGC EPSG registry (http://www.opengis.net/def/crs/EPSG/0/), it included 5,500+ CRSs. If we combine CRSs with /N/ geometry serialisations, should the resulting /N/*5,500+ items be recorded in a registry, as RDF datatypes / SKOS concepts? > I more or > less assumed that the WKT encoding of the coordinates already is a best > practise. I think the approach should be consistently applied to all geometry serialisations. Otherwise we'll have geometry literals (WKT) where the datatype denotes the CRS and others (non-WKT) where the datatype denotes the geometry serialisation used. Andrea > 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> > <mailto: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>> > <mailto: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>> > <mailto: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> > <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>> > <mailto: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>> > <mailto: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>> > <mailto: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>> > <mailto: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> > <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>> > <mailto: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>> > <mailto: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>> > <mailto: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>> > <mailto: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/ > > -- 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 16:53:19 UTC