On Tue, Apr 4, 2017 at 12:24 PM, Peter Baumann <
p.baum...@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?
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.
-------------------------------------------------------
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
