Re: CRS specification

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?

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.

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 <mailto: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
>     <mailto:raphael.troncy@eurecom.fr> & raphael.troncy@gmail.com
>     <mailto:raphael.troncy@gmail.com>
>     Tel: +33 (0)4 - 9300 8242 <tel:%2B33%20%280%294%20-%209300%208242>
>     Fax: +33 (0)4 - 9000 8200 <tel:%2B33%20%280%294%20-%209000%208200>
>     Web: http://www.eurecom.fr/~troncy/ <http://www.eurecom.fr/%7Etroncy/>
>
>
>
>
> -- 
> 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 <http://www.geodan.nl> | disclaimer 
<http://www.geodan.nl/disclaimer>
--------------------------------------