Hi Andrea,
On 04/10/2017 03:06 PM, Andrea Aime wrote:
> 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?
indeed.
> E.g., if one rescaling says "i is going to be 200 pixels" it really means the
> output image will be 200 pixels tall?
that's the intention, but disclaimer: if you want to look at scaling in
particular please have a look at the WCS Scaling Extension for the gory details.
HTH,
Peter
>
> Cheers
> Andrea
>
>
> On Wed, Apr 5, 2017 at 8:17 PM, Peter Baumann <p.baum...@jacobs-university.de
> <mailto:p.baum...@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.baum...@jacobs-university.de <mailto: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.
>
> 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
>> <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
>> <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
>> <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
>> <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 <tel:+39%200584%20962313>
>> fax: +39 0584 1660272 <tel:+39%200584%20166%200272>
>> mob: +39 339 8844549 <tel:+39%20339%20884%204549>
>>
>> http://www.geo-solutions.it
>> http://twitter.com/geosolutions_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
> <http://www.faculty.jacobs-university.de/pbaumann>
> mail: p.baum...@jacobs-university.de
> <mailto:p.baum...@jacobs-university.de>
> tel: +49-421-200-3178 <tel:+49%20421%202003178>, fax:
> +49-421-200-493178 <tel:+49%20421%20200493178>
> - Executive Director, rasdaman GmbH Bremen (HRB 26793)
> www.rasdaman.com <http://www.rasdaman.com>, mail: baum...@rasdaman.com
> <mailto:baum...@rasdaman.com>
> tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
> <tel:+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.
>
> -------------------------------------------------------
--
Dr. Peter Baumann
- Professor of Computer Science, Jacobs University Bremen
www.faculty.jacobs-university.de/pbaumann
mail: p.baum...@jacobs-university.de
tel: +49-421-200-3178, fax: +49-421-200-493178
- Executive Director, rasdaman GmbH Bremen (HRB 26793)
www.rasdaman.com, mail: baum...@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)
------------------------------------------------------------------------------
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
