It supports any base64 encoded image handled by ImageIO.
A new method had to be added to interface org.geotools.styling.StyleFactory to implement this functionality.
Added support for <InlineContent> child of <ExternalGraphic> SLD elem…
Only base64-encoded image data is supported.
I could not try building this patch, but overall it looks fine. Have you tried a full build?
One important thing to mention here, the SLDParse is the SLD 1.0 parser, with extensions, the SLD 1.1 parser is in xsd-sld instead. In other words, if someone tries to submit a SLD 1.1 document to the real SDL 1.1 parser, the parse will keep on failing like before.
support for base64-encoded InlineContent in SLD 1.1 parser
I implemented support for base64-encoded InlineContent in SLD 1.1 parser. Should I revert changes in org.geotools.styling.SLDParser then?
I did a full build and it passed without errors.
I think it will be fine the SLDParser is a beast that tries to read everything, and already contains vendor extensions and support for a few SLD 1.1 things.
The SLD 1.1 parser is the good long term bet.
Veeery long term. We have had for ages and it cannot parse all our vendor extensions, nor we fully support SLD 1.1. It seems there is just no interest among the people that can fund core development.
Looked at the patch, looks good to me, just sharing it with the community on gt-devel since it adds a new public method to a public interface, thus breaking its API (I think it's fine, but don't want to just go and perform an API change based on my gut).
Closed the pull request as I'm applying it with a small modification, the pull request got outdated enough that it was not possible to apply it directly anymore