Support scanning directories for VRTs #123
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR add support for scanning directories to find VRTs without having to set up a YAML config file.
Typical usage is to first build raster overviews and then to serve the tiles. For test purposes, first create the test VRT using
and then scan for this VRT and build some overviews using
Overview levels to build are specified as a single string without whitespace containing comma-separate integer overview zoom levels.
To serve the same VRTs with the pre-generated overviews:
Note that it builds a source configuration for each VRT and makes some basic assumptions. In particular it does not know the data limits (the
span
config setting) and it purposely does not load all the data to determine the span as the data may be much larger than RAM. This is not really a problem for overviews, but when you zoom down levels finer than the overviews each tile will determine its own span which will probably not be what you want.A future idea is to store metadata in the VRT to include the span limits.