MapStore must not rely on the workspace prefix inside the style names returned by GetCapabilities

[giohappy]

Geoserver 2.19.x fixed a wrong behaviour where style names isnide workspace-specific GetCapabilities reponse were returned with the workspace prefix.
MapStores Styled editor relied on this prefix for its functionalities, which now are broken with Geoserver 2.19.x.

Another method must be designed to retrive the fully qualified name of the style (workspace + style name).

[allyoucanmap]

@giohappy I'm investigating client side to understand how to fix this behaviour but there are some cases where it's not possible recognize the correct workspace for example when a layer uses style from the global styles/ folder mixed with other from a specific workspace.

case

• layer gs:us_states with get capabilities targeting its own specific workspace shows all the styles without prefix but there are some styles that are in the global styles folder. How should the client guess which one is from the styles folder and which not? (pophade, pophatch and polygon are in the global styles/ directory)

https://gs-stable.geo-solutions.it/geoserver/gs/us_states/wms?service=WMS&version=1.3.0&request=GetCapabilities

[giohappy]

this is a good question. We should ask the Geoserver team.

[allyoucanmap]

@giohappy the answer is that we cannot rely on get capabilities to get information about the workspace of a style but we should use the geoserver rest api instead.

[giohappy]

@allyoucanmap so another request to do...
Having a proper metadata management for styles is more and more urgent, but since this won't happen very soon I don't see any other solution then doind this affitional request for the time being.

[giohappy]

@allyoucanmap apparently the problem also happens with the new 2.18.x, the one updated for the current GN 3.2.x. Can you please give it a look urgently?

[giohappy]

For the moment we're stuck since responses from the GetCapabilities can be ambigous in case multiple styles with the same name are assigned to a layer. There's no way to tell which layer is what.

For GeoNode we could base the solution on the metadata returned by the GS REST API but we have a problem with the double requests that are currently needed to set the metadata for a new layer.

At the moment the only way to distinguish styles with same name from multiple workspaces is to do a global GetCapabilities, which is far from optimal of course.

@simboss we need to discuss an alternative solution together with the Geoserver team I guess.

[giohappy]

@allyoucanmap do you think we can port the fix to the mapstore client quickly?

[allyoucanmap]

@giohappy yes, starting to work on it

[giohappy]

I guess this can be close @allyoucanmap right?

[allyoucanmap]

@giohappy yes