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. HTH, Peter > > > > > > > -- > 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@lists.osgeo.org > 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: 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) _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
