Optimize better than unique pathrow about landsat-cogeo-mosaic

[kylebarron]

You might want to take (an optional, user-defined?) buffer on the pathrow boundaries. For example pathrow boundaries vary a little (#8 (comment)).

So maybe reduce the area to 99% of its size? The hard thing would be making it smaller in a way that conserves its shape. Find the geometry's centroid and then bring each coordinate 1% closer to the centroid?

Happily, it looks like shapely has built-in support for this :) (https://shapely.readthedocs.io/en/stable/manual.html#shapely.affinity.scale)
So maybe try:

shapely.affinity.scale(geom, xfact=0.99, yfact=0.99, zfact=1.0, origin='centroid')

[kylebarron]

Use existing code to generate from DB. but then keep geometry data of each path row and optimize when exporting mosaic

[kylebarron]

I think a better way is to first generate an optimized pathrow-quadkey index, a mapping from pathrows to quadkeys.

You have all the geometries of both the path-rows and the zoom-8 tiles ahead of time, so first make this optimized index. (Also allows you to explore it visually ahead of time to make sure there are no gaps).

Then when creating a new mosaic from the sqlite db locally, you don't need to do "for pathrow in all pathrows". You just loop over the pathrows in the index and then only query the db for those in particular.

When creating a custom mosaic on the fly in lambda, do an inner join between the pathrows returned by sat api and the pathrows in this optimized index. That way creating a custom mosaic on the fly should be fast, because you don't have to do lots of geometry checking. But also created mosaics are optimized.

[kylebarron]

Note: pr2coords.json looks to be exactly the same as the WRS geometry shapefile from https://www.usgs.gov/land-resources/nli/landsat/landsat-shapefiles-and-kml-files

[kylebarron]

This is now supported in the index cli, which creates a pathrow-quadkey index file, and create-from-db which utilizes it.

[kylebarron]

Fixed as of c056a10

[kylebarron]

Leaving open until supported from STAC features as well

[kylebarron]

A little messy but supported from STAC as of 94a502b