Re: [gdal-dev] How does WMTS driver detect DataWindow?
On mardi 29 novembre 2016 11:49:36 CET Rahkonen Jukka (MML) wrote: > 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 > > -6.38153862706 55.6179644952 > 60.3815386271 75.5825702342 > > > and our most precise TM is > > 13 > 3571.42857143 > -548576.0 8388608.0 > 256 > 256 > 8192 > 8192 > > > With WGS84BoundingBox GDAL finds > > -1553364.00402 > 8388608 > 2553364.01241 > 6681097.99317 > > > and without WGS84BoundingBox the correct > > -548576 > 8388608 > 1548576 > 6291456 > OK, I managed to reproduce with your above elements. I've pushed a fix so that in that case the WGS84BoundingBox is just ignored and the most precise tile matrix used. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How does WMTS driver detect DataWindow?
Hi, I got to understand why WMTS service has so large WGS84 bounding box in GetCapabilities. It is because the native EPSG:3067 bounding box is first converted into WGS84 by using a densified polygon geometry. The WGS84BoundingBox is then the envelope of this warped polygon. Because of warping the rectangle gets wider towards the poles. This is logical and the result does not look so bad in this image https://gist.github.com/anonymous/2445ea91a8ac7b15bf39 However, if the bounding box goes closer to -90°S or 90°N the distortion gets bigger. In our case the maximum latitude is at 83°N and the result it quite funny http://latuviitta.org/downloads/WGS84BoundingBox.png -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How does WMTS driver detect DataWindow?
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 -6.38153862706 55.6179644952 60.3815386271 75.5825702342 and our most precise TM is 13 3571.42857143 -548576.0 8388608.0 256 256 8192 8192 With WGS84BoundingBox GDAL finds -1553364.00402 8388608 2553364.01241 6681097.99317 and without WGS84BoundingBox the correct -548576 8388608 1548576 6291456 -Jukka Rahkonen- Lähettäjä: Even Rouault [mailto:even.roua...@spatialys.com] Lähetetty: 29. marraskuuta 2016 0:07 Vastaanottaja: gdal-dev@lists.osgeo.org Kopio: Rahkonen Jukka (MML) 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 > > > > -6.38153862706 55.6179644952 > > 60.3815386271 75.5825702342 > > > > > > I checked with gdaltransform that longitude -6.38153862706 converts into the > value that was used as the DataWindow UpperLeftX value: > > -1553364.00402 > > > > However, the TopLeftCorner of the TileMatrix as it is defined in the > GetCapabilities has a much smaller X value: -548576.00 > > > > > > 0 > > 29257142.85714285820722579956 > > -548576.00 8388608.00 > > 256 > > 256 > > 1 > > 1 > > > > > > 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 > > -3924 > > > > 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 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 do
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 > > > > -6.38153862706 55.6179644952 > > 60.3815386271 75.5825702342 > > > > > > I checked with gdaltransform that longitude -6.38153862706 converts into the > value that was used as the DataWindow UpperLeftX value: > > -1553364.00402 > > > > However, the TopLeftCorner of the TileMatrix as it is defined in the > GetCapabilities has a much smaller X value: -548576.00 > > > > > > 0 > > 29257142.85714285820722579956 > > -548576.00 8388608.00 > > 256 > > 256 > > 1 > > 1 > > > > > > 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 > > -3924 > > > > 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 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
