Re: CRS specification

Hi All,

Comments inline

Frans Knibbe | Geodan <frans.knibbe@geodan.nl> wrote on 14-01-2014 
10:55:29:

> Hello,
> 
> I am not sure there is agreement either. But I believe that Kostis 
> could live with a specification of CRS when it is applied to dataset
> metadata. That is something, it at least means that there could be 
> agreement on having the CRS in the vocabulary as a separate entity. 
> Maybe there is some way to keep the definition open enough for now? 

One of the options could be to state that, unless defined otherwise, the 
geometry is specified using WGS84?
I'm not a GEO specialist but from what I can see out on the web this is 
the dominant CRS used. Both for publications and for tools used to consume 
the data
 
> I have the distinct feeling that a well defined CRS entity in the 
> vocabulary is dependent on the definition of the Geometry class. The
> CRS could also be contained in some of the geometry expressions that
> are allowed now, so there is potential conflict there. The class 
> Geometry is defined very liberally now. On the one hand that is 
> good, because it gives freedom to use it. On the other hand it is 
> bad, because knowing that something is a locn:Geometry does not 
> actually say very much. The class is not that useful in its present 
> state. And, as in the CRS example, it is difficult to extend the 
> class because it is not well defined.  So if we feel like discussing
> the Geometry class (stabilizing it), maybe the decision on how to 
> model CRS can wait for the conclusion of that discussion. 
> 
> And yes, I think it would be a good idea to separately discuss the 
> idea of geospatial extensions to metadata vocabularies. I would be 
> happy to contribute. Maybe we can make a wiki page for that topic.

I think it is very important to have CRS attribute on Geometry resources.
We are talking about linked data, so as a end user I might be interested 
in only one resource.
I think it would be extermly cumbersome to always have to fetch the 
metadata of a dataset to determine the CRS.
If you want to stimulate adoption of linked data it should be easy to get 
started, needing multiple gets is not helping.

Ofcources it should also be in the DCAT specification of the dataset with 
a new profile.

My 2 cents

 
> Regards,
> Frans
> 
> On 2014-01-13 8:26, Andrea Perego wrote:
> Dears, 
> 
> I'm not sure we have reached an agreement about the issue concerning
> CRS specification. However, a number of use cases have been 
> thoroughly described, highlighting when it is useful to have the CRS
> in the serialisation of a geometry and when it is useful to keep it 
separate.
> 
> I wonder whether this can be reflected in the LOCN vocabulary, by 
> recommending the best ways of expressing a geometry depending on the
> use case. So, users will be able to choose the one that most fits 
> their requirements. We can use the wiki page concerning class 
> locn:Geometry [1] to work on this.
> 
> IMHO, both Frans and Raphaël illustrated strong use cases in favour 
> of the possibility of specifying the CRS (also) outside the 
> serialisation of a geometry. The discussed solution was defining a 
> specific property in the LOCN vocabulary, since there's no suitable 
> candidate in existing vocabularies. So, I would like to ask the 
> group whether there are still any objections in defining it, as an 
> "optional" property that can be used in one of the ways recommended 
> by the LOCN vocabulary to express a geometry.  
> 
> I may be wrong, but, as far as I can tell, all the objections have 
> been discussed, with the exception of the one raised by Clemens 
> about the specification of "potentially conflicting" CRSs [2]. 
> 
> My last point. Frans outlined a use case concerning the use of CRS 
> specifications in dataset metadata [3]. I think this introduces a 
> possible new work item for our group, i.e.: is anybody interested in
> working on possible geospatial extensions to dataset vocabularies 
> (as DCAT, VoID)? But it may be worth discussing this in a new thread.
> 
> Best,
> 
> Andrea
> 
> ----
> [1]http://www.w3.org/community/locadd/wiki/LOCN:_Class_Geometry
> [2]http://lists.w3.org/Archives/Public/public-locadd/2014Jan/0000.html
> [3]http://lists.w3.org/Archives/Public/public-locadd/2014Jan/0031.html
> 
> 

> On Tue, Jan 7, 2014 at 12:30 PM, Raphaël Troncy 
<raphael.troncy@eurecom.fr
> > wrote:
> Dear Kostis,

>     True, if you only have the literal, e.g. "POLYGON((97372
>     487152,97372 580407,149636 580407,149636 487152,97372 487152))", you
>     can not get the CRS. But is that a problem? If you have the triple
>     you can get the CRS (provided one is specified).
> 
> You cannot rely on two triples to interpret a single RDF term. See my
> comment on the formal definition of a datatype. On the other hand, since
> we adopt the open world assumption we certainly cannot assume that only
> a single pair of coordinates and CRS will exist in a knowledge base.
> 
> This really comes back to the class vs datatype representation issue
> that has already been pointed out by Frans.
> 
> In your view, if I understand well, you want the geometry value to 
> be of a (complex) datatype, therefore, putting the CRS information 
> *and* the coordinates into a literal that needs to be (correctly) 
> parsed to be used. This has some limitations as we already shown in 
> other threads, e.g. 1/ use of regular expression for some SPARQL 
> queries, 2/ hard-coded interpretation of the value if no CRS is 
> provided, i.e. your software relies on a default CRS, but this 
> default is not made explicit in the vocabulary definition, etc.
> 
> In Frans view (and also mine), a geometry can be a class, that has 
> explicit attributes such as a list of coordinates and a CRS. The CRS
> and the set of coordinates are still tied together in the definition
> of this class. Do you see the difference?

> Well, I do not agree with you in this. We will definitely have multiple
> CRS and there is a good reason for this. Each CRS consider a different
> approximation of the earth. For example, WGS84 consider the earth to be
> spheroidal, which is perfect in some cases and absolute disaster for
> others. It may sound a bit funny at first, but there is also the need in
> some cases to model extraterrestrial coordinates :)
> 
> +1 for this! We definitively need multiple CRS depending on the use 
> case. WGS84 is fine for many use cases, but a disaster when you need
> precision. 
> 
> Best regards.
> 
>   Raphaël
> 
> -- 
> Raphaël Troncy
> EURECOM, Campus SophiaTech
> Multimedia Communications Department
> 450 route des Chappes, 06410 Biot, France.
> e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com
> Tel: +33 (0)4 - 9300 8242
> Fax: +33 (0)4 - 9000 8200
> Web: http://www.eurecom.fr/~troncy/

> 

> 
> -- 
> Andrea Perego, Ph.D.
> European Commission DG JRC
> Institute for Environment & Sustainability
> Unit H06 - Digital Earth & Reference Data
> Via E. Fermi, 2749 - TP 262
> 21027 Ispra VA, Italy
> 
> DE+RD Unit: http://ies.jrc.ec.europa.eu/DE
> 
> ----
> The views expressed are purely those of the writer and may
> not in any circumstances be regarded as stating an official
> position of the European Commission. 
> 

> -- 
> --------------------------------------
> Geodan
> President Kennedylaan 1
> 1079 MB Amsterdam (NL)
> 
> T +31 (0)20 - 5711 347
> E frans.knibbe@geodan.nl 
> www.geodan.nl | disclaimer
> --------------------------------------