[gdal-dev] How does WMTS driver detect DataWindow?
Rahkonen Jukka (MML)
jukka.rahkonen at maanmittauslaitos.fi
Tue Nov 29 03:49:36 PST 2016
With a little help GDAL picks up correct extent. Removing the erroneous WGS84BoundingBox hint from GetCapabilities made it.
I consider that there is a bug in the WMTS server which is advertising invalid bounding box but I don't really know GDAL should do.
I am not good at reading the code from https://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/wmts/wmtsdataset.cpp but I do see that there are comments about making a clip with the implied bounding box of the most precise tile matrix, taking into account the TileMatrix limits if they appear in GetCapabilities
The logic seems to be now
1) Use the BoundingBox of the layer expressed in the SRS of the tile matrix set if that exists (row 1394)
2) Otherwise use the BoundingBox of the layer expressed in some other SRS (for example WGS84) if that exists (row 1506)
3) Otherwise use the BoundingBox of the tile matrix set if that exists (row 1550)
4) Otherwise compute the bounding box from the definition of the most precise tile matrix (1558)
The comments about clipping are on rows 1572 and 1587.
So if the meaning was to take the advertised bounding box and clip it with the box that is computed from the tile matrix set and its limits, it seems to fail with our data
In our case the layer has this faulty
<ows:WGS84BoundingBox>
<ows:LowerCorner>-6.38153862706 55.6179644952</ows:LowerCorner>
<ows:UpperCorner>60.3815386271 75.5825702342</ows:UpperCorner>
</ows:WGS84BoundingBox>
and our most precise TM is
<TileMatrix>
<ows:Identifier>13</ows:Identifier>
<ScaleDenominator>3571.42857143</ScaleDenominator>
<TopLeftCorner>-548576.0 8388608.0</TopLeftCorner>
<TileWidth>256</TileWidth>
<TileHeight>256</TileHeight>
<MatrixWidth>8192</MatrixWidth>
<MatrixHeight>8192</MatrixHeight>
</TileMatrix>
With WGS84BoundingBox GDAL finds
<DataWindow>
<UpperLeftX>-1553364.000000402</UpperLeftX>
<UpperLeftY>8388608</UpperLeftY>
<LowerRightX>2553364.000001241</LowerRightX>
<LowerRightY>6681097.999999317</LowerRightY>
</DataWindow>
and without WGS84BoundingBox the correct
<DataWindow>
<UpperLeftX>-548576</UpperLeftX>
<UpperLeftY>8388608</UpperLeftY>
<LowerRightX>1548576</LowerRightX>
<LowerRightY>6291456</LowerRightY>
</DataWindow>
-Jukka Rahkonen-
Lähettäjä: Even Rouault [mailto:even.rouault at spatialys.com]
Lähetetty: 29. marraskuuta 2016 0:07
Vastaanottaja: gdal-dev at lists.osgeo.org
Kopio: Rahkonen Jukka (MML) <jukka.rahkonen at maanmittauslaitos.fi>
Aihe: Re: [gdal-dev] How does WMTS driver detect DataWindow?
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/20161129/41eab330/attachment-0001.html>
More information about the gdal-dev
mailing list