Open tfr42 opened 9 years ago
The idea of PR #251 was simply to provide a consistent behavior for organizing the tile levels internally, as not all providers (e.g. the GdalTileDataSetBuilder) construct DefaultTileDataSet() with the levels ordered by resolution. That's why I believe it's a good idea to guarantee the order in the constructor itself.
A positive run-time effect is that before the patch, tile levels had to be ordered for every call to #getTiles( Envelope envelope, double resolution ). After the patch, they are only ordered once on construction.
I still fail to see, how the patch causes the observed problem. Can you provide a full configuration (including the tile directory) for easy observing of the effect? Probably, you can limit the extent and the number of levels to shrink it to a reasonable size.
Actual in all deegree 3.4 pre-releases after pre10 any GetTile requests against local FileSystemTileStore created with tilecache returns a "Tile does not exists" error. This was caused by PR #251. By rolling back this PR the indended behaviour can be restored. Expected is that the behaviour remains the same as in the pre10 and earlier releases and PR #251 is reworked or reverted. Test Setup: We are using http://tilecache.org/ to create a directory structure on the local filesystem which contain the TMS.
The configuration file tilecache.cfg contains the following parameters:
and start the seeding with
./tilecache_seed.py basemap 0 11
see http://tilecache.org/docs/README.html#configuration for more information.
The deegree WMTS is configured with FileSystemTileStore:
and the TileMatrixSet:
The GetTile request: http://localhost:8080/deegree-wmts-basemap/services/wmts?SERVICE=WMTS&REQUEST=GetTile&VERSION=1.0.0&LAYER=basemap&STYLE=default&FORMAT=image/png&TILEMATRIXSET=InspireCrs84Quad&TILEMATRIX=0&TILEROW=0&TILECOL=0