Currently we re-project images into the window projection in the tile store. But if a window is 1 m/pixel and covers a small crop of a big 10 m/pixel image then we store a lot more than is needed (because we first resize the big image to 1 m/pixel in the tile store, then crop it during materialization).
We could instead store it at 10 m/pixel in the tile store and do the re-projection on-the-fly during materialization. For some applications this could have lower performance, but it's actually better for most applications probably. And it could also mean that there's lots of cases where we don't have to modify the image at all from the data source, just copy it directly into the tile store.
But yeah this means the tile store API would need to change -- it would need to accept a projection when reading data, and also probably a list of needed projections when writing data?
Currently we re-project images into the window projection in the tile store. But if a window is 1 m/pixel and covers a small crop of a big 10 m/pixel image then we store a lot more than is needed (because we first resize the big image to 1 m/pixel in the tile store, then crop it during materialization).
We could instead store it at 10 m/pixel in the tile store and do the re-projection on-the-fly during materialization. For some applications this could have lower performance, but it's actually better for most applications probably. And it could also mean that there's lots of cases where we don't have to modify the image at all from the data source, just copy it directly into the tile store.
But yeah this means the tile store API would need to change -- it would need to accept a projection when reading data, and also probably a list of needed projections when writing data?