search

oskariorg / oskari-docs

Oskari documentation and Node.js app running oskari.org
http://www.oskari.org
Other
9 stars 20 forks source link

Changing url of a proxied WMTS layer #295

Closed jampukka closed 1 year ago

jampukka commented 1 year ago

Changing url of a wmtslayer and then refreshing capabilities from the new endpoint changes both url and the parsed capabilities of the maplayer correctly. However changing them does not alter options.urlTemplate, which, if set, determines the actual url to use when requesting tiles from the service for wmtslayers that are proxied via oskari-server through GetLayerTile.

--edit: specify that options.urlTemplate only applies to proxied wmtslayers

ZakarFin commented 1 year ago

Hmm, the proxying GetLayerTile route seems to be the only one using urlTemplate from options: https://github.com/oskariorg/oskari-server/blob/master/control-base/src/main/java/fi/nls/oskari/control/layer/GetLayerTileHandler.java#L175? I suppose we should update that to get the url from capabilities. It doesn't look like it gets set anymore when updating capabilities.

jampukka commented 1 year ago

Yes, that's the one I ran into and almost couldn't figure out why the request still went to the old URL (which the error message kindly told me) even though both the url and the capabilities had been succesfully updated.

I guess the fix is already visioned in the code // TODO: look at GetLayerCapabilitiesHandler and get resource url from capabilities instead (https://github.com/oskariorg/oskari-server/blob/master/control-base/src/main/java/fi/nls/oskari/control/layer/GetLayerTileHandler.java#L174).

So the fix would be to remove options.tileUrl from having any effect anywhere? If so then it would be nice to add a db migration to remove the field from options object from all maplayers (or just wmtslayers). This should be rather safe change to make, I doubt anyone is using options.tileUrl for proxied layers to override the URLs from Capabilities.

ZakarFin commented 1 year ago

So the fix would be to remove options.tileUrl from having any effect anywhere? If so then it would be nice to add a db migration to remove the field from options object from all maplayers (or just wmtslayers). This should be rather safe change to make, I doubt anyone is using options.tileUrl for proxied layers to override the URLs from Capabilities.

True, true 👍

ZakarFin commented 1 year ago

Fix will be included in 2.11 (due late May-early June)