Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reverse painter's algorithm for tileindex layers #5899

Open
jratike80 opened this issue Oct 19, 2019 · 1 comment
Open

Reverse painter's algorithm for tileindex layers #5899

jratike80 opened this issue Oct 19, 2019 · 1 comment
Assignees

Comments

@jratike80
Copy link

jratike80 commented Oct 19, 2019

tileindex

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

@jbo-ads
Copy link
Member

jbo-ads commented Jul 28, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants