- From: Frans Knibbe | Geodan <frans.knibbe@geodan.nl>
- Date: Mon, 30 Dec 2013 17:27:46 +0100
- To: public-locadd@w3.org
- Message-ID: <52C19F02.8070706@geodan.nl>
Hi Andrea, all,
My thoughts on this matter:
1. I think it would be be best if the CRS is identified by a URI. This
allows dereferencing the identifier to find out things about the CRS.
2. I think that in most cases the CRS identifier will not be used for
dereferencing, but for filtering data on CRS or for finding out the
CRS of a geometry or a collection of geometries.
3. I think the CRS should not only be applicable to geometries, but to
collections of geometries or datasets too. In other words, I think
it should be possible to use the specification of the CRS in the
dataset metadata, possibly instead of repeatedly specifying a CRS
for each geometry in a dataset.
4. Being able to dereference a CRS URI is desirable. A common case
would be to get the EPSG code of a CRS, an important attribute if
data are used in current GIS software.
5. Other examples of the usefulness of having access to all CRS
parameters (as will be the case in the system IGN France is
developing) are getting information on the axis orientation of a CRS
(a great source of confusion) and enabling automatic coordinate
transformations (without the need for a library of CRS parameters).
6. Although it would be nice not to have a lot of CRS registries to
choose from, I don't think any specific registry should be
recommended. I think it is best to leave it open to future
developments to find a best practice for identifying (and
describing) CRS's. This would in the spirit of the vocabulary too,
because the specification of geometry is also left very open.
7. To answer a part of Krzysztof's question (What would be wrong with
having the identification of the CRS together with the WKT in a
literal): I believe the basic thing is that the coordinates of a
geometry and its CRS are just two separate things that should not be
conflated. When this happens, it has many undesirable effects. For
example, it becomes much harder to use the CRS as a filter in a
SPARQL query (e.g. give me all geometries that have CRS =
<http://my/crs> ). Also, it is not possible to assign multiple CRS
specifications to a geometry (e.g. the CRS of this geometry has
identifier X issued by the OGC and identifier Y issued by IGN
France). Storage media will probably have a hard time indexing data
by CRS if the CRS is hidden away in a literal. And, as I wrote
before, I don't think the domain of a CRS specification should be
limited to a single geometry.
I wonder if there is a reason why it would a good thing to combine
geometry and identification of the CRS in a single literal?
Based on these considerations I think it would be nice to add a CRS
property to the vocabulary, that its range should be a URI and that the
domain of the property should include datasets (void:Dataset,
dcat:Dataset ?). I don't know if it makes sense to also include RDF
collections in the domain...
Regards,
Frans
On 2013-12-30 0:13, Andrea Perego wrote:
> Dears,
>
> Based on the discussion on the original thread (see mails [1-5]), I
> would kindly ask your feedback on the following proposal:
>
>
> *Proposed resolution*
>
> Add to the LOCN voc an optional property to specify the CRS of a
> geometry. The range of such property can be either a literal (e.g.,
> EPSG:4326), a URN (e.g., urn:ogc:def:EPSG::4326) or an HTTP URI
> reference (e.g., http://www.opengis.net/def/crs/EPSG/0/4326).
>
>
> Intentionally, I've not included the following two points, since the
> position of the group is still unclear on them:
>
> 1. Should the use of HTTP URIs be recommended? BTW, on this, Krzysztof
> posted a question that has not been yet answered [1].
>
> 2. Should we recommend a specific CRS URI register?
>
> I kindly ask you to use this thread to post any relevant comments.
>
> Thanks!
>
> Andrea
>
> ----
> [1]http://lists.w3.org/Archives/Public/public-locadd/2013Dec/0022.html
> [2]http://lists.w3.org/Archives/Public/public-locadd/2013Dec/0027.html
> [3]http://lists.w3.org/Archives/Public/public-locadd/2013Dec/0028.html
> [4]http://lists.w3.org/Archives/Public/public-locadd/2013Dec/0029.html
> [5]http://lists.w3.org/Archives/Public/public-locadd/2013Dec/0030.html
>
>
>
> On Sun, Dec 22, 2013 at 11:13 PM, Raphaël Troncy
> <raphael.troncy@eurecom.fr <mailto:raphael.troncy@eurecom.fr>> wrote:
>
> @Raphaël, could you please provide some more details about the CRS
> conversion service you are about to publish?
>
>
> This is a REST service that implements a number of algorithms for
> doing projections between CRS, similar to what the Circé software
> is doing, but implemented as a web-based service, see
> http://fr.wikipedia.org/wiki/Circ%C3%A9_%28logiciel%29
> (unfortunately, only in French).
> More details in Jan/Feb when we actually publish the service.
> 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>
--------------------------------------
Received on Monday, 30 December 2013 16:28:22 UTC