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

Mon Apr 10 06:06:55 PDT 2017

Hi,
sorry I lost track of the subject. So, to close up, and approach where the
envelope is reported as "lat lon" and the "i j" raster space
axis would map pairwise, so i pointing north-wards and j east-wards, would
be considered valid?
E.g., if one rescaling says "i is going to be 200 pixels" it really means
the output image will be 200 pixels tall?

Cheers
Andrea

On Wed, Apr 5, 2017 at 8:17 PM, Peter Baumann <
p.baumann at jacobs-university.de> wrote:

>
>
> 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> 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.ne
>> t/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:
>
> [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,
>
>
> 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 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39  339 8844549 <+39%20339%20884%204549>
>
> 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 <+49%20421%202003178>, fax: +49-421-200-493178 <+49%20421%20200493178>
>  - 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 <+49%20173%205837882>
> "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)
>
>
>
>

-- 
==
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.

-------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170410/df76d4a6/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/20170410/df76d4a6/attachment-0001.png>