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

Andrea Aime andrea.aime at geo-solutions.it
Wed Apr 5 05:16:00 PDT 2017

On Tue, Apr 4, 2017 at 12:24 PM, Peter Baumann <
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.
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">
<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">

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?

> 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:

[image: 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, 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?
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?


GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
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



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.

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

More information about the gdal-dev mailing list