<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Even,<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 8 November 2017 at 16:31, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<span class="gmail-"></span><div style="font-family:"Sans Serif";font-size:9pt;font-weight:400;font-style:normal"><p style="margin:0px;text-indent:0px">OK thanks for the explanations. Makes some sense.... </p>
<p style="margin:0px;text-indent:0px">So it would seem that if you want to return a GeoTIFF in</p>
<p style="margin:0px;text-indent:0px">traditional GIS order (ie faster varying dimension corresponds to longitude), AND you emit</p><div style="font-family:tahoma,sans-serif;display:inline" class="gmail_default"> </div>offsetVector in the way Rasdaman does, it seems<p></p>
<p style="margin:0px;text-indent:0px">that emitting a gml:GridFunction +2 +1 would be required.</p></div></blockquote><div><br><div style="font-family:tahoma,sans-serif" class="gmail_default">Yes, as Jukka also pointed out in a later reply. !<br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br>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).<br><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">In the other case, you need to instruct the client on how to interpret the data.<br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br>(I believe that if the GridFunction would not be optional, this all would be a little less confusing)<br></div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-family:"Sans Serif";font-size:9pt;font-weight:400;font-style:normal">But actually, looking closely at the drawing at
<p style="margin:0px;text-indent:0px"><a href="http://rasdaman.org/wiki/PetascopeUserGuide#GridaxislabelsandCRSaxislabels" target="_blank">http://rasdaman.org/wiki/<wbr>PetascopeUserGuid</a></p><div style="font-family:tahoma,sans-serif;display:inline" class="gmail_default"><a href="http://rasdaman.org/wiki/PetascopeUserGuide#GridaxislabelsandCRSaxislabels" target="_blank"></a></div><a href="http://rasdaman.org/wiki/PetascopeUserGuide#GridaxislabelsandCRSaxislabels" target="_blank">e#<wbr>GridaxislabelsandCRSaxislabels</a> , I see<p></p>
<p style="margin:0px;text-indent:0px"></p><div style="font-family:tahoma,sans-serif;display:inline" class="gmail_default"></div>RectifiedGrid.axisLabels="t Long Lat", whereas <div style="font-family:tahoma,sans-serif;display:inline" class="gmail_default"></div>RectifiedGrid.origin.Point@<wbr>axisLabels="t Lat Long"<div style="font-family:tahoma,sans-serif;display:inline" class="gmail_default"> </div>(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.<p></p>
<p style="margin:0px;text-indent:0px"> </p>
<p style="margin:0px;text-indent:0px">So, it would seem that there are 2 more or less equivalent way of achieving the same end result ?</p></div></blockquote><div><br><div style="font-family:tahoma,sans-serif" class="gmail_default">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.<br><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">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. <br><br>RectifiedGrid.origin.Point@<wbr>axisLabels are the CRS axes names instead, hence latitude goes first.<br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">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.<br></div><br><div style="font-family:tahoma,sans-serif" class="gmail_default"></div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-family:"Sans Serif";font-size:9pt;font-weight:400;font-style:normal">
<p style="margin:0px;text-indent:0px"> </p>
<p style="margin:0px;text-indent:0px">And thus MapServer output at</p>
<p style="margin:0px;text-indent:0px"><a href="http://194.66.252.155/cgi-bin/BGS_EMODnet_bathymetry/ows?SERVICE=WCS&REQUEST=DescribeCoverage&version=2.0.1&coverageid=BGS_EMODNET_CentralMed-MCol" target="_blank">http://194.66.252.1</a></p><p style="margin:0px;text-indent:0px">And thus MapServer output at</p>
<p style="margin:0px;text-indent:0px"><a href="http://194.66.252.155/cgi-bin/BGS_EMODnet_bathymetry/ows?SERVICE=WCS&REQUEST=DescribeCoverage&version=2.0.1&coverageid=BGS_EMODNET_CentralMed-MCol" target="_blank">http://194.66.252.155/cgi-bin/<wbr>BGS_EMODnet_bathymetry/ows?<wbr>SERVICE=WCS&REQUEST=<wbr>DescribeCoverage&version=2.0.<wbr>1&coverageid=BGS_EMODNET_<wbr>CentralMed-MCol</a></p>
<p style="margin:0px;text-indent:0px">could probably be correct, but it would be better for RectifiedGrid.axisLabels to be changed to "long lat" to better</p><div style="font-family:tahoma,sans-serif;display:inline" class="gmail_default"> </div>reflect what is done.<p></p></div></blockquote><div><br><div style="font-family:tahoma,sans-serif" class="gmail_default">Exactly, that output is not OK as it is now.<br></div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-family:"Sans Serif";font-size:9pt;font-weight:400;font-style:normal"><p style="margin:0px;text-indent:0px"></p><div style="font-family:tahoma,sans-serif;display:inline" class="gmail_default"></div>And GeoServer output at <a href="https://msp.smartsea.fmi.fi/geoserver/wcs?SERVICE=WCS&REQUEST=DescribeCoverage&VERSION=2.0.1&COVERAGEID=smartsea__eusm2016-EPSG2393" target="_blank">https://msp.smartsea.fmi.fi/<wbr>geoserver/wcs?SERVICE=WCS&<wbr>REQUEST=DescribeCoverage&<wbr>VERSION=2.0.1&COVERAGEID=<wbr>smartsea__eusm2016-EPSG2393</a><p></p>
<p style="margin:0px;text-indent:0px">would either need to remove the GridFunction (ala MapServer) or keep it and invert the order in which its offsetVector appear (ala Rasdaman)</p>
<p style="margin:0px;text-indent:0px"> </p></div></blockquote><div><br><div style="font-family:tahoma,sans-serif" class="gmail_default">If GeoServer is not going to span the North direction first in the GetCoverage responses, then that description is wrong.<br>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.<br></div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-family:"Sans Serif";font-size:9pt;font-weight:400;font-style:normal">
<p style="margin:0px;text-indent:0px">And for WCS subsetting, when you write something like SUBSET=AXIS_NAME(min,max),</p><div style="font-family:tahoma,sans-serif;display:inline" class="gmail_default"> </div>where AXIS_NAME should come from ? From the RectifiedGrid.axisLabels I guess ?</div></blockquote><div><div style="font-family:tahoma,sans-serif;display:inline" class="gmail_default"></div> </div><div><br><div style="font-family:tahoma,sans-serif" class="gmail_default">NO, subsetting/subspacing is meant to work aligned with the coordinate system (!)<br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">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)<br><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">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.<br>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.<br><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Subsetting via GRID indexes would be probably achieved if you request a GetCoverage by using the "Index?D" CRS which is mean<br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Anyway.. it was just for keeping it a little less abstract.<br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">WCS subsettings need the CRS axis names. <br><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">(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, <a href="http://ows.rasdaman.org/def/crs/OGC/0/Index2D">http://ows.rasdaman.org/def/crs/OGC/0/Index2D</a> in the GetCoverage request, and subset to i(0:9) and j(0:9))<br>[1] <a href="http://rasdaman.org/wiki/IndexCrss">http://rasdaman.org/wiki/IndexCrss</a><br></div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-family:"Sans Serif";font-size:9pt;font-weight:400;font-style:normal">
<p style="margin:0px;text-indent:0px"></p><div style="font-family:tahoma,sans-serif;display:inline" class="gmail_default"></div><p></p>Then in Ari's test with GeoServer
<p style="margin:0px;text-indent:0px"><a href="https://msp.smartsea.fmi.fi/geoserver/wcs?SERVICE=WCS&REQUEST=DescribeCoverage&VERSION=2.0.1&COVERAGEID=smartsea__eusm2016-EPSG2393" target="_blank">https://msp.smartsea.fmi.fi/<wbr>geoserver/wcs?SERVICE=WCS&<wbr>REQUEST=DescribeCoverage&<wbr>VERSION=2.0.1&COVERAGEID=<wbr>smartsea__eusm2016-EPSG2393</a>, in theory "i" and "j" should be the axis requested ?</p><span class="gmail-HOEnZb"><font color="#888888">
<p style="margin:0px;text-indent:0px"></p></font></span></div></blockquote><div><br><div style="font-family:tahoma,sans-serif" class="gmail_default">No: having explained that here above, you see subsets in Ari's case should be "X" and "Y", as defined in EPSG:2393.</div><br>-<div style="font-family:tahoma,sans-serif;display:inline" class="gmail_default">Piero !</div><br></div></div><br></div></div>