A regression with accessing the styles directory was introduced in GeoServer
2.9.2 and 2.10.0 as a result of fixing workspace styles for [GEOS-7635] - Jira. In previous versions, it
was possible to access files within subdirectories (e.g.,
'styles/icons/tropical_cyclone/hurricane_north.png') but that now returns an
error "Unexpected number of tokens in reqest path.". SLD external graphics
can still be used in this manner for formats like JPEG and PNG but this
breaks KML output since the HTTP requests to retrieve the images will fail.
This was useful to keep the number of files in the root styles directory at
a more manageable level with styles that can access over 100 different
icons. Would there be any objections to updating
org.geoserver.ows.StylePublisher to allow accessing styles subdirectories
again?
No objection, indeed encouragement as we have a release scheduled for Wednesday.
I would ask that you report the bug to the issue tracker while preparing a patch, so we can discuss this issue in tomorrows meeting. I have CCed the author of StylePublisher (Alex Goudine) who in his defence pair programmed that one with me
I am not sure I understand you description:
the style publisher treats tropical_cyclone as a workspace name, not a sub directory. I do not have a suggestion for resolving this naming conflict at present
I do not understand your comment about SLD external graphics vs KML output - does the KML encoder need to be fixed?
A regression with accessing the styles directory was introduced in GeoServer
2.9.2 and 2.10.0 as a result of fixing workspace styles for https://osgeo-org.atlassian.net/browse/GEOS-7635. In previous versions, it
was possible to access files within subdirectories (e.g.,
‘styles/icons/tropical_cyclone/hurricane_north.png’) but that now returns an
error “Unexpected number of tokens in reqest path.”. SLD external graphics
can still be used in this manner for formats like JPEG and PNG but this
breaks KML output since the HTTP requests to retrieve the images will fail.
This was useful to keep the number of files in the root styles directory at
a more manageable level with styles that can access over 100 different
icons. Would there be any objections to updating
org.geoserver.ows.StylePublisher to allow accessing styles subdirectories
again?
I created a JIRA ticket [GEOS-8040] - Jira and
will try to submit a pull request today.
When these images are loaded for an output format like PNG or JPEG, the
images are loaded internally by the renderer and work fine since they do not
go through StylePublisher. For KML output, the KML IconStyle will contain a
URL like http://localhost:8080/geoserver/styles/icons/tropical_cyclone/hurricane_north.png
so StylePublisher throws an error when a client like Google Earth tries to
load the image.
