[gdal-dev] [Geoserver-devel] GML lat-lon coverages and interoperability

Peter Baumann p.baumann at jacobs-university.de
Sat Jun 3 23:59:22 PDT 2017

On 04/10/2017 07:22 PM, jratike80 wrote:
> Peter Baumann wrote
>> Hi all,
>> why not simply check against the compliance tests of WCS 2 and maybe a
>> reference
>> implementation? Might be the easiest for answering all such questions.
>> cheers,
>> Peter
> Hi,
> I could not find exact match for raster image (GeoTIFF) case from
> http://cite.opengeospatial.org/teamengine/about/wcs/2.0.1/site/ or
> http://schemas.opengis.net/wcs/2.0/examples/.
> When it comes to reference implementation, by following the link
> http://standards.rasdaman.org/ to the WCS endpoint demo using service
> http://ows.rasdaman.org/rasdaman/ows and then to coverage BlueMarbleCov I
> can read that DescribeCoverage contains this:
>     <coverageFunction>
>       <GridFunction>
>         <sequenceRule axisOrder="+2 +1">Linear</sequenceRule>
>         <startPoint>0 0</startPoint>
>       </GridFunction>
>     </coverageFunction>
>     <gmlcov:metadata/>
>     <domainSet>
>       <RectifiedGrid dimension="2" gml:id="BlueMarbleCov-grid">
>         <limits>
>           <GridEnvelope>
>             <low>0 0</low>
>             <high>17999 8999</high>
>           </GridEnvelope>
>         </limits>
>         <axisLabels>Lat Long</axisLabels>
>         <origin>
>           <Point gml:id="BlueMarbleCov-origin"
> srsName="http://ows.rasdaman.org/def/crs/EPSG/0/4326">
>             <pos>89.99 -179.99</pos>
>           </Point>
>         </origin>
>         <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>
>       </RectifiedGrid>
> So both the Rasdaman demo and Geoserver are using gridFunction axisOrder +2
> +1 with EPSG:4326. However, on April 4th you wrote on this mailing list:
> "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."
> I am not yet sure what is the conclusion.
> -Jukka Rahkonen-

Hi Jukka,

sorry for the late response, busy as hell again.

The issue (with ISO 19123) is that coverageFunction can do a lot of things - up
to containing MathML expressions for analytic definitions of grids. (this I was
referring to as less than optimal - AFAIK, this is not used by anybody,
fortunately). OTOH, we have storage relevant parameters like sequenceRule which
determines the sequence of pixels in the sequentialization scheme. This is
relevant indeed, and there is a meaningful default (forgot whether row major or
column major, cannot look it up from here).

As for GeoTIFF, there is a specification defining the mapping, see OGC 12-100r1
available from http://www.opengeospatial.org/standards/wcs.



> --
> View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-GML-lat-lon-coverages-and-interoperability-tp5315441p5316705.html
> Sent from the GDAL - Dev mailing list archive at Nabble.com.
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

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

More information about the gdal-dev mailing list