[gdal-dev] GML lat-lon coverages and interoperability

Wed Apr 5 11:17:11 PDT 2017

On 04/05/2017 02:16 PM, Andrea Aime wrote:
> On Tue, Apr 4, 2017 at 12:24 PM, Peter Baumann <p.baumann at jacobs-university.de
> <mailto:p.baumann at jacobs-university.de>> wrote:
>
>     To avoid the problems that other standards have with axis order, coverages
>     contain the axis order explicitly, in the axisLabels attribute. Here an
>     example:
>
>
>             <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326"
>     <http://www.opengis.net/def/crs/EPSG/0/4326> *axisLabels="Lat Long"*
>     uomLabels="deg deg" srsDimension="2">
>                 <gml:lowerCorner>1 1</gml:lowerCorner>
>                 <gml:upperCorner>3 10</gml:upperCorner>
>             </gml:Envelope>
>
>     The sequence in axisLabels is indicative.
>
>
> I'm looking at the WCS 2.0.1 core spec, all it says about the labels is:
>
> "The attribute axisLabels is an ordered list of labels for all the axes of
> this CRS". Label is a generic term, I don't see any dictionary giving meaning
> to the labels.

srsName and axisLabels are inherited from GML 3.2.1 which says (cf comment in
geometryBasic0d1d.xsd):
"The attribute axisLabels is an ordered list of labels for all the axes of this
CRS. The gml:axisAbbrev value should be used for these axis labels, after spaces
and forbidden characters are removed. When the srsName attribute is included,
this attribute is optional. When the srsName attribute is omitted, this
attribute shall also be omitted."
In GMLCOV/CIS axisLabels is mandatory.

Purpose is to associate the EPSG CRS axes with the axes as used in the XML
document in a machine readable manner, without the ambiguities of other standards.
In CIS 1.0 this is via axisAbbrev, so quite rigid. Following long and winding
discussions with EPSG this has been changed in CIS 1.1 so that your examples 3
and 4 are allowed as well (identification by position, not by name).

> So the following should all be equivalent to the client, or not?
> <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326"
> axisLabels="Lat Long" uomLabels="deg deg" srsDimension="2">

correct as per EPSG:4326

> <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326"
> axisLabels="a b" uomLabels="deg deg" srsDimension="2">
> <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326"
> axisLabels="foo bar" uomLabels="deg deg" srsDimension="2">
> <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326"
> axisLabels="Long Lat" uomLabels="deg deg" srsDimension="2">

all these are wrong in CIS 1.0, you _must_ use the axisAbbrev element. In CIS
1.1 ok, although the last one is misleading.

>
> I added the last on purpose, since they are just labels, they really carry no
> meaning, and the axis order is still determined by the srsName instead (thus,
> lat long).
> Or not?

srsName and axisLabels are inherited from GML 3.2.1 which says (cf comment in
geometryBasic0d1d.xsd):
"The attribute axisLabels is an ordered list of labels for all the axes of this
CRS. The gml:axisAbbrev value should be used for these axis labels, after spaces
and forbidden characters are removed. When the srsName attribute is included,
this attribute is optional. When the srsName attribute is omitted, this
attribute shall also be omitted."
In GMLCOV/CIS axisLabels is mandatory.

>  
>
>     So it is not necessary to use GridFunctions for this purpose. My personal
>     opinion is that such mechanisms are not optimal for fiddling with
>     coordinate positions as they make it unnecessarily difficult to determine
>     the final pixel position. This seems to be the case here as well.
>
>
> The function is there because we could not stomach the idea that "i j" in
> raster space would be associated to up and right (in this order), geographic
> coordinates systems have their own madness (or at least OGC wants us to
> believe that) but we hoped the raster space wouldn't be touched. If we remove
> the function, keep the lat/lon orientation for the envelope, and assume
> pairwise matching like Jukka suggests, then this is our raster (aka pixel) space:
>
> Inline image 2 
> It can work of course.
>
> Then, since you are here, a question about the axis order of the returned
> coverages (let's assume geotiff for simplificity's sake). I am presuming some
> uniformity across OGC standards,

that is the Holy Grail. In practice, groups work individually (which is somehow
understandable - it's all voluntary effort, although not desirable - I have
brought it to the doors of OGC many times that a centralized point of
coordination on the basics would be advantageous; that point could be OWS Common
which is under revision since some time - not sure what this will mean in
practice).

> so if vector data in WGS84 is to be returned in lat/lon order, does it makes
> sense to return also coverages in the same order?

as we seem to have EPSG as common ground, yes.

> Projection unaware software displays vector data flipped when returned by a
> compliant WFS 1.1 server... shouldn't it happen the same for WCS 2.0? Or
> should rasters be considered somehow blessed and outside of this issue?

I am always for harmonization (principle of least surprise in Software
Engineering), but you will find wildly varying opinions on this :)

HTH,
Peter

>
> Cheers
> Andrea
>
> -- 
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime 
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i
> file/s allegato/i sono da considerarsi strettamente riservate. Il loro
> utilizzo è consentito esclusivamente al destinatario del messaggio, per le
> finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio
> senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia
> via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo
> dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte,
> distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse,
> costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
>
>  
>
> The information in this message and/or attachments, is intended solely for the
> attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act (Legislative
> Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not
> in accord with its purpose, any disclosure, reproduction, copying,
> distribution, or either dissemination, either whole or partial, is strictly
> forbidden except previous formal approval of the named addressee(s). If you
> are not the intended recipient, please contact immediately the sender by
> telephone, fax or e-mail and delete the information in this message that has
> been received in error. The sender does not give any warranty or accept
> liability as the content, accuracy or completeness of sent messages and
> accepts no responsibility  for changes made after they were sent or for other
> risks which arise as a result of e-mail transmission, viruses, etc.
>
>
> -------------------------------------------------------

-- 
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   www.faculty.jacobs-university.de/pbaumann
   mail: p.baumann at jacobs-university.de
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)
   www.rasdaman.com, mail: baumann at rasdaman.com
   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170405/82491f4d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 2567 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170405/82491f4d/attachment-0001.png>