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

"Truth in advertising" is the main concern. 
This is where the community usually represented by OGC will not compromise. 
If you claim to be using EPSG 4326, but then put coordinates in lon,lat order, then the document is inconsistent, and the traditional industrial users will throw up their hands and go elsewhere. 
If we want to include that community we have to respect that. 

GeoJSON insists that coords are always (x,y) (i.e. lon,lat) regardless of whether that is consistent with the CRS referenced. 
Some GeoJSON data is therefore inconsistent. 
And GeoJSON has quite a lot of momentum in some parts of the community. 
We recently worked with the GeoJSON editors to clarify this. 
They recognise the potential confusion and in the IETF draft of GeoJSON the original CRS treatment is deprecated. 
But (say it again) in GeoJSON coords are always (x,y), which is what the general web developers expect, even if it is inconsistent with historic practice in the geodetic/cartographic community. 

My view is that GeoJSON provides a significant installed base that we should attempt to leverage as much as possible. 
But also that we must be careful, and if CRS references are ever associated with GeoJSON representations, they must use right-handed coordinate systems. 

Following this thread, I can see the case for having an RDF interface to some key elements of CRS descriptions (e.g. coordinate order) but for the reasons previously explained we should carefully limit this and not get sucked into a comprehensive CRS description ontology. Perhaps 

:uses-right-handed-coordinate-system	a 		owl:DatatypeProperty ;
					rdfs:domain 	:CRS ;
					rdfs:range  	xsd:Boolean . 

would be enough? 

-----Original Message-----
From: Andrea Perego [mailto:andrea.perego@jrc.ec.europa.eu] 
Sent: Friday, 22 May 2015 1:12 AM
To: Svensson, Lars
Cc: Taylor, Kerry (Digital, Acton); janowicz@ucsb.edu; Cox, Simon (L&W, Highett); raphael.troncy@eurecom.fr; eparsons@google.com; public-sdw-wg@w3.org
Subject: 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

Received on Friday, 22 May 2015 00:23:13 UTC