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. -------------------------------------------------------
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev