I just stumbled upon what appears to be an error in the GeoServer embeded WMTS, when using it with a global layer group virtual service.
In this instance, I am using the default release directory, and the spearfish global layer group.
A GetTile request for a layer in that layer group will fail, for example:
http://localhost:8o80/geoserver/spearfish/gwc/service/wmts?layer=sf%3Aarchsites&style=&tilematrixset=EPSG%3A4326&Service=WMTS&Request=GetTile&Version=1.0.0&Format=image%2Fpng&TileMatrix=EPSG%3A4326%3A14&TileCol=6941&TileRow=4143
Will return:
LAYER sf:archsites is not known.
I would expect to get the tile for that layer, since the layer is contained within the spearfish layer group.
WMTS GetCapabilities only shows the layer group, however I’m not certain if that is actually an error, since WMS getCapabilities also behaves like this for a global layer group virtual service. Does anyone know if this is intended functionality for WMS GetCapabilites?
To sumarize:
When using a global layergroup virtual service:
-
WMTS GetTile does not show tiles for layers contained within the global layergroup. I am reasonably confident this is a bug. (WMS GetMap does work for individual layers within the layer group)
-
WMS and WMTS GetCapabilities only show the global layer group, not the layers contained within it. I am not sure if this is a bug.
Any insight would be appreciated.
Thanks,
Torben
I’m not seeing this.
I’ve tried a LG in both Single and Named Tree modes making get capabilities requests to both services in the virtual service as well as the group, and a layer both with and without its workspace prefix.
After doing a careful step though I got the virtual service capabilities docs always listing just the group and requests in the virtual service only work for the group.
Initially I thought I saw the capabilities docs containing the layers but I may have been looking at the global doc.
The only thing I can think of is maybe you were using the WMS endpoint instead of the WMS-C endpoint? With that the capabilities doc has just the group under Single, but shows the sublayers under Named Tree, and either way the GetMap requests for sublayers work, both with and without the workspace prefix.
If that’s it, this enters into semi-bug/semi-feature territory. Having GWC virtual service mirror the behaviour of GeoServer ones in terms of naming and visibility perfectly would be very nice and the expected way for things to work.
···
On 2018-04-30 12:32 PM, Torben Barsballe wrote:
I just stumbled upon what appears to be an error in the GeoServer embeded WMTS, when using it with a global layer group virtual service.
In this instance, I am using the default release directory, and the spearfish global layer group.
A GetTile request for a layer in that layer group will fail, for example:
http://localhost:8o80/geoserver/spearfish/gwc/service/wmts?layer=sf%3Aarchsites&style=&tilematrixset=EPSG%3A4326&Service=WMTS&Request=GetTile&Version=1.0.0&Format=image%2Fpng&TileMatrix=EPSG%3A4326%3A14&TileCol=6941&TileRow=4143
Will return:
LAYER sf:archsites is not known.
I would expect to get the tile for that layer, since the layer is contained within the spearfish layer group.
WMTS GetCapabilities only shows the layer group, however I’m not certain if that is actually an error, since WMS getCapabilities also behaves like this for a global layer group virtual service. Does anyone know if this is intended functionality for WMS GetCapabilites?
To sumarize:
When using a global layergroup virtual service:
-
WMTS GetTile does not show tiles for layers contained within the global layergroup. I am reasonably confident this is a bug. (WMS GetMap does work for individual layers within the layer group)
-
WMS and WMTS GetCapabilities only show the global layer group, not the layers contained within it. I am not sure if this is a bug.
Any insight would be appreciated.
Thanks,
Torben
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! [http://sdm.link/slashdot](http://sdm.link/slashdot)
_______________________________________________
Geoserver-devel mailing list
[Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@anonymised.comsourceforge.net)
[https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)
--
Kevin Michael Smith
[<smithkm@anonymised.com>](mailto:smithkm@anonymised.com)
Sorry, to clarify:
I am comparing GeoServer WMS with (Embedded) GeoWebCache WMTS to try and understand what the intended behaviour of a global layer group virtual service actually is (since it isn’t really documented anywhere) and seeing a mismatch. I’m still not sure what the intended behaviour is, and am seeking clarification.
Torben
···
On Mon, Apr 30, 2018 at 4:01 PM, Kevin Smith <smithkm@anonymised.com> wrote:
I’m not seeing this.
I’ve tried a LG in both Single and Named Tree modes making get capabilities requests to both services in the virtual service as well as the group, and a layer both with and without its workspace prefix.
After doing a careful step though I got the virtual service capabilities docs always listing just the group and requests in the virtual service only work for the group.
Initially I thought I saw the capabilities docs containing the layers but I may have been looking at the global doc.
The only thing I can think of is maybe you were using the WMS endpoint instead of the WMS-C endpoint? With that the capabilities doc has just the group under Single, but shows the sublayers under Named Tree, and either way the GetMap requests for sublayers work, both with and without the workspace prefix.
If that’s it, this enters into semi-bug/semi-feature territory. Having GWC virtual service mirror the behaviour of GeoServer ones in terms of naming and visibility perfectly would be very nice and the expected way for things to work.
On 2018-04-30 12:32 PM, Torben Barsballe wrote:
I just stumbled upon what appears to be an error in the GeoServer embeded WMTS, when using it with a global layer group virtual service.
In this instance, I am using the default release directory, and the spearfish global layer group.
A GetTile request for a layer in that layer group will fail, for example:
http://localhost:8o80/geoserver/spearfish/gwc/service/wmts?layer=sf%3Aarchsites&style=&tilematrixset=EPSG%3A4326&Service=WMTS&Request=GetTile&Version=1.0.0&Format=image%2Fpng&TileMatrix=EPSG%3A4326%3A14&TileCol=6941&TileRow=4143
Will return:
LAYER sf:archsites is not known.
I would expect to get the tile for that layer, since the layer is contained within the spearfish layer group.
WMTS GetCapabilities only shows the layer group, however I’m not certain if that is actually an error, since WMS getCapabilities also behaves like this for a global layer group virtual service. Does anyone know if this is intended functionality for WMS GetCapabilites?
To sumarize:
When using a global layergroup virtual service:
-
WMTS GetTile does not show tiles for layers contained within the global layergroup. I am reasonably confident this is a bug. (WMS GetMap does work for individual layers within the layer group)
-
WMS and WMTS GetCapabilities only show the global layer group, not the layers contained within it. I am not sure if this is a bug.
Any insight would be appreciated.
Thanks,
Torben
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! [http://sdm.link/slashdot](http://sdm.link/slashdot)
_______________________________________________
Geoserver-devel mailing list
[Geoserver-devel@anonymised.com366...sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)
[https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)
--
Kevin Michael Smith
[<smithkm@anonymised.com>](mailto:smithkm@anonymised.com)
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.com.366…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel