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
Create mosaics aligned with the mercator tile grid. One drawback of vincent’s simple implementation in awspds-mosaic is that once you get to the edge of a current mosaic, a new mosaic is generated and it essentially deletes all tiles in the old region
But with mosaics aligned with the minzoom, I can store multiple mosaic urls in state and pass different urls for different tiles based on which mosaic they’re contained in. And then you never get the “flicker” from panning, until you change the parameters of the custom mosaic.
You most likely don't want to create one mosaic per zoom 7 tile, since zoom 7 is the minzoom, so if you were at zoom 7.01 and created a new custom mosaic, you'd be creating a new mosaic for each of the tiles on the screen.
I think caching mosaic definitions at zoom 5 might be ideal. By definition tiles at zoom 5 align with tiles at zoom 7. There would be 16 zoom 7 tiles within each zoom 5 tiles. So that would probably give a good balance between fast mosaic creation and not constantly creating a new one every time you pan.
So you can have a state argument like landsatUrlMap that where the key is the bounding tile and the value is the url of the mosaic. So for prebuilt mosaics it might be '0', the quadkey of the global zoom-0 tile:
landsatUrlMap: {'0': mosaicUrl}
But for a custom mosaic it could be something like:
where the keys are each quadkeys referring to zoom 5 tiles.
The function consuming this object can first check for '0', and if it exists assume there's a global mosaic. If the '0' key doesn't exist, then it checks if the requested tile is within any of the tiles that exist as keys. If not, send a request to create a new mosaic for the desired zoom-5 tile.
Only clear this object when a new custom mosaic is desired. Otherwise you're only adding to the state object.
Other notes:
Might be a good idea to create these custom mosaics in a separate folder, like bucket/mosaics/custom so that once in a while you could delete the folder. Or maybe have auto delete for files older than x age for that folder?
Possible to do any smart sat api query to return a "best asset per pathrow"? So that it's returning fewer results and thus be faster?
I want a good user experience with custom date ranges, but it isn't worth optimizing highly for it, because I think most users will use a prebuilt mosaic.
Need to keep in mind tilted viewport. When you have non-zero pitch (in either 2D or 3D) you'll have a non-rectangular viewport.
Requesting STAC results for tile 6, 12, 5 (zoom 5), which is over southwestern US, with parameters:
0 min cloud
20 max cloud
3 months from Jan 1 2019
returned 175 results in about 1.5s. That should be faster from AWS as well. So I think zoom 5 is probably good. The parent tile at zoom 4 returned 488 results in 3.5s for the same search, so I think zoom 5 is probably a good medium.
Idea
Create mosaics aligned with the mercator tile grid. One drawback of vincent’s simple implementation in
awspds-mosaic
is that once you get to the edge of a current mosaic, a new mosaic is generated and it essentially deletes all tiles in the old regionBut with mosaics aligned with the minzoom, I can store multiple mosaic urls in state and pass different urls for different tiles based on which mosaic they’re contained in. And then you never get the “flicker” from panning, until you change the parameters of the custom mosaic.
You most likely don't want to create one mosaic per zoom 7 tile, since zoom 7 is the minzoom, so if you were at zoom 7.01 and created a new custom mosaic, you'd be creating a new mosaic for each of the tiles on the screen.
I think caching mosaic definitions at zoom 5 might be ideal. By definition tiles at zoom 5 align with tiles at zoom 7. There would be 16 zoom 7 tiles within each zoom 5 tiles. So that would probably give a good balance between fast mosaic creation and not constantly creating a new one every time you pan.
So you can have a
state
argument likelandsatUrlMap
that where the key is the bounding tile and the value is the url of the mosaic. So for prebuilt mosaics it might be'0'
, the quadkey of the global zoom-0 tile:But for a custom mosaic it could be something like:
where the keys are each quadkeys referring to zoom 5 tiles.
The function consuming this object can first check for
'0'
, and if it exists assume there's a global mosaic. If the'0'
key doesn't exist, then it checks if the requested tile is within any of the tiles that exist as keys. If not, send a request to create a new mosaic for the desired zoom-5 tile.Only clear this object when a new custom mosaic is desired. Otherwise you're only adding to the state object.
Other notes:
bucket/mosaics/custom
so that once in a while you could delete the folder. Or maybe have auto delete for files older thanx
age for that folder?References:
The text was updated successfully, but these errors were encountered: