[gdal-dev] WCS GetCoverage with AxisOrder swap

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] WCS GetCoverage with AxisOrder swap

Ari Jolma-2
I've got to the point in the new WCS driver development, where I'm
trying to issue GetCoverage request to a GeoServer, which is serving
data in EPSG that has axis order swapped.

This is related to the earlier discussion

https://lists.osgeo.org/pipermail/gdal-dev/2017-April/046366.html

The data serving is at

https://msp.smartsea.fmi.fi/geoserver/wcs?SERVICE=WCS&REQUEST=DescribeCoverage&VERSION=2.0.1&COVERAGEID=smartsea__eusm2016-EPSG2393

The boundedBy tells that the axisLabels are "Y X" and the lower corner
is "6543350.381089335 3061592.6391462097" and upper corner is
"7307056.899896299 3432141.361396798". This makes sense, in that EPSG X
(easting) runs up from 3000000 and Y (northing) runs up from 6500000.

What I don't understand is why I need to make the GetCoverage request
with subset=Y(3061592,3061632) and subset=X(7307016,7307056). If I
define them as I would expect

https://msp.smartsea.fmi.fi/geoserver/wcs?SERVICE=WCS&REQUEST=GetCoverage&VERSION=2.0.1&COVERAGEID=smartsea__eusm2016-EPSG2393&FORMAT=image%2Ftiff&SUBSET=X%283061592.63914621,3061632.65520693%29&SUBSET=Y%287307016.88383558,7307056.8998963%29

I get "Empty intersection after subsetting".

A MapServer that serves data with EPSG that has axis order swapped is at

http://194.66.252.155/cgi-bin/BGS_EMODnet_bathymetry/ows?SERVICE=WCS&REQUEST=DescribeCoverage&version=2.0.1&coverageid=BGS_EMODNET_CentralMed-MCol

It works using the above logic. However, it does not have GridFunction,
which GeoServer has (it is "+2 +1", i.e., the data is east first, then
north).

and Rasdaman server at

http://ows.rasdaman.org/rasdaman/ows?SERVICE=WCS&REQUEST=DescribeCoverage&VERSION=2.0.1&COVERAGEID=BlueMarbleCov

Works using the above logic. However, it *has* GridFunction, which is
the same as GeoServer has. However, it has the order of offsetVectors
swapped - which I think is correct (as is also written here
https://lists.osgeo.org/pipermail/gdal-dev/2017-April/046421.html)

So, I can make Rasdaman work for CRS with swapped order by default (also
the returned geotiff is ok), and for MapServer and GeoServer I need to
have at least two hack options (NoOffsetSwap and NoGridEnvelopeSwap,
maybe there could be only one). I have not yet checked if the rasters
returned from those two are ok.

Ari




_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS GetCoverage with AxisOrder swap

Ari Jolma-2
Ari Jolma kirjoitti 08.11.2017 klo 13:48:
>  for MapServer and GeoServer I need to have at least two hack options
> (NoOffsetSwap and NoGridEnvelopeSwap, maybe there could be only one).
> I have not yet checked if the rasters returned from those two are ok.

The rasters that those servers return are ok. I just need the one
additional hack option for GeoServer to swap the axis names for the
GetCoverage request.

I also don't need to use the GridFunction information.

BTW, it seems that GDAL driver options are usually all upcase. Is that
just a convention, and could it perhaps be violated? The reason for
options like "PreferredFormat=xxx" for the WCS driver (instead of
"PREFERREDFORMAT=xxx") is that 'PreferredFormat' is the name of the
element in the WCS_GDAL XML. My approach in the new WCS driver is to use
options to set values in the WCS_GDAL XML since that XML file is in the
cache and meant to be maintained by the driver.

Ari

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS GetCoverage with AxisOrder swap

Even Rouault-2

On mercredi 8 novembre 2017 14:50:54 CET Ari Jolma wrote:

> Ari Jolma kirjoitti 08.11.2017 klo 13:48:

> >  for MapServer and GeoServer I need to have at least two hack options

> > (NoOffsetSwap and NoGridEnvelopeSwap, maybe there could be only one).

> > I have not yet checked if the rasters returned from those two are ok.

>

> The rasters that those servers return are ok. I just need the one

> additional hack option for GeoServer to swap the axis names for the

> GetCoverage request.

>

> I also don't need to use the GridFunction information.

 

One thing that is confusing, and rings some bells to me as I saw that with GMLJP2 (the

GDAL_JP2K_ALT_OFFSETVECTOR_ORDER config option in gdaljp2metadata.cpp) is the order of the offetVector element

 

From your example, we have:

 

MapServer:

<gml:offsetVector srsName="http://www.opengis.net/def/crs/EPSG/0/4326">0 0.004167</gml:offsetVector>

<gml:offsetVector srsName="http://www.opengis.net/def/crs/EPSG/0/4326">-0.004167 0</gml:offsetVector>

 

GeoServer:

<gml:offsetVector srsName="http://www.opengis.net/def/crs/EPSG/0/2393">0.0 20.00803035910304</gml:offsetVector>

<gml:offsetVector srsName="http://www.opengis.net/def/crs/EPSG/0/2393">-20.00803035910304 0.0</gml:offsetVector>

 

Rasdaman

<offsetVector srsName="http://ows.rasdaman.org/def/crs/EPSG/0/4326">-0.02 0</offsetVector>

<offsetVector srsName="http://ows.rasdaman.org/def/crs/EPSG/0/4326">0 0.02</offsetVector>

 

So in all 3 cases, the order of the value *inside* a offetVector element is lat/northing long/easting as those CRS as lat-long / northing-easting. OK

 

BUT Rasdaman does an extra swap of the offsetVector elements themselves.

 

What is not clear (among many things) is when GridFunction applies. If it applies before linking the raster/grid space to the georeferenced space,

that is the first offsetVector applies to the fastest varying dimension of the final grid,

then I'd say MapServer & GeoServer do the right thing (GeoServer probably closer to correctenss, due to te

presence of the GridFunction). Otherwise, if its applied at the very end of the process, Rasdaman is probably correct.

 

Practically I'd say if you have

<offsetVector srsName="...">A B</offsetVector>

<offsetVector srsName="...">C D</offsetVector>

with SRS with lat-long or northing-easting order, with high confidence regarding how "correct" an implementation is:

* if A != 0 and D > 0 and C=B=0, D the x resolution and A is the y resolution .

* if A=D=0 and C != 0 and B > 0, then B is the x resolution and C the y resolution.

In other situations, good luck...

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS GetCoverage with AxisOrder swap

jratike80
Even Rouault-2 wrote
> On mercredi 8 novembre 2017 14:50:54 CET Ari Jolma wrote:
>> Ari Jolma kirjoitti 08.11.2017 klo 13:48:
>> >  for MapServer and GeoServer I need to have at least two hack options
>> > (NoOffsetSwap and NoGridEnvelopeSwap, maybe there could be only one).
>> > I have not yet checked if the rasters returned from those two are ok.

Hi,

I fear that we are going in circles, see this not-so-old thread
http://osgeo-org.1560.x6.nabble.com/gdal-dev-GML-lat-lon-coverages-and-interoperability-td5315441.html

I wonder if we should open a new wiki page for the discussion about WCS 2.0
axis order and if we should define swapped axis by using
GridFunction-axisOrder="+2 +1">Linear which means "take the second number
and increase the first offset vector with it, then take the second number
and increase the first axes", or by writing the offset vectors as "first
number is moving me from top to down, the second number from left to right".

I got an impression that in that thread seven months ago the offset vector
solution without using GridFunction was more or less recommended by Dr.
Baumann at least for easy coverages like aerial images. I would like that
too because then client software would not need to know what are
GridFunctions, just to read the offset vectors right.

I also wonder that if client is supposed to handle axisOrder="+2 +1">linear,
should it then be able to handle also everything else that is defined on
page 223 of 437 of the GML 3.2.1 standard in chapter "19.3.14 sequenceRule,
SequenceRuleType, SequenceRuleEnumeration"


-Jukka Rahkonen-







--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS GetCoverage with AxisOrder swap

Piero Campa
In reply to this post by Ari Jolma-2
Hi there,

The gml:GridFunction is *not* an auxiliary definition of the grid geometry, but rather a guidance on how to link the grid to the *range set* (i.e. the data), so it shall not be compared with the "domain" information (offset vectors and so on).

As Even properly underlines, the order of the coordinates in the offset vectors shall refer to the order of the CRS axis definition, that is (concerning EPSG:4326) the first coordinate/number is the latitude, the second is the longitude (with proper -/+ sign whether the COVERAGE axis attached to the vector is concordant/discordant with the CRS axis direction).

The order of the offset-vectors themselves refers to the order of the GRID axes (the pic in [1] might be helpful decoding the XML of it all!).
This order is what can be referred to in the GridFunction: +1 --> first GRID axis, +2 --> second GRID axis, etc.

For instance, what rasdaman seems to tell on the coverage is the the first 9000-points COVERAGE axis is the vertical axis, increasing South-ward, while the second 18000-points axis follows the East direction.
Via GridFunction, it then says then that the data you will get in a WCS GetCoverage response will span the 2nd (horizontal) axis first.

hth!
-Piero

On 8 November 2017 at 14:42, <[hidden email]> wrote:
Message: 3
Date: Wed, 8 Nov 2017 13:48:49 +0200
From: Ari Jolma <[hidden email]>
To: "'[hidden email]' ([hidden email])"
        <[hidden email]>
Subject: [gdal-dev] WCS GetCoverage with AxisOrder swap
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8; format=flowed

I've got to the point in the new WCS driver development, where I'm
trying to issue GetCoverage request to a GeoServer, which is serving
data in EPSG that has axis order swapped.

This is related to the earlier discussion

https://lists.osgeo.org/pipermail/gdal-dev/2017-April/046366.html

The data serving is at

https://msp.smartsea.fmi.fi/geoserver/wcs?SERVICE=WCS&REQUEST=DescribeCoverage&VERSION=2.0.1&COVERAGEID=smartsea__eusm2016-EPSG2393

The boundedBy tells that the axisLabels are "Y X" and the lower corner
is "6543350.381089335 3061592.6391462097" and upper corner is
"7307056.899896299 3432141.361396798". This makes sense, in that EPSG X
(easting) runs up from 3000000 and Y (northing) runs up from 6500000.

What I don't understand is why I need to make the GetCoverage request
with subset=Y(3061592,3061632) and subset=X(7307016,7307056). If I
define them as I would expect

https://msp.smartsea.fmi.fi/geoserver/wcs?SERVICE=WCS&REQUEST=GetCoverage&VERSION=2.0.1&COVERAGEID=smartsea__eusm2016-EPSG2393&FORMAT=image%2Ftiff&SUBSET=X%283061592.63914621,3061632.65520693%29&SUBSET=Y%287307016.88383558,7307056.8998963%29

I get "Empty intersection after subsetting".

A MapServer that serves data with EPSG that has axis order swapped is at

http://194.66.252.155/cgi-bin/BGS_EMODnet_bathymetry/ows?SERVICE=WCS&REQUEST=DescribeCoverage&version=2.0.1&coverageid=BGS_EMODNET_CentralMed-MCol

It works using the above logic. However, it does not have GridFunction,
which GeoServer has (it is "+2 +1", i.e., the data is east first, then
north).

and Rasdaman server at
​​


http://ows.rasdaman.org/rasdaa32c78aman/ows?SERVICE=WCS&REQUEST=DescribeCoverage&VERSION=2.0.1&COVERAGEID=BlueMarbleCov

Works using the above logic. However, it *has* GridFunction, which is
the same as GeoServer has. However, it has the order of offsetVectors
swapped - which I think is correct (as is also written here
https://lists.osgeo.org/pipermail/gdal-dev/2017-April/046421.html)

So, I can make Rasdaman work for CRS with swapped order by default (also
the returned geotiff is ok), and for MapServer and GeoServer I need to
have at least two hack options (NoOffsetSwap and NoGridEnvelopeSwap,
maybe there could be only one). I have not yet checked if the rasters
returned from those two are ok.

Ari






------------------------------

Message: 4
Date: Wed, 8 Nov 2017 14:50:54 +0200
From: Ari Jolma <[hidden email]>
To: "'[hidden email]' ([hidden email])"
        <[hidden email]>
Subject: Re: [gdal-dev] WCS GetCoverage with AxisOrder swap
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8; format=flowed

Ari Jolma kirjoitti 08.11.2017 klo 13:48:
>  for MapServer and GeoServer I need to have at least two hack options
> (NoOffsetSwap and NoGridEnvelopeSwap, maybe there could be only one).
> I have not yet checked if the rasters returned from those two are ok.

The rasters that those servers return are ok. I just need the one
additional hack option for GeoServer to swap the axis names for the
GetCoverage request.

I also don't need to use the GridFunction information.

BTW, it seems that GDAL driver options are usually all upcase. Is that
just a convention, and could it perhaps be violated? The reason for
options like "PreferredFormat=xxx" for the WCS driver (instead of
"PREFERREDFORMAT=xxx") is that 'PreferredFormat' is the name of the
element in the WCS_GDAL XML. My approach in the new WCS driver is to use
options to set values in the WCS_GDAL XML since that XML file is in the
cache and meant to be maintained by the driver.

Ari



------------------------------

Message: 5
Date: Wed, 08 Nov 2017 14:42:51 +0100
From: Even Rouault <[hidden email]>
To: [hidden email]
Subject: Re: [gdal-dev] WCS GetCoverage with AxisOrder swap
Message-ID: <2058494.1KC9oNcdcJ@even-i700>
Content-Type: text/plain; charset="iso-8859-1"

On mercredi 8 novembre 2017 14:50:54 CET Ari Jolma wrote:
> Ari Jolma kirjoitti 08.11.2017 klo 13:48:
> >  for MapServer and GeoServer I need to have at least two hack options
> > (NoOffsetSwap and NoGridEnvelopeSwap, maybe there could be only one).
> > I have not yet checked if the rasters returned from those two are ok.
>
> The rasters that those servers return are ok. I just need the one
> additional hack option for GeoServer to swap the axis names for the
> GetCoverage request.
>
> I also don't need to use the GridFunction information.

One thing that is confusing, and rings some bells to me as I saw that with GMLJP2 (the
GDAL_JP2K_ALT_OFFSETVECTOR_ORDER config option in gdaljp2metadata.cpp) is the order of the offetVector element

>From your example, we have:

MapServer:
<gml:offsetVector srsName="http://www.opengis.net/def/crs/EPSG/0/4326">0 0.004167</gml:offsetVector>
<gml:offsetVector srsName="http://www.opengis.net/def/crs/EPSG/0/4326">-0.004167 0</gml:offsetVector>

GeoServer:
<gml:offsetVector srsName="http://www.opengis.net/def/crs/EPSG/0/2393">0.0 20.00803035910304</gml:offsetVector>
<gml:offsetVector srsName="http://www.opengis.net/def/crs/EPSG/0/2393">-20.00803035910304 0.0</gml:offsetVector>

Rasdaman
<offsetVector srsName="http://ows.rasdaman.org/def/crs/EPSG/0/4326">-0.02 0</offsetVector>
<offsetVector srsName="http://ows.rasdaman.org/def/crs/EPSG/0/4326">0 0.02</offsetVector>

So in all 3 cases, the order of the value *inside* a offetVector element is lat/northing long/easting as those CRS as lat-long / northing-easting. OK

BUT Rasdaman does an extra swap of the offsetVector elements themselves.

What is not clear (among many things) is when GridFunction applies. If it applies before linking the raster/grid space to the georeferenced space,
that is the first offsetVector applies to the fastest varying dimension of the final grid,
then I'd say MapServer & GeoServer do the right thing (GeoServer probably closer to correctenss, due to te
presence of the GridFunction). Otherwise, if its applied at the very end of the process, Rasdaman is probably correct.

Practically I'd say if you have
<offsetVector srsName="...">A B</offsetVector>
<offsetVector srsName="...">C D</offsetVector>
with SRS with lat-long or northing-easting order, with high confidence regarding how "correct" an implementation is:
 * if A != 0 and D > 0 and C=B=0, D the x resolution and A is the y resolution .
 * if A=D=0 and C != 0 and B > 0, then B is the x resolution and C the y resolution.
In other situations, good luck...

--
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20171108/9a786fbe/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

------------------------------

End of gdal-dev Digest, Vol 162, Issue 22
*****************************************


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS GetCoverage with AxisOrder swap

Even Rouault-2

On mercredi 8 novembre 2017 15:50:48 CET Piero Campalani wrote:

> Hi there,

>

> The gml:GridFunction is *not* an auxiliary definition of the grid geometry,

> but rather a guidance on how to link the grid to the *range set* (i.e. the

> data), so it shall not be compared with the "domain" information (offset

> vectors and so on).

>

> As Even properly underlines, the order of the coordinates in the offset

> vectors shall refer to the order of the CRS axis definition, that is

> (concerning EPSG:4326) the first coordinate/number is the latitude, the

> second is the longitude (with proper -/+ sign whether the COVERAGE axis

> attached to the vector is concordant/discordant with the CRS axis

> direction).

>

> The order of the offset-vectors themselves refers to the order of the GRID

> axes (the pic in [1] might be helpful decoding the XML of it all!).

> This order is what can be referred to in the GridFunction: +1 --> first

> GRID axis, +2 --> second GRID axis, etc.

>

> For instance, what rasdaman seems to tell on the coverage is the the first

> 9000-points COVERAGE axis is the vertical axis, increasing South-ward,

> while the second 18000-points axis follows the East direction.

> Via GridFunction, it then says then that the data you will get in a WCS

> GetCoverage response will span the 2nd (horizontal) axis first.

 

OK thanks for the explanations. Makes some sense....

So it would seem that if you want to return a GeoTIFF in

traditional GIS order (ie faster varying dimension corresponds to longitude), AND you emit

offsetVector in the way Rasdaman does, it seems

that emitting a gml:GridFunction +2 +1 would be required.

 

But actually, looking closely at the drawing at

http://rasdaman.org/wiki/PetascopeUserGuide#GridaxislabelsandCRSaxislabels , I see

RectifiedGrid.axisLabels="t Long Lat", whereas RectifiedGrid.origin.Point@axisLabels="t Lat Long"

(note the inversion). The second offset vector expressed an increase in longitude (0 0 0.5), while the

third one a decrease in latitude (0 -0.5 0). Which is the GIS friendly order.

 

So, it would seem that there are 2 more or less equivalent way of achieving the same end result ?

 

And thus MapServer output at

http://194.66.252.155/cgi-bin/BGS_EMODnet_bathymetry/ows?SERVICE=WCS&REQUEST=DescribeCoverage&version=2.0.1&coverageid=BGS_EMODNET_CentralMed-MCol

could probably be correct, but it would be better for RectifiedGrid.axisLabels to be changed to "long lat" to better

reflect what is done.

Rasdaman output at http://ows.rasdaman.org/rasdaman/ows?SERVICE=WCS&REQUEST=DescribeCoverage&VERSION=2.0.1&COVERAGEID=BlueMarbleCov would be correct

And GeoServer output at https://msp.smartsea.fmi.fi/geoserver/wcs?SERVICE=WCS&REQUEST=DescribeCoverage&VERSION=2.0.1&COVERAGEID=smartsea__eusm2016-EPSG2393

would either need to remove the GridFunction (ala MapServer) or keep it and invert the order in which its offsetVector appear (ala Rasdaman)

 

 

And for WCS subsetting, when you write something like SUBSET=AXIS_NAME(min,max),

where AXIS_NAME should come from ? From the RectifiedGrid.axisLabels I guess ?

(to be opposed to CoverageDescription.boundedBy.Envelope@axisLabels)

Then in Ari's test with GeoServer

https://msp.smartsea.fmi.fi/geoserver/wcs?SERVICE=WCS&REQUEST=DescribeCoverage&VERSION=2.0.1&COVERAGEID=smartsea__eusm2016-EPSG2393, in theory "i" and "j" should be the axis requested ?

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS GetCoverage with AxisOrder swap

jratike80
Even Rouault-2 wrote
> So, it would seem that there are 2 more or less equivalent way of
> achieving the same end result ?

My understanding is that these two are equivalent and define a grid in
EPSG:4326 with pixel size of 1 degree (if it is an image). First way is to
turn the offset vectors, this is also used in an example in the OGC GML in
JPEG 2000 (GMLJP2) standard.

offsetVector srsName="http://ows.rasdaman.org/def/crs/EPSG/0/4326">0
1</offsetVector
offsetVector srsName="http://ows.rasdaman.org/def/crs/EPSG/0/4326">-1
0</offsetVector

The second way is to turn the axes order.

&lt;GridFunction>
  <sequenceRule axisOrder="+2 +1">Linear</sequenceRule>
</GridFunction>
offsetVector srsName="http://ows.rasdaman.org/def/crs/EPSG/0/4326">-1
0</offsetVector
offsetVector srsName="http://ows.rasdaman.org/def/crs/EPSG/0/4326">0
1</offsetVector

It is also possible to write the first variant as complete so it is not
necessary to know what are the default values of sequenceRule

&lt;GridFunction>
  <sequenceRule axisOrder="+1 +2">Linear</sequenceRule>
</GridFunction>
offsetVector srsName="http://ows.rasdaman.org/def/crs/EPSG/0/4326">0
1</offsetVector
offsetVector srsName="http://ows.rasdaman.org/def/crs/EPSG/0/4326">-1
0</offsetVector


-Jukka Rahkonen-




--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS GetCoverage with AxisOrder swap

Ari Jolma-2
In reply to this post by Even Rouault-2

Even Rouault kirjoitti 08.11.2017 klo 17:31:

On mercredi 8 novembre 2017 15:50:48 CET Piero Campalani wrote:


> This order is what can be referred to in the GridFunction: +1 --> first

> GRID axis, +2 --> second GRID axis, etc.


Ok, this tells me that the axisOrder attribute in sequenceRule determines how to consider the GridEnvelope and the order of the offsetVectors in the Grid element.


 And thus MapServer output at

http://194.66.252.155/cgi-bin/BGS_EMODnet_bathymetry/ows?SERVICE=WCS&REQUEST=DescribeCoverage&version=2.0.1&coverageid=BGS_EMODNET_CentralMed-MCol

could probably be correct, but it would be better for RectifiedGrid.axisLabels to be changed to "long lat" to better

reflect what is done.


At least it fixes the driver for MapServer in this case (no hack options needed) since it does not define the axisOrder.

And GeoServer output at https://msp.smartsea.fmi.fi/geoserver/wcs?SERVICE=WCS&REQUEST=DescribeCoverage&VERSION=2.0.1&COVERAGEID=smartsea__eusm2016-EPSG2393

would either need to remove the GridFunction (ala MapServer) or keep it and invert the order in which its offsetVector appear (ala Rasdaman)


Invert the offsetVector order *and* invert the axis in GridEnvelope (otherwise the size is wrong).

 

 

And for WCS subsetting, when you write something like SUBSET=AXIS_NAME(min,max),

where AXIS_NAME should come from ? From the RectifiedGrid.axisLabels I guess ?

(to be opposed to CoverageDescription.boundedBy.Envelope@axisLabels)

Then in Ari's test with GeoServer

https://msp.smartsea.fmi.fi/geoserver/wcs?SERVICE=WCS&REQUEST=DescribeCoverage&VERSION=2.0.1&COVERAGEID=smartsea__eusm2016-EPSG2393, in theory "i" and "j" should be the axis requested ?


That does not work -- it's good that they are different since that shows it is not ok (invalid axis label error). Maybe the logic is related to the axis names? It's hard to tell since I don't find the logic in the GeoServer source code.

Ari


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS GetCoverage with AxisOrder swap

Peter Baumann


On 11/08/2017 10:01 PM, Ari Jolma wrote:

Even Rouault kirjoitti 08.11.2017 klo 17:31:

On mercredi 8 novembre 2017 15:50:48 CET Piero Campalani wrote:


> This order is what can be referred to in the GridFunction: +1 --> first

> GRID axis, +2 --> second GRID axis, etc.


Ok, this tells me that the axisOrder attribute in sequenceRule determines how to consider the GridEnvelope and the order of the offsetVectors in the Grid element.

the axisLabels attribute determines axis order, and this in turn refers to the CRS definition behind the URL in srsName.
SequenceRule / GridFunction is just for the internal linearization (whose description depends, ie: interprets axis order) - and BTW only applies to GML (and JSON and RDF), not necessarily to binary encodings which usually determine their own internal structure.

My team has analysed your report and says:

On 11/08/2017 02:56 PM, Bang Pham Huu wrote:

I checked the result as I think it is like this

+ GeoServer is correct with http://www.opengis.net/def/crs/EPSG/0/2393 as this one is X, Y so the offset vector is correct.

offsetVector1: X (positive), Y (negative)

offsetVector2: Y (negative), X (positive)

+ Rasdaman is also correct with http://ows.rasdaman.org/def/crs/EPSG/0/4326 (Lat, Long) so the offset vector is correct.

offsetVector1: Y (negative), X (positive)

offsetVector2: X (positive), Y (negative)

and with a CRS with X, Y order like http://www.opengis.net/def/crs/EPSG/0/3857, Rasdaman returns offset vector with correct order, e.g from a 2D coverage imported with this CRS:

<offsetVector srsName="http://localhost:8080/def/crs/EPSG/0/3857">23613.2868316 0</offsetVector>
<offsetVector srsName="http://localhost:8080/def/crs/EPSG/0/3857">0 -23613.2868316</offsetVector>

+ Mapserver is not correct for http://www.opengis.net/def/crs/EPSG/0/4326 (it should be as same as Rasdaman).




-Peter



 And thus MapServer output at

http://194.66.252.155/cgi-bin/BGS_EMODnet_bathymetry/ows?SERVICE=WCS&REQUEST=DescribeCoverage&version=2.0.1&coverageid=BGS_EMODNET_CentralMed-MCol

could probably be correct, but it would be better for RectifiedGrid.axisLabels to be changed to "long lat" to better

reflect what is done.


At least it fixes the driver for MapServer in this case (no hack options needed) since it does not define the axisOrder.

And GeoServer output at https://msp.smartsea.fmi.fi/geoserver/wcs?SERVICE=WCS&REQUEST=DescribeCoverage&VERSION=2.0.1&COVERAGEID=smartsea__eusm2016-EPSG2393

would either need to remove the GridFunction (ala MapServer) or keep it and invert the order in which its offsetVector appear (ala Rasdaman)


Invert the offsetVector order *and* invert the axis in GridEnvelope (otherwise the size is wrong).

 

 

And for WCS subsetting, when you write something like SUBSET=AXIS_NAME(min,max),

where AXIS_NAME should come from ? From the RectifiedGrid.axisLabels I guess ?

(to be opposed to CoverageDescription.boundedBy.Envelope@axisLabels)

Then in Ari's test with GeoServer

https://msp.smartsea.fmi.fi/geoserver/wcs?SERVICE=WCS&REQUEST=DescribeCoverage&VERSION=2.0.1&COVERAGEID=smartsea__eusm2016-EPSG2393, in theory "i" and "j" should be the axis requested ?


That does not work -- it's good that they are different since that shows it is not ok (invalid axis label error). Maybe the logic is related to the axis names? It's hard to tell since I don't find the logic in the GeoServer source code.

Ari



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   www.faculty.jacobs-university.de/pbaumann
   mail: [hidden email]
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)
   www.rasdaman.com, mail: [hidden email]
   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)



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS GetCoverage with AxisOrder swap

Even Rouault-2

Peter,

 

> the axisLabels attribute determines axis order, and this in turn refers to the

> CRS definition behind the URL in srsName.

 

Does the value of RectifiedGrid.axisLabels must be correlated with the one of the CRS,

or can it be a "random" value ?

For example, GeoServer has <gml:RectifiedGrid><gml:axisLabels>i j</gml:axisLabels></gml:RectifiedGrid>

 

> My team has analysed your report and says:

 

Thanks but I'm afraid I'm even more confused now.

 

>

> On 11/08/2017 02:56 PM, Bang Pham Huu wrote:

> > I checked the result as I think it is like this

> >

> > + GeoServer is correct with http://www.opengis.net/def/crs/EPSG/0/2393 as

> > this one is X, Y so the offset vector is correct.

 

In EPSG, http://www.opengis.net/def/axis/EPSG/0/48 = X = NORTH and

http://www.opengis.net/def/axis/EPSG/0/47 = Y = EAST. So this CRS has the "GIS-unfriendly" order.

 

But if you consider

<gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/2393" axisLabels="Y X" uomLabels="m m" srsDimension="2">

<gml:lowerCorner>6543350.381089335 3061592.6391462097</gml:lowerCorner>

<gml:upperCorner>7307056.899896299 3432141.361396798</gml:upperCorner></gml:Envelope>

 

and assume from the above that Y=EAST=6543350.381089335 and X=NORTH=3061592.6391462097 (lower corner values),

this doesn't transform to a location in Finland.

 

Whereas X=NORTH=6543350.381089335 and Y=EAST=3061592.6391462097 does transform to Finland

 

So I think the axisLabels here is wrong, it should be axisLabels="X Y"

 

 

> >

> > offsetVector1: X (positive), Y (negative)

> >

> > offsetVector2: Y (negative), X (positive)

 

Can't correlate the above reasoning about the sign of values with the actual output of

https://msp.smartsea.fmi.fi/geoserver/wcs?SERVICE=WCS&REQUEST=DescribeCoverage&VERSION=2.0.1&COVERAGEID=smartsea__eusm2016-EPSG2393

which is

<gml:offsetVector srsName="http://www.opengis.net/def/crs/EPSG/0/2393">0.0 20.00803035910304</gml:offsetVector>

<gml:offsetVector srsName="http://www.opengis.net/def/crs/EPSG/0/2393">-20.00803035910304 0.0</gml:offsetVector>

 

Given what you said about <gml:GridFunction> not applying to GeoTIFF output, then

this would be correct since the above would express that the first axis (along the width of the image) of the GeoTIFF

express positive easting space and the second axis (along height) express negative northing spacing (image north-up oriented)

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS GetCoverage with AxisOrder swap

jratike80
Even Rouault-2 wrote

> Peter,
>
>> the axisLabels attribute determines axis order, and this in turn refers
>> to the
>> CRS definition behind the URL in srsName.
>
> Does the value of RectifiedGrid.axisLabels must be correlated with the one
> of the CRS,
> or can it be a "random" value ?
> For example, GeoServer has
> <gml:RectifiedGrid>
> <gml:axisLabels>
> i j
> </gml:axisLabels>
> </gml:RectifiedGrid>
>> My team has analysed your report and says:
>
> Thanks but I'm afraid I'm even more confused now.
>
>>
>> On 11/08/2017 02:56 PM, Bang Pham Huu wrote:
>> > I checked the result as I think it is like this
>> >
>> > + GeoServer is correct with http://www.opengis.net/def/crs/EPSG/0/2393
>> as
>> > this one is X, Y so the offset vector is correct.
>
> In EPSG, http://www.opengis.net/def/axis/EPSG/0/48 = X = NORTH and
> http://www.opengis.net/def/axis/EPSG/0/47 = Y = EAST. So this CRS has the
> "GIS-unfriendly" order.
>
> But if you consider
> <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/2393"
> axisLabels="Y X" uomLabels="m m" srsDimension="2">
> <gml:lowerCorner>
> 6543350.381089335 3061592.6391462097
> </gml:lowerCorner>
> <gml:upperCorner>
> 7307056.899896299 3432141.361396798
> </gml:upperCorner>
> </gml:Envelope>
> and assume from the above that Y=EAST=6543350.381089335 and
> X=NORTH=3061592.6391462097 (lower corner values),
> this doesn't transform to a location in Finland.
>
> Whereas X=NORTH=6543350.381089335 and Y=EAST=3061592.6391462097 does
> transform to Finland
>
> So I think the axisLabels here is wrong, it should be axisLabels="X Y"
>
>
>> >
>> > offsetVector1: X (positive), Y (negative)
>> >
>> > offsetVector2: Y (negative), X (positive)
>
> Can't correlate the above reasoning about the sign of values with the
> actual output of
> https://msp.smartsea.fmi.fi/geoserver/wcs?SERVICE=WCS&REQUEST=DescribeCoverage&VERSION=2.0.1&COVERAGEID=smartsea__eusm2016-EPSG2393
> which is
> <gml:offsetVector srsName="http://www.opengis.net/def/crs/EPSG/0/2393">
> 0.0 20.00803035910304
> </gml:offsetVector>
> <gml:offsetVector srsName="http://www.opengis.net/def/crs/EPSG/0/2393">
> -20.00803035910304 0.0
> </gml:offsetVector>
> Given what you said about
> <gml:GridFunction>
>  not applying to GeoTIFF output, then
> this would be correct since the above would express that the first axis
> (along the width of the image) of the GeoTIFF
> express positive easting space and the second axis (along height) express
> negative northing spacing (image north-up oriented)
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>
> _______________________________________________
> gdal-dev mailing list

> gdal-dev@.osgeo

> https://lists.osgeo.org/mailman/listinfo/gdal-dev

Hi folks,

I think that it is extremely good to discuss about axisOrder, GridFunctions,
offsetVectors, axisLabels etc. because for sure we all want to build
interoperability between different WCS 2.0 implementations.
However, I think that this mailing list thread is rather making more
confusion than clarifying things. First, it is very hard to follow who wrote
what and when, and if that was an answer, then what was the question. And if
we make errors with our conclusions, or if we forget to think about all
aspects in out analyzes, it is very hard to clarify that on the mailing
list. We should have something like Google document or a wiki page as a
workplace.

About incomplete analyzes, I feel that the Rasdaman team perhaps forgot to
check the GridFunction when they analyzed the offsetVectors.
In the Rasdaman case there is an axisOrder rule
axisOrder="+2 +1"
and offset vectors are
offsetVector srsName="http://ows.rasdaman.org/def/crs/EPSG/0/4326">-0.02 0
srsName="http://ows.rasdaman.org/def/crs/EPSG/0/4326">0 0.02

In the Mapserver case there is no axisOrder rule which meant that it is the
default
axisOrder="+1 +2"
and offset vectors are
offsetVector srsName="http://www.opengis.net/def/crs/EPSG/0/4326">0 0.004167
offsetVector srsName="http://www.opengis.net/def/crs/EPSG/0/4326">-0.004167
0

Question:
Doesn’t these two expressions lead to same result? Yes or no?

-Jukka Rahkonen-




--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS GetCoverage with AxisOrder swap

geowolf
On Thu, Nov 9, 2017 at 10:36 AM, jratike80 <[hidden email]> wrote:
Hi folks,

I think that it is extremely good to discuss about axisOrder, GridFunctions,
offsetVectors, axisLabels etc. because for sure we all want to build
interoperability between different WCS 2.0 implementations.
However, I think that this mailing list thread is rather making more
confusion than clarifying things. First, it is very hard to follow who wrote
what and when, and if that was an answer, then what was the question. And if
we make errors with our conclusions, or if we forget to think about all
aspects in out analyzes, it is very hard to clarify that on the mailing
list. We should have something like Google document or a wiki page as a
workplace.

Fully agreed, a small tutorial with a few user cases (geographic, projected east/north,
projected north/east) and (all?) valid ways to describe those situations would be
very useful

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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS GetCoverage with AxisOrder swap

Piero Campa
In reply to this post by Ari Jolma-2
Even,

On 8 November 2017 at 16:31, Even Rouault <[hidden email]> wrote:

OK thanks for the explanations. Makes some sense....

So it would seem that if you want to return a GeoTIFF in

traditional GIS order (ie faster varying dimension corresponds to longitude), AND you emit

​ ​
offsetVector in the way Rasdaman does, it seems

that emitting a gml:GridFunction +2 +1 would be required.


​Yes, as Jukka also pointed out in a later reply.  !

If you /match/ the description of the geometry of the grid (origin, offset vectors order, etc) with the way you list the grid _data_ then you don't need the GridFunction (that is, you can assume the default +1 +2 ... +N linear rule).

In the other case, you need to instruct the client on how to interpret the data.

(I believe that if the GridFunction would not be optional, this all would be a little less confusing)

 
But actually, looking closely at the drawing at

http://rasdaman.org/wiki/PetascopeUserGuid

e#GridaxislabelsandCRSaxislabels , I see

​​
RectifiedGrid.axisLabels="t Long Lat", whereas
​​
RectifiedGrid.origin.Point@axisLabels="t Lat Long"
​ ​
(note the inversion). The second offset vector expressed an increase in longitude (0 0 0.5), while thethird one a decrease in latitude (0 -0.5 0). Which is the GIS friendly order.

 

So, it would seem that there are 2 more or less equivalent way of achieving the same end result ?


GRID axes names (in spite of the CRS axes names which are formally described in its definition) are arbitrary: in the example, the rasdaman ​implementation chooses to name grid axes by the CRS axes they span.

​RectifiedGrid.axisLabels (GRID axes) are "t Long Lat", but could just be "0 1 2", or "a b c". Naming them after the CRS they span is just more convenient.

​RectifiedGrid.origin.Point@axisLabels are the CRS axes names instead, hence latitude goes first.
The GML there is OK: indeed you see the 2nd offset-vector, the direction of the 2nd "Long"-labelled GRID axis) goes '0 0 0.5', hence in the easting direction.

​​

 

And thus MapServer output at

http://194.66.252.1

And thus MapServer output at

http://194.66.252.155/cgi-bin/BGS_EMODnet_bathymetry/ows?SERVICE=WCS&REQUEST=DescribeCoverage&version=2.0.1&coverageid=BGS_EMODNET_CentralMed-MCol

could probably be correct, but it would be better for RectifiedGrid.axisLabels to be changed to "long lat" to better

​ ​
reflect what is done.


Exactly, that output is not OK as it is now.

 

​​
And GeoServer output at https://msp.smartsea.fmi.fi/geoserver/wcs?SERVICE=WCS&REQUEST=DescribeCoverage&VERSION=2.0.1&COVERAGEID=smartsea__eusm2016-EPSG2393

would either need to remove the GridFunction (ala MapServer) or keep it and invert the order in which its offsetVector appear (ala Rasdaman)

 


If GeoServer is not going to span the North direction first in the GetCoverage responses, then that description is wrong.
Being EPSG:2393 a North-first CRS, the geometry of the grid already defines the North-ward as first (+1), and East-ward as second (+2), so if that is the rule which GeoServer will use to list the data, the GridFunction there is wrong.

 

And for WCS subsetting, when you write something like SUBSET=AXIS_NAME(min,max),

​ ​
where AXIS_NAME should come from ? From the RectifiedGrid.axisLabels I guess ?
 

​NO, subsetting/subspacing​ is meant to work aligned with the coordinate system (!)
You choose your (sub)space of interest, and then the server will filter out all the grid points that get included in that space, independently of its, say, geometric profile (indeed in extreme settings, what you get might not be a grid! see below)

Example: imagine an oblique 100x100 2D regular grid in a 3D "X Y Z" CS space. The grid has 2 "i" and "j" axes, with origin in "0 0 0" and offset vectors which might be "1 1 0.5" for i and "-0.5 -0.5 1" for j.
The user's might want to fetch all the grid points in the small cube delimited by X(0:3) Y(0:3) Z(7:10). in the 3D space, the user has defined this little cube which will act as spatial filter for the oblique grid.

Subsetting via GRID indexes would be probably achieved if you request a GetCoverage by using the "Index?D" CRS which is mean

Anyway.. it was just for keeping it a little less abstract.
WCS subsettings need the CRS axis names.

(In this nasty example, if you'd want to subset the oblique grid by taking its 10x10 subgrid starting from the origin, then a) the server would need to implement the WCS CRS extension, b) you would need to set the "subsettingCrs" parameter to, say, http://ows.rasdaman.org/def/crs/OGC/0/Index2D in the GetCoverage request, and subset to i(0:9) and j(0:9))
[1] http://rasdaman.org/wiki/IndexCrss

Then in Ari's test with GeoServer

https://msp.smartsea.fmi.fi/geoserver/wcs?SERVICE=WCS&REQUEST=DescribeCoverage&VERSION=2.0.1&COVERAGEID=smartsea__eusm2016-EPSG2393, in theory "i" and "j" should be the axis requested ?


No: having explained that here above, you see subsets in Ari's case should be "X" and "Y", as defined in EPSG:2393.​

-
​Piero !​



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS GetCoverage with AxisOrder swap

jratike80
Piero Campa wrote

>> And for WCS subsetting, when you write something like
>> SUBSET=AXIS_NAME(min,max),
>> ​ ​
>> where AXIS_NAME should come from ? From the RectifiedGrid.axisLabels I
>> guess ?
>>
> ​
> ​NO, subsetting/subspacing​ is meant to work aligned with the coordinate
> system (!)
> You choose your (sub)space of interest, and then the server will filter
> out
> all the grid points that get included in that space, independently of its,
> say, geometric profile (indeed in extreme settings, what you get might not
> be a grid! see below)

Hi,

When Ari gets totally familiar with this then he will like to continue.
About the first new thing he wants to do will be to get response from WCS
with non-native pixel size. The he starts to read the Scaling extension
https://portal.opengeospatial.org/files/12-039 and then he learns that
scaling is done in the RectifiedGrid domain and RectifiedGrid.axisLabels are
exactly what he must use. Poor man.

-Jukka Rahkonen-



--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS GetCoverage with AxisOrder swap

Ari Jolma-2
jratike80 kirjoitti 09.11.2017 klo 15:18:

> Piero Campa wrote
>>> And for WCS subsetting, when you write something like
>>> SUBSET=AXIS_NAME(min,max),
>>> ​ ​
>>> where AXIS_NAME should come from ? From the RectifiedGrid.axisLabels I
>>> guess ?
>>>
>> ​
>> ​NO, subsetting/subspacing​ is meant to work aligned with the coordinate
>> system (!)
>> You choose your (sub)space of interest, and then the server will filter
>> out
>> all the grid points that get included in that space, independently of its,
>> say, geometric profile (indeed in extreme settings, what you get might not
>> be a grid! see below)
> Hi,
>
> When Ari gets totally familiar with this then he will like to continue.
> About the first new thing he wants to do will be to get response from WCS
> with non-native pixel size. The he starts to read the Scaling extension
> https://portal.opengeospatial.org/files/12-039 and then he learns that
> scaling is done in the RectifiedGrid domain and RectifiedGrid.axisLabels are
> exactly what he must use. Poor man.

I had this in my code already

if (scaled) {
         // scaling is expressed in grid axes
         std::vector<CPLString> grid_axes =
Split(CPLGetXMLValue(psService, "GridAxes", ""), ",");
         tmp.Printf("&SCALESIZE=%s(%i),%s(%i)", grid_axes[0].c_str(),
nBufXSize, grid_axes[1].c_str(), nBufYSize);
         request += tmp;
     }

However, I have not yet tested it. I.e., GDAL gives me (the driver) a
buffer where to write. I'm reasoning I should use the scalesize. The
GridAxes is saved from the coverage description.

Ari

>
> -Jukka Rahkonen-
>
>
>
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
> _______________________________________________
> gdal-dev mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS GetCoverage with AxisOrder swap

Ari Jolma-2
Ari Jolma kirjoitti 09.11.2017 klo 15:52:

> jratike80 kirjoitti 09.11.2017 klo 15:18:
>> Piero Campa wrote
>>>> And for WCS subsetting, when you write something like
>>>> SUBSET=AXIS_NAME(min,max),
>>>> ​ ​
>>>> where AXIS_NAME should come from ? From the RectifiedGrid.axisLabels I
>>>> guess ?
>>>>
>>> ​
>>> ​NO, subsetting/subspacing​ is meant to work aligned with the
>>> coordinate
>>> system (!)
>>> You choose your (sub)space of interest, and then the server will filter
>>> out
>>> all the grid points that get included in that space, independently
>>> of its,
>>> say, geometric profile (indeed in extreme settings, what you get
>>> might not
>>> be a grid! see below)
>> Hi,
>>
>> When Ari gets totally familiar with this then he will like to continue.
>> About the first new thing he wants to do will be to get response from
>> WCS
>> with non-native pixel size. The he starts to read the Scaling extension
>> https://portal.opengeospatial.org/files/12-039 and then he learns that
>> scaling is done in the RectifiedGrid domain and
>> RectifiedGrid.axisLabels are
>> exactly what he must use. Poor man.
>
> I had this in my code already
>
> if (scaled) {
>         // scaling is expressed in grid axes
>         std::vector<CPLString> grid_axes =
> Split(CPLGetXMLValue(psService, "GridAxes", ""), ",");
>         tmp.Printf("&SCALESIZE=%s(%i),%s(%i)", grid_axes[0].c_str(),
> nBufXSize, grid_axes[1].c_str(), nBufYSize);
>         request += tmp;
>     }
>
> However, I have not yet tested it. I.e., GDAL gives me (the driver) a
> buffer where to write. I'm reasoning I should use the scalesize. The
> GridAxes is saved from the coverage description.

Now I have, all with the axis order swapped CRS. MapServer and Rasdaman
return fine geotiffs. GeoServer returns something that GDAL complains
"Returned tile does not match expected configuration. Got 13x20 instead
of 20x13.", which is expected since with GeoServer I'm having the grid
axis order problems.

Ari

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS GetCoverage with AxisOrder swap

Peter Baumann
In reply to this post by Even Rouault-2

Even-

very good question:

On 11/09/2017 08:41 AM, Even Rouault wrote:

Peter,

 

> the axisLabels attribute determines axis order, and this in turn refers to the

> CRS definition behind the URL in srsName.

 

Does the value of RectifiedGrid.axisLabels must be correlated with the one of the CRS,

or can it be a "random" value ?

For example, GeoServer has <gml:RectifiedGrid><gml:axisLabels>i j</gml:axisLabels></gml:RectifiedGrid>


In CIS 1.0 it _must_ be the axis name as given in the CRS's axisAbbrev element.
At some time, however, OGP informed the world (well: the WCS.SWG) that this is not normative and they reserve to change it, which they did: "Long" -> "Lon". After the dust around this rumble settled the mechanism (agreed between WCS.SWG and CRS.SWG) was slightly relaxed for CIS 1.1: axisLabels can use _any_ unique identifier (say, axisLabels="x1 x2 x3") and only its positional order defines the mapping between the CRS axis and the coverage axis.

So, in CIS 1.0: exact string equality, CIS 1.1: "random" value.

-Peter

 

> My team has analysed your report and says:

 

Thanks but I'm afraid I'm even more confused now.

 

>

> On 11/08/2017 02:56 PM, Bang Pham Huu wrote:

> > I checked the result as I think it is like this

> >

> > + GeoServer is correct with http://www.opengis.net/def/crs/EPSG/0/2393 as

> > this one is X, Y so the offset vector is correct.

 

In EPSG, http://www.opengis.net/def/axis/EPSG/0/48 = X = NORTH and

http://www.opengis.net/def/axis/EPSG/0/47 = Y = EAST. So this CRS has the "GIS-unfriendly" order.

 

But if you consider

<gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/2393" axisLabels="Y X" uomLabels="m m" srsDimension="2">

<gml:lowerCorner>6543350.381089335 3061592.6391462097</gml:lowerCorner>

<gml:upperCorner>7307056.899896299 3432141.361396798</gml:upperCorner></gml:Envelope>

 

and assume from the above that Y=EAST=6543350.381089335 and X=NORTH=3061592.6391462097 (lower corner values),

this doesn't transform to a location in Finland.

 

Whereas X=NORTH=6543350.381089335 and Y=EAST=3061592.6391462097 does transform to Finland

 

So I think the axisLabels here is wrong, it should be axisLabels="X Y"

 

 

> >

> > offsetVector1: X (positive), Y (negative)

> >

> > offsetVector2: Y (negative), X (positive)

 

Can't correlate the above reasoning about the sign of values with the actual output of

https://msp.smartsea.fmi.fi/geoserver/wcs?SERVICE=WCS&REQUEST=DescribeCoverage&VERSION=2.0.1&COVERAGEID=smartsea__eusm2016-EPSG2393

which is

<gml:offsetVector srsName="http://www.opengis.net/def/crs/EPSG/0/2393">0.0 20.00803035910304</gml:offsetVector>

<gml:offsetVector srsName="http://www.opengis.net/def/crs/EPSG/0/2393">-20.00803035910304 0.0</gml:offsetVector>

 

Given what you said about <gml:GridFunction> not applying to GeoTIFF output, then

this would be correct since the above would express that the first axis (along the width of the image) of the GeoTIFF

express positive easting space and the second axis (along height) express negative northing spacing (image north-up oriented)

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


-- 
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   www.faculty.jacobs-university.de/pbaumann
   mail: [hidden email]
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)
   www.rasdaman.com, mail: [hidden email]
   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)



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS GetCoverage with AxisOrder swap

Peter Baumann
In reply to this post by geowolf



On 11/09/2017 10:44 AM, Andrea Aime wrote:
On Thu, Nov 9, 2017 at 10:36 AM, jratike80 <[hidden email]> wrote:
Hi folks,

I think that it is extremely good to discuss about axisOrder, GridFunctions,
offsetVectors, axisLabels etc. because for sure we all want to build
interoperability between different WCS 2.0 implementations.
However, I think that this mailing list thread is rather making more
confusion than clarifying things. First, it is very hard to follow who wrote
what and when, and if that was an answer, then what was the question. And if
we make errors with our conclusions, or if we forget to think about all
aspects in out analyzes, it is very hard to clarify that on the mailing
list. We should have something like Google document or a wiki page as a
workplace.

Fully agreed, a small tutorial with a few user cases (geographic, projected east/north,
projected north/east) and (all?) valid ways to describe those situations would be
very useful

absolutely! Just remember, standardization - like open-source development - is a voluntary activity with consequently limited resources.
-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 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   www.faculty.jacobs-university.de/pbaumann
   mail: [hidden email]
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)
   www.rasdaman.com, mail: [hidden email]
   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)



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev