[gdal-dev] How does WMTS driver detect DataWindow?

[Even Rouault]

On lundi 28 novembre 2016 15:33:31 CET Rahkonen Jukka (MML) wrote:
> Hi,
> 
> While playing with gdal_translate and WMST my colleague found that GDAL was
> picking a wrong DataWindow with
> 
> 
> gdal_translate
> "WMTS:http://xx.yy.fi/foo/service?REQUEST=GetCapabilities&SERVICE=WMTS,laye
> r=bar" bar.xml -of WMTS
> 
> 
> 
> After some thinking we started to believe that the reason may be in the
> wrong WGS84BoundingBox that this WMTS service puts into GetCapabilities
> 
> <ows:WGS84BoundingBox>
> 
> <ows:LowerCorner>-6.38153862706 55.6179644952</ows:LowerCorner>
> 
> <ows:UpperCorner>60.3815386271 75.5825702342</ows:UpperCorner>
> 
> </ows:WGS84BoundingBox>
> 
> 
> 
> I checked with gdaltransform that longitude -6.38153862706 converts into the
> value that was used as the DataWindow UpperLeftX value:
> 
> <UpperLeftX>-1553364.000000402</UpperLeftX>
> 
> 
> 
> However, the TopLeftCorner of the TileMatrix as it is defined in the
> GetCapabilities has a much smaller X value: -548576.000000
> 
> 
> 
> <TileMatrix>
> 
> <ows:Identifier>0</ows:Identifier>
> 
> <ScaleDenominator>29257142.85714285820722579956</ScaleDenominator>
> 
> <TopLeftCorner>-548576.000000 8388608.000000</TopLeftCorner>
> 
> <TileWidth>256</TileWidth>
> 
> <TileHeight>256</TileHeight>
> 
> <MatrixWidth>1</MatrixWidth>
> 
> <MatrixHeight>1</MatrixHeight>
> 
> </TileMatrix>
> 
> 
> 
> Probably because of the wrong UpperLeftX value was gdal_translate seems to
> think that the leftmost tile in this layer has a negative TileX value
> 
> <TileX>-3924</TileX>
> 
> 
> 
> By reading the WMTS standard the negative index values are not valid in
> WMTS:
> 
> TileCol: Column index of tile matrix
> 
> Non negative integer type value between 0 and MatrixWidth-1 of this tile
> matrix defined in the ServiceMetadata document
> 
> 
> 
> BoundingBoxes does not seem to be mandatory in WMTS because they can be
> computed from other, mandatory parameters as it is written in the notes of
> Table 14 - Parts of TileMatrix data structure
> 
> 
> 
> "NOTE 7 The bounding box of a tile matrix is not supplied explicitly because
> it can be calculated from topLeftCorner, tileWidth, tileHeight and
> scaleDenominator."
> 
> 
> 
> It feels that gdal_translate should never write a DataWindow that is bigger
> than the extents of the TileMatrix.   Perhaps BoundingBoxes, if they exist,
> could be used for limiting the maximum extent, like the TileMatrixSetLimits
> if they are found from the GetCapabilities. Or is there something special
> in WMTS that makes it much more comfortable for GDAL to trust in
> BoundingBoxes? Like the fact that different tile levels in WMTS may have
> different bounding boxes?

Hi Jukka,

I don't recall exactly the details but there are several strategies in place in the WMTS driver 
to determine the bounding box of interest based on what you quotes: WGS84BoundingBox, 
TileMatrix, TileMatrixSetLimits. The <WGS84BoundingBox> is likely used as you noticed as 
the most prioritary to indicate the real zone of interest in case of using global tiling schemes. 
But there's probably a lack of checks to validate in case it doesn't make no sense. I believe 
the driver should be able to deal without it. What you can try is to download the 
GetCapabilites response, edit it to remove the  WGS84BoundingBox bounding box and open 
this file with gdalinfo/gdal_translate.

But anyway the driver could be made more robust for those cases. Could be worth filing a 
ticket about that.

Even


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