Use the capabilities getmap / gettile url as the "base" for templates #75
Conversation
|
Sorry I don't know why this started the checks, I should get rid of the .github folder I imagine. |
prushforth
force-pushed
the
proxy-capabilities-request-getmap
branch
from
aba61ed to
dddab5c
Compare
|
Indeed, standard wise one should use the the links provided in the caps. However, the links might be missing in some implementations, so I would still allow a fallback to the server base URL, in case no explicit information is provided. (that would likely be a non compliant server, but there's plenty of compliance deviations going around). |
ok, and yes |
|
Thinking about the WMTS gridsets mismatch.... a full match ensures that the remote server can do what GeoServer can do. Mind, when cascading WMTS GeoServer is not acting as a proxy, it's fetching, composing, rescaling and clipping the original server tiles, allowing to support more CRSs, different resolution levels, and eventually more resolutions (upscaling). If one wants to have the client talk directly to the remote server that is eventually doing less zoom levels, the client should be instructed to use the z values of the remote server, instead of the local GeoServer, or it will fail zooming in, when going past what the remote server can deliver. |
fall back to using the URL of the capabilities document itself. Update MapMLBaseProxyTest.java to check the cascaded request against the request URL from the capabilities document OR if that is null, use the URL OF the capabilities document as the base. Update assertCascading in MapMLWMTSProxyTest.java to compare against resource request URL from capabilities document OR if that is null, use the URL OF the capabilities document as the base.
prushforth
force-pushed
the
proxy-capabilities-request-getmap
branch
from
5290d51 to
28e93d4
Compare
Yes, I would like to get there. However I have not tested the WMTS proxy capability too much so far, mainly because I didn't realize it was implemented until too late to comment. I found that the main basemap tile cache of Canada has a required style=default parameter which is blocking me from even hacking the proxy to overlook the discrepancy in zoom levels. It's pretty clear that not every tile cache will have all the theoretical zoom levels of a TCRS, so the design is that the client can be prevented from over-requesting by providing inline metadata in the <map-extent>, either in the form of a <map-meta name=zoom content="min=0,max=n"> or a <map-input type=zoom min=0 max=n>. |
Hi @dromagnoli and @aaime
I noticed that I was having trouble with proxying this WMS because the capabilities URL that I got from a metadata file is different from that in the capabilities document, and yet you can't do a getmap off the base URL that was used as the WMSStore. Weird I know, but it seems safer to parse and use the capabilities request section than it does to use the capabilties URL as the base. WDYT?
This change may break a test but it's hard to tell because of the problem with junit at the moment.
I was very pleased that you tried to proxy the WMTS as well but it seems very sensitive to differences in the number of tile matrices on the proxy definition vs the remote actually implemented tile matrices. Maybe it should just check for the number of tile matrices being less than or equal to the number known to the TCRS? Anyway, I'll play with that next week if I have time.