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

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