I think this is enough to show the potential, it takes a bit of refactoring since so much logic goes into tile-handling atm, but we don't have to bother with that in the general case, when using the warper.
What will matter for mapscanner is making sensible choices about the dimension, and the extent - and whether we really have to stick with Mercator (it's hardcoded for now just to stay compatible with assumptions.
Pros: it's quicker, we can use multiple varied providers (some is GDAL-TMS xml, but wmts providers like mapbox also work), lots of tile logic can be forgotten
Con: we aren't getting native imagery, but we can by aligning to the zoom levels (I just stopped short of doing that because not sure it's so important).
I'm still in the middle of some of these things helper wise, but this can simplify what mapscanner is currently doing, I think.
I think this is enough to show the potential, it takes a bit of refactoring since so much logic goes into tile-handling atm, but we don't have to bother with that in the general case, when using the warper.
What will matter for mapscanner is making sensible choices about the dimension, and the extent - and whether we really have to stick with Mercator (it's hardcoded for now just to stay compatible with assumptions.
Pros: it's quicker, we can use multiple varied providers (some is GDAL-TMS xml, but wmts providers like mapbox also work), lots of tile logic can be forgotten
Con: we aren't getting native imagery, but we can by aligning to the zoom levels (I just stopped short of doing that because not sure it's so important).
I'm still in the middle of some of these things helper wise, but this can simplify what mapscanner is currently doing, I think.
Created on 2022-06-28 by the reprex package (v2.0.1)