You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Inspired by the discussion during the FOSS4G conference in Bucharest I have written some material to support my feeling that we could get nice speed boost in a user friendly way if it would be possible to use some other method than painter's algorithm for deciding which pixels will be included in the final output. Currently images are selected from tileindex orderer by ascending date and rendered one be one from oldest to newest. This is equivalent to the "srs-over" blending mode https://mapserver.org/mapfile/composite.html.
The faster method migt be to select tiles ordered by descending time and start rendering from the newest image. Only if the requested area is not full next images would be used to fill the pixels. Similar blending mode is "dst-over".
The attached test case shows 2x speedup and we got 5-10 times more speed with the production data by manipulating the tileindex to contain a best before field that can be used for making more selective SQL queries from the tileindex.
More detailed description is in the attached document that is in Word format because that is one of the few that GitHub accepts.
Other annexes:
Python script for creating test images
GDAL commands for creating tileindex in GeoPackage format
Mapfile that works for me on MS4W
There is something similar in MapCache. This is called Tile assembling policies. In particular, the stack tile assembly policy is defined as: Every pixel of the resulting tile is filled with the first opaque pixel found in all simple tiles in their retrieval order.
Inspired by the discussion during the FOSS4G conference in Bucharest I have written some material to support my feeling that we could get nice speed boost in a user friendly way if it would be possible to use some other method than painter's algorithm for deciding which pixels will be included in the final output. Currently images are selected from tileindex orderer by ascending date and rendered one be one from oldest to newest. This is equivalent to the "srs-over" blending mode https://mapserver.org/mapfile/composite.html.
The faster method migt be to select tiles ordered by descending time and start rendering from the newest image. Only if the requested area is not full next images would be used to fill the pixels. Similar blending mode is "dst-over".
An alternative would be to analyze the tile index spatially and pass only those images that will contribute to the final output for the renderer. Rendering would then happen with the "srs-over" mode from oldest to newest. This is how the "ExcessGranuleRemoval" in Geoserver https://geoserver.geo-solutions.it/edu/en/raster_data/mosaic_pyramid.html seems to work. The commit of the implementation is https://github.com/geotools/geotools/pull/1344/files.
The attached test case shows 2x speedup and we got 5-10 times more speed with the production data by manipulating the tileindex to contain a best before field that can be used for making more selective SQL queries from the tileindex.
More detailed description is in the attached document that is in Word format because that is one of the few that GitHub accepts.
Other annexes:
Python script for creating test images
GDAL commands for creating tileindex in GeoPackage format
Mapfile that works for me on MS4W
Related ticket #5551
create_and_update_tileindex.txt
Slow temporal range requests from tileindex layers.docx
python_to_create_test_images.txt
painter.map.txt
The text was updated successfully, but these errors were encountered: