I noticed what I think is an issue with vector-to-raster render transformations and I thought I may have the appropriate fix. This can be evidenced when using vec:Heatmap. My assumption is that the intent of a vector-to-raster transform is to use the requested bbox provided as a filter within the query object as you would without the rendering transform. It seems furthermore HeatmapProcess sets a few properties on the rendering query object including expanding the bbox. The problem is that the default code path through RenderedImageMapOutputFormat ends up HeatmapProcess through the direct raster rendering and ends up using Query.ALL as the query passed through the rendering tranformation. This has no-op's for all the properties HeatmapProcess intends to set on the query. The result is that the call to featureSource.getFeatures(query) from RenderingTransformationHelper uses a query that does not include the bbox filter nor any properties set on the query object from invertQuery().
This default behavior can be worked around by setting the property org.geoserver.render.raster.direct.disable which would avoid direct raster rendering globally. Or another possible work around at the layer style scope could be adding a second symbolizer that is perhaps a bit of a no-op symbolizer so it would fail the check in direct raster rendering for a single symbolizer. My thought is that a more robust approach would avoid this pitfall as the default behavior without requiring any workarounds? It seems logical to me to add a check specifically in the direct raster rending to see if the transformation uses a vector source, in which case return to the streaming renderer approach. Anyways, here's my proposed minor change: PR-1790 <https://github.com/geoserver/geoserver/pull/1790> While I was in there, I noticed the documentation for render transforms was out of date with the latest namespace for the referenced geotools' processes so I also submitted a PR for that simple change (PR-1791 <https://github.com/geoserver/geoserver/pull/1791>). By the way, the additional StreamingRenderer extensibility that Andrea added several months ago for the UTFGrid OutputFormat helped out a ton! Running through this was related to updating some distributed rendering work in GeoWave to take advantage of the new StreamingRenderer extensibility and I'm really happy with how much smoother the integration is now. Thanks! Rich
------------------------------------------------------------------------------
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
