- From: Frans Knibbe | Geodan <frans.knibbe@geodan.nl>
- Date: Fri, 03 Jan 2014 11:48:49 +0100
- To: Kostis Kyzirakos <Kostis.Kyzirakos@cwi.nl>, LocAdd W3C CG Public Mailing list <public-locadd@w3.org>
- Message-ID: <52C69591.8030707@geodan.nl>
Hello,
I agree that a sequence of coordinates should be associated with a CRS.
In my opinion, that is exactly what happens in the example I gave:
ex1:myGeometry
a ex2:geometry ;
ex2:asWKT "POLYGON((97372 487152,97372 580407,149636 580407,149636
487152,97372 487152))"^^ex2:wktLiteral ;
ex2:CRS <http://www.opengis.net/def/crs/EPSG/0/28992>
<http://www.opengis.net/def/crs/EPSG/0/28992> ;
This is based on the viewpoint of a geometry consisting of a sequence of
coordinates and a CRS. They are both properties of a geometry.
My feeling is that it is conceptually awkward to put the specification
of the CRS and the coordinates in the same literal. Others might feel it
to be the other way around. It is hard to prove that one way is right or
wrong. Ultimately, the decision is arbitrary. What I think is important
to consider is /convenience/. Which method is more convenient? In the
line of Kostis's decimal example, let us look at something that is
perhaps more straightforward: the encoding of text. The word "Αθήνα" is
usually encoded in a single literal, e.g.:
ex1:myFeature ex2:name "Αθήνα"^^xsd:string;
But the world could also have agreed to code the individual characters:
ex2:name [
a rdf:Seq ;
rdf:_1 "Α";
rdf:_2 "θ";
rdf:_3 "ή";
rdf:_4 "ν";
rdf:_5 "α".
] .
This is somewhat similar to the decision made in NeoGeo to keep the
coordinates separate objects.
In some scenarios, it may be more convenient to model a text as an
ordered sequence of character elements. In most cases, the text will be
used as a whole, without any need to process the individual characters.
So the first example is more convenient than the second. Now let us try
to put the word "Αθήνα" in perspective by including its script and language:
ex1:myFeature
a ex2:name ;
ex3:spelling "Αθήνα"^^xsd:string ;
ex3:language "Greek" ;
ex3:script "Greek" .
The extra properties provide data that are vital for the correct
interpretation of the string in some cases. So why not put them all in
the same literal?
ex1:myFeature ex2:name "script='Greek';language='Greek';'Αθήνα'";
It is easy to see that this is not the most convenient way of expressing
the text. For example, it needs some processing before it can be used to
form a human readable text. Similarly, I don't think it is convenient to
put the specification of the CRS together with a coordinate sequence in
the same literal. Here is a list of reasons why I think it is inconvenient:
1. Most (all?) current GIS software takes coordinate strings and CRS
specifications separately.
2. It should be possible to specify the CRS at the level of a data set
or a collection of geometries.
3. It should be made easy for storage media to index the CRS.
4. It should be possible to easily select data based on CRS in SPARQL
queries.
5. Having multiple specifications of the same CRS for a single geometry
should be possible.
6. Having multiple specifications of the same coordinate sequence for a
single geometry should be possible.
7. There should not be a single authority for specifying CRS's
(especially if we want specifications to last until the sun goes nova).
8. Next to CRS there are other geometry properties that could be
important, like level of detail. Do they need to be put in the same
literal too? That would make things even messier.
9. It should be possible to select only the CRS or only the coordinates
(for specific use cases).
10. Processing the coordinates requires removing the CRS specification
from the string, which is undesirable extra processing.
11. It should be possible to make statements about the CRS.
12. It should be possible to dereference a CRS.
And I am quite sure this list is not exhaustive. Is it possible to have
an overview of advantages of concatenating the CRS and the coordinates?
Put in a more general perspective: If geographical data are going to
exist in the web of Linked Data, it is good to depart from historical
constructs if better solutions are on offer. Using a URI to identify a
CRS is a very good step in the rights direction. But why make it
impossible to use that same URI in an RDF triple?
Regards,
Frans
On 2014-01-02 16:03, Kostis Kyzirakos wrote:
> Hi all,
> We had a similar discussion on what is the best way to incorporate
> information about the
> CRS that is tied with a geometric object when we designed stSPARQL [1]
> and we ended
> up taking the same decision with the GeoSPARQL WG!
>
> A CRS and a geometry serialization are not two separate things. On the
> contrary, the
> interpretation of the coordinates of a geometry serialization depends
> on the coordinate reference
> system that is associated with the geometry serialization. A sequence
> of coordinates does
> not have any meaning, when not associated with a CRS. For this reason,
> recent standards
> like GML and GeoSPARQL force the association of a geometric object
> with a CRS while
> other standards like KML have this information hard-coded (as Clemens
> also pointed out!).
>
> (We could have a similar discussion regarding decimal numbers. Should
> we represent a decimal
> number using a single literal and use two functions to access each
> part of the number that is
> before and after the decimal mark, or should we use two separate
> literals?)
>
> For this reason, in GeoSPARQL (similarly to OGC-SFA and SQL MM) you
> can find out the
> CRS that has been used for encoding the serialization of a geometric
> object using the
> function geof:getsrid.
>
> If you want to use multiple serializations of a geometry by using
> various CRS, you can use
> multiple triples. Now, the problem of having multiple CRS is that
> tranformations between
> compatible CRS always introduces some error. I agree with the approach
> of GeoSPARQL,
> that essentially adopts that fact that geometries may be implicitly
> transformed to a different
> CRS at query time. For example, when defining topological functions like
>
> geof:sfOverlaps(geom1: ogc:geomLiteral,geom2: ogc:geomLiteral):
> xsd:boolean
>
> the standard says "Each function returns an xsd:boolean value of true
> if the specified relation
> exists between geom1 and geom2 and returns false otherwise. In each
> case, the spatial
> reference system of geom1 is used for spatial calculations". My
> opinion is that this design choice
> makes things much easier for a user that do not care about CRS
> involved in answering her query
> and just want an (possibly imperfect) answer over the complete
> information stored in a graph.
> This is not restrictive however, since a user that do care about which
> CRS are being used when
> answering a query, she can add one or more filter expressions to
> specify exactly which CRS
> should be considered.
>
> What is currently missing from GeoSPARQL regarding CRS (but can be
> easily added to a next
> version), is a function like the function TRANSFORM defined in SQL-MM
> 3 (which we also
> implemented as the function strdf:transform(geom: ogc:geomLiteral,
> targetCRS: anyURI) in our
> system Strabon [2]) that can be used at the SELECT part of a SPARQL
> query to return to the
> user the geometry serialized according to a specific CRS.
>
>
> Best regards (and a happy new year!),
> Kostis
>
> [1] http://www.strabon.di.uoa.gr/stSPARQL
> [2] http://www.strabon.di.uoa.gr
>
> ===================================================
> Kostis E. Kyzirakos, PhD
> Centrum voor Wiskunde en Informatica
> DB Architectures (DA)
> Office L320
> Science Park 123
> 1098 XG Amsterdam (NL)
> tel: +31 (20) 592-4039
> mobile: +31 (0) 6422-95345
> e-mail: kostis@cwi.nl <mailto:kostis@cwi.nl>
> ===================================================
>
>
> On Thu, Jan 2, 2014 at 10:23 AM, Frans Knibbe | Geodan
> <frans.knibbe@geodan.nl <mailto:frans.knibbe@geodan.nl>> wrote:
>
> Hello Clemens, All,
>
> First I would like to wish everyone a healthy and fruitful new year!
>
> Secondly, thanks to Clemens for stating his doubts about a
> separate CRS property. All change proposals should be well thought
> over.
>
> In a previous message I tried to explain what I think are good
> reasons to keep it separate. Of course, whether the CRS is an
> intrinsic part of a geometry all depends the exact definition of
> what a geometry is. I don't know where the official OGC
> specification can be found, but if someone can provide a pointer
> that would be nice. The definition in the LOCN vocabulary seems to
> be quite open.
>
> I think a reasonable definition would be that a geometry defines a
> shape of a geographic object by means of a series of coordinates.
> A single geographic object can have multiple geometries, each a
> different approximation of the true shape of the geographic
> object. The series of coordinates naturally depends on the CRS.
> But if you look more closely, there is a lot more that can be
> stated about the geometry. For example, and I think that is an
> important one too, there is the level of detail (LOD), which could
> perhaps be defined as a resolution in meters. And there are other
> things too. Let's have an example in turtle:
>
> ex1:myGeometry
> a ex2:geometry ;
> ex2:asWKT "POLYGON((97372 487152,97372 580407,149636
> 580407,149636 487152,97372 487152))"^^ex2:wktLiteral ;
> ex2:CRS <http://www.opengis.net/def/crs/EPSG/0/28992>
> <http://www.opengis.net/def/crs/EPSG/0/28992> ;
> ex2:CRS <http://www.other.org/srs/12345>
> <http://www.other.org/srs/12345> ;
> ex2:levelOfDetail "10.5"^^xsd:decimal ;
> ex2:horizontalAccuracy "1.2"^^xsd:decimal ;
> ex2:verticalAccuracy "0.8"^^xsd:decimal ;
> .
>
> I have added some data that helps to put the string of coordinates
> in perspective. Maybe others would like to add still more, like
> the generalisation method used, if any. Or whether the geometry
> was measured in the field or computed. Now imagine us having to
> put all these data in a single literal, and make sense of it...
>
> By the way, looking at this example I am getting the notion that
> keeping the specification of the geometry type ("POLYGON" in this
> case) separate too might be a good idea :-)
>
> Regards,
> Frans
>
>
>
> On 2013-12-30 3:55, Clemens Portele wrote:
>> Hi Andrea,
>>
>> I would propose to support only http URIs. The use of literals
>> like EPSG:4326 or URNs like urn:ogc:def:EPSG::4326 has been
>> deprecated by OGC. There is no need to support legacy in the core
>> location vocabulary. (As an aside, the notation EPSG:nnnnn was
>> also meant to be a URI - after registering the URI scheme "EPSG"
>> with IANA, which never happened.)
>>
>> In addition, and that is my main concern, I am not sure I
>> understand the proposed property. The CRS information is
>> intrinsic to the geometry representation, which is kept open in
>> LOCN, so how exactly would this property be defined or be useful?
>> Of course, every geometry representation should be explicit about
>> its CRS - or specify the standard CRS, if no CRS is or can be
>> specified explicitly in the geometry representation. This is
>> already the case in most of the sample encodings mentioned at
>> http://www.w3.org/ns/locn#locn:geometry, e.g.:
>>
>> - WKT (GeoSPARQL): CRS info optional, a URI, default is
>> http://www.opengis.net/def/crs/OGC/1.3/CRS84
>> - GML: CRS info mandatory, a URI
>> - RDF+WKT (GeoSPARQL): CRS info optional, a URI, default is
>> http://www.opengis.net/def/crs/OGC/1.3/CRS84
>> - RDF+GML (GeoSPARQL): CRS info mandatory, a URI
>> - KML: fixed to 2D or 3D geodetic WGS84 with long/lat(/alt) axis
>> order, decimal degrees for lat and long, metres for alt
>> - geo URI: optional, but discouraged (values not specified),
>> default is 2D or 3D geodetic WGS84 with lat/long(/alt) axis
>> order, decimal degrees for lat and long, metres for alt
>>
>> So each of these geometry representations already includes the
>> information about the CRS. It is not clear to me what the value
>> of an additional, potentially conflicting CRS property would be.
>>
>> In addition, the CRS is strictly not a property of a geometry,
>> but of a particular representation / serialisation.
>>
>> In the GeoSPARQL Standards Working Group in OGC we had also
>> discussed having a CRS property. Actually earlier drafts had a
>> separate geo:srid property, but this has been removed in the
>> final version for exactly these reasons (plus this approach
>> results in simpler SPARQL queries).
>>
>> Best regards,
>> Clemens
>>
>>
>> On 30 Dec 2013, at 00:13, Andrea Perego
>> <andrea.perego@jrc.ec.europa..eu
>> <mailto:andrea.perego@jrc.ec.europa.eu>> 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.
>>
Received on Friday, 3 January 2014 10:49:24 UTC