This is a follow-up on GEOT-6894. There is a need to clean up which class is taking care of what in gt-wmts, and from my perspective it seems like WMTSTileService is dealing with too much. It should just handle one instance of TileMatrix for a given format. One of the properties of WMTSTileService is templateUrl. For each tile request this is processed to give the final url. My proposal have these implications:
Integrate layerName, styleName, tileMatrixSetName, format within templateUrl and remove those properties from WMTSTileService
Remove the dependency on type (KVP / REST) from WMTSTileService and WMTSTile by integrating {TileMatrix},{TileRow},{TileCol} in both templateUrl's
Make a fast URL-creator based on StringBuilder to replace {TileMatrix},{TileRow},{TileCol} within WMTSTile.getUrl()
Environment
None
Activity
Andrea Aime
June 26, 2021 at 2:05 PM
Reopening, the PR as merged is causing legitimate build failures
This is a follow-up on GEOT-6894. There is a need to clean up which class is taking care of what in gt-wmts, and from my perspective it seems like WMTSTileService is dealing with too much. It should just handle one instance of TileMatrix for a given format.
One of the properties of WMTSTileService is templateUrl. For each tile request this is processed to give the final url. My proposal have these implications:
Integrate layerName, styleName, tileMatrixSetName, format within templateUrl and remove those properties from WMTSTileService
Remove the dependency on type (KVP / REST) from WMTSTileService and WMTSTile by integrating {TileMatrix},{TileRow},{TileCol} in both templateUrl's
Make a fast URL-creator based on StringBuilder to replace {TileMatrix},{TileRow},{TileCol} within WMTSTile.getUrl()