Skip to content

Wmts Probe #406

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 45 commits into from
Feb 8, 2022
Merged

Wmts Probe #406

merged 45 commits into from
Feb 8, 2022

Conversation

jochemthart1
Copy link
Contributor

This PR adds a probe for Mapbox Vector tile service based on issue #379.

Design:

This probe contains 2 probes. One that requests a single layer and another that requests all layers.

KVP/REST
Because WMTS can be requested through KVP and REST, there are a few pieces of code in place to determine whether to request through KVP or REST.

In expand_params() it is determined if the base_url can be requested through KVP, REST or both. These are given as user input options with KVP being default if available.

In wmts.py the REQUEST_TEMPLATE is a dict object that features both a KVP and REST url template. The request template that is used is chosen based on the user input

Issues with REST requests
Because owslib WebMapTileService does not support url's that only provide REST requests, I made sure to check in get_metadata()-wmts.py and WmtsGetCaps(OwsGetCaps)-owsgetcaps.py if KVP request works and to add "/1.0.0/WMTSCapabilities.xml" if not before requesting metadata.
Example for this issue would be this endpoint that can only be accessed through REST:

  • Capabilities url: ".../wmts/1.0.0/WMTSCapabilities.xml"
  • User input url: ".../wmts"
  • Normal get_metadata() request: ".../wmts?service=WMTS&version=1.0.0&request=GetCapabilities" (this will fail)
  • Request should be: ".../wmts/1.0.0/WMTSCapabilities.xml"

after_request is used to restore self._resource.url to the original user input url.

I realize this solution is not really neat, so I'm open to other suggestions.

Requesting center tile
For GetTile requests, the center tile index is calculated using toprightcorner coordinates, scale and matrixwidth/height. Most WMTS services should have some data at the center tile.

Issue in probe.py
In probe, an adjustment has been made to getting self._parameters. copy.deepcopy() is used from plugin.py. This is because previously, the parameters would be overwritten in the following piece of code:

for param in request_parms:
    if param_defs[param]['type'] == 'stringlist':
        request_parms[param] = ','.join(request_parms[param])

Instead of adjusting the request_params variable in probe.py, the original self._parameters was changed.
This problem probably never became apparent, because other probes only send 1 request per layer, but for WMTS, there are multiple requests for each layer and this meant that more and more "," would be added to the request string giving url's similar to this:
.../wmts?service=WMTS&version=1.0.0&request=GetTile&layer=l,,,a,,,y,,,e,,,r&etc...

@justb4 justb4 self-requested a review December 8, 2021 12:29
@jochemthart1 jochemthart1 requested a review from justb4 December 23, 2021 11:33
Copy link
Member

@justb4 justb4 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Almost there: to complete add a test for WmtsGetTileAll. Maybe use a PDOK WMTS URL for variety. Thanks for patience!

@jochemthart1
Copy link
Contributor Author

I specifically left out WMTS GetTileAll because many resources have so many layers that it might take 10-20 minutes. However, I did find a pdok resource that doesn't take too long, but total testing time is still 16 minutes now.

@jochemthart1 jochemthart1 requested a review from justb4 December 24, 2021 11:29
@justb4
Copy link
Member

justb4 commented Dec 29, 2021

I specifically left out WMTS GetTileAll because many resources have so many layers that it might take 10-20 minutes.
However, I did find a pdok resource that doesn't take too long, but total testing time is still 16 minutes now.

That is indeed quite long. Is that because GetTileAll goes through all Layers, Zoomlevels and (image) Formats?
We had a similar problem with WMS. Also that many of the formats advertised simply did not work or their conversion took too long. If those Probes take too long, than that is straining for the WMTS (and GHC) anyway. I see no easy solution, unless like an option to have a single image format with GetTileAll as parameter option.

@jochemthart1
Copy link
Contributor Author

I specifically left out WMTS GetTileAll because many resources have so many layers that it might take 10-20 minutes.
However, I did find a pdok resource that doesn't take too long, but total testing time is still 16 minutes now.

That is indeed quite long. Is that because GetTileAll goes through all Layers, Zoomlevels and (image) Formats? We had a similar problem with WMS. Also that many of the formats advertised simply did not work or their conversion took too long. If those Probes take too long, than that is straining for the WMTS (and GHC) anyway. I see no easy solution, unless like an option to have a single image format with GetTileAll as parameter option.

GetTileAll goes through all layers, each tilematrixset (crs), and each zoomlevel, sampling the center tile. It takes the image format from user input.

pdok WMTS
The above PDOK WMTS resource for example has 4 layers, 3 tilematrixsets with 15, 12 and 20 zoomlevels respectively, which comes down to 188 requests in total.

Changing GetTileAll to randomly sample a zoomlevel (12 checks for this url) or timematrixset (~60 checks for this url) might be a solution. Changing name to GetTileSample would be in order then.

@justb4
Copy link
Member

justb4 commented Jan 13, 2022

That (GetTileSample) is a good suggestion. My suggestion: instead of going through all MatrixSets (zoomlevels), take at least two. Maybe the lowest and highest levels. In my tiling-setups (and I think PDOK and well-setup tiling as well) for example levels 1-13 (RD) are cached and 14+ always requested from source (and never cached) or "blown-up" from level 13 (MapProxy option). So that is a good test if the cache works but also if requesting from the source (WMS) works. A random level could miss out the source request.

@jochemthart1
Copy link
Contributor Author

jochemthart1 commented Jan 25, 2022

Ready for review
I have made the proposed changes and it is now possible to choose to sample or to check all of the tilematrixsets (projections) and tilematrices (zoom levels). This is possible for both GetTile and GetTileAll. I have not changed the name for GetTileAll as this probe still checks all layers opposed to GetTile which asks the user to select one layer.

Tilecol and tilerow indices were set on the center tile within the bounding box and could not be changed. I adjusted this to make the center coordinates of the bounding box appear as a default in the user parameters. A user can change these values to other WGS84 coordinates if they desire to request tiles based on the tile indices of these coordinates

Tests are also adjusted to the new probe parameters. GetTile is tested with REST and KVP and a sample of tilematrixsets and all tilematrices. GetTileAll is tested with KVP and a sample of tilematrixsets and tilematrices.

@justb4
Copy link
Member

justb4 commented Feb 8, 2022

Seeing this just now. Checked the PR list regularly but it still said "Changes requested" and got no notification.
The changes from jan 25 are after our meeting right?

@justb4 justb4 merged commit c6313e7 into geopython:master Feb 8, 2022
@justb4
Copy link
Member

justb4 commented Feb 8, 2022

Let's just merge and test with some diverse WMTSs. It is hard to oversee all code-scenarios with REST, KVP etc. Any problems will be local to the Probe is expected.

@justb4
Copy link
Member

justb4 commented Feb 8, 2022

Thanks for contribution and patience @jochemthart1 !

Copy link
Member

@justb4 justb4 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All ok, let's go!

@justb4 justb4 added this to the Version 0.9.0 milestone Feb 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants