Slippy maps from Cloud Optimized GeoTiff

[tombh]

@cholmes I saw in your implementation details for Planet that you use COG. Do you also use COG as a basis for slippy maps? Eg; generating TMS endpoints? If so, are you able to explain how?

[cholmes]

Right now the Planet slippy maps don't use COG directly. We had to do web tiles before we had COG really up and running for all data, and haven't had a chance to experiment with it. But I'm hoping to push the team to experiment more in that direction.

That said I believe @Millerj1994 and his team @FarmShots have used Planet COG as a basis for slippy maps. And I think @lossyrob has also been looking in to serving maps direct from COG, though through geotrellis.

I heard you all at OAM have some experiments in that direction. Would love to hear more about what's working on not for you. I'm contemplating putting together some COG best practices thing, to talk about implementations, etc.

[tombh]

Thanks for the writeup Chris. So basically it looks like we don't have an established, defacto tool yet then. Certainly the work @mojodna has been doing with the oam-dynamic-tiler represents a significant wealth of knowledge. However it doesn't quite formally follow the COG standard yet, I get the impression it wouldn't be a huge leap to implement it strictly. However the bigger hurdle I see in terms of its use as something canonical is that it's still locked into dependency with OAM, AWS Lambda and S3. There has been brief discussion at OAM that we'd be keen to formalise the dynamic-tiler should the funds arise.

As a brief aside: in theory a slippy map server for COG imagery could be completely distinct, such that it could even be a public SaaS app. Eg; https://slippycogs.io/tms/s3://random-bucket/randomCOG.gtif/1/2/3 would proxy the geotif and magically return the appropriate tile.

[mojodna]

https://github.com/mojodna/marblecutter takes oam-dynamic-tiler further (thanks, Mapzen), supporting single-band DEMs and fully moving to support COG. A future round of work would be to take the cleanup that's occurred there and ensure that it supports RGB(A) imagery and individual files (the Mapzen work uses Postgres to figure out what sources should be part of a mosaicked view, and in which order). It also needs to support tiling of individual files (again; that got stripped out during the mosaicking work).

Marblecutter is no longer locked to OAM / Lambda / S3; there's a Flask app (I've been using it to develop) and Postgres provides path information (which is currently S3 buckets/keys, but could be HTTP, or even local).

[cholmes]

Closing this, as it's a bit orthogonal to the core catalog api.