Hi Andrea,
What spec you are reading? All examples in OGC® Web Coverage Service Interface Standard - Scaling Extension are using the short format
…& SCALEFACTOR=2.0 &…
…& SCALEAXES=i(3.5),j(3.5),k(2.0) &…
…& SCALESIZE=i(1000),j(1000),k(10) &…
…& SCALEEXTENT=i(10:20),j(20:30) &…
or as XML
scal:axisi</scal:axis>
scal:targetSize1000</scal:targetSize>
</scal:TargetAxisSize>
scal:axisj</scal:axis>
scal:targetSize1000</scal:targetSize>
</scal:TargetAxisSize>
scal:axisk</scal:axis>
scal:targetSize10</scal:targetSize>
</scal:TargetAxisSize>
</scal:ScaleToSize>
However, examples are missing reference to how the axis are presented in DescribeCoverage.
The this discussion that I found from the web is in https://groups.google.com/forum/#!msg/rasdaman-users/SBA2SrVapHo/J8POkUVy-iwJ Piero Campanali writes:
However (again), in your examples where scaling is involved, you are going to
target GRID axis, so you shouldn’t really bother about URI identifiers because
GRID axis labels are just arbitrary names: you just should pick what is declared
in the domainSet.
…
Eventually, assuming your GRID labels are “i j” and “Lat Long” the CRS ones,
what I believe would be correct in the WCS scaling requests is:
:: ScaleFactor=2.0
:: ScaleAxesByFactor=i(2),j(2)
:: ScaleSize=i(1000),j(1000)
:: ScaleExtent=Lat(10,20),Long(20,30)
[or even URI identifiers of Lat and Long]
So Piero believes that ScaleAxesByFactor and ScaleSize should never need anything else than the GRID labels which are used in DescribeCoverage, while ScaleExtent might use either CRS axis labels as used in DescribeCoverage, or URI identifier.
Thinking again about this example in the scaling standard:
…& SCALEEXTENT=i(10:20),j(20:30) &…
If axis in SCALEEXTENT are the CRS axis, then the example feels wrong because at least i and j are not the most common CRS axis labels.
-Jukka Rahkonen-
Lähettäjä: andrea.aime@…403… [mailto:andrea.aime@…403…] Puolesta Andrea Aime
Lähetetty: 22. maaliskuuta 2017 9:41
Vastaanottaja: Rahkonen Jukka (MML) <jukka.rahkonen@…4189…>
Kopio: Geoserver-devel geoserver-devel@lists.sourceforge.net
Aihe: Re: [Geoserver-devel] WCS 2.0.1 with SCALESIZE [SOLVED]
···
Hi Jukka,
that is actually not clear to me, the examples in the spec that I could find are all using the long format, but I could
not find a specific rule for axis names, or how the labels reported in DescribeCoverage output relate to the
IDs used in requests, since the former always uses short names in the spec, and the latter uses long URI
like ones instead (see the scaling extension).
I am not opposed to also recognize a shorter format, could be one of those "GeoServer not quite fully standard
but handy" relaxed interpretations of the protocol. Or you could just be that the specification it’s inconsistent,
it would make a lot of sense imho if the labels reported in DescribeCoverage had to be used as-is
in GetCovearge.
Cheers
Andrea
On Tue, Mar 21, 2017 at 10:04 PM, Rahkonen Jukka (MML) <jukka.rahkonen@…4189…> wrote:
All right, the SCALESIZE axis are output grid axes which are named as i and j in DescribeCoverage
gml:axisLabels>i j</gml:axisLabels
So the E and N which are used for subset are wrong for SCALESIZEAnother thing is that i and j can’t be used as it but they require URI for the axis. So this is a working query:
Now I wonder if it is necessary and useful to require that long format for axis names. The KVP examples in the Scaling Extension standard are using this short and more human-writable syntax:
…& SCALESIZE=i(1000),j(1000),k(10) &…-Jukka-
Lähettäjä: Rahkonen Jukka (MML)
Lähetetty: 21. maaliskuuta 2017 20:03
Vastaanottaja: ‘Geoserver-devel’
Aihe: [Geoserver-devel] WCS 2.0.1 with SCALESIZEHi,
Is there something wrong with this GetCoverage?
localhost:8080/geoserver/wcs?service=WCS&version=2.0.1&request=GetCoverage&coverageID=sf__sfdem&SUBSET=E(589980,590000)&SUBSET=N(4913700,4923700)&SCALESIZE=E(200),N(200)
The error from GeoServer 2.11-RC1 is
“ScaleAxisUndefined” locator=“E”>-Jukka Rahkonen-
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
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
–
==
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://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.
