Re: UCR issue: phrasing of CRS requirement(s)

I definitely agree that http://www.w3.org/2003/01/geo/wgs84_pos breaks 
down as we go beyond point data, which is one reason that we need a 
literal encoding for geometries. In addition, from a SPARQL query 
perspective, we really need a literal encoding to make spatial query 
functions feasible. This way, a single literal argument covers all cases.

GeoSPARQL defines both a gmlLiteral and wktLiteral. GML is fully 
self-describing with CRS info, so we incorporated the CRS URI into the 
wktLiteral encoding so that it would be self-describing as well for 
consistency with gmlLiteral.

Cheers,
Matt


On 5/21/2015 11:11 AM, Andrea Perego wrote:
> On Thu, May 21, 2015 at 5:05 PM, Svensson, Lars <L.Svensson@dnb.de> wrote:
>> Kerry,
>>
>> On Thursday, May 21, 2015 4:23 PM Kerry.Taylor@csiro.au wrote:
>>
>>> RE axis order,
>>> I know there is a great deal of frustrated experience  and errors with this.
>>> The thing is, with ontologies like Raphael's and with "linked data" (I mean RDF
>>> instance data in any of its forms, including JSON-LD),
>>> normally ordering is irrelevant as a description for each value is provided
>>> (commonly called "self describing'). E.G.  Have a look at "geo" I pointed at
>>> before. http://www.w3.org/2003/01/geo/wgs84_pos
>> wgs84_pos et al. are fine as long as you just deal with point coordinates. As soon as you start talking about bounding boxes etc. it turns _way_ more complicated. Even in simple settings we need to describe more than points.
> I agree with Lars. The approach used in the WGS86 lat/long vocabulary
> is not scalable for complex geometries. And, in any case, many people
> will keep using literals. BTW, schema.org uses literals for "shapes"
> (http://schema.org/GeoShape) and longitude, latitude, and elevation
> for points (http://schema.org/GeoCoordinates).
>
> For this reason, it would be useful to find a way to make explicit the
> axis order used in geometry literals (as in the example provided by
> Peter), without the need of processing the corresponding CRS
> description.
>
> I also think that the axis order issue is very much related to the
> notion of "spatial" data as we are using it (i.e., not only
> geo-spatial data). Non-geo people will keep on reading coordinates as
> lon / lat, because this is the order used in a cartesian reference
> system, and this is also the order used by communities dealing with
> spatial data (e.g., computer graphics).
>
> A possible option would be to require the specification of the axis
> order only is it is lat / lon (lon / lat), implying that the default
> should be lon / lat (lat / lon).
>
> Andrea
>

Received on Thursday, 21 May 2015 16:00:57 UTC