[Long Play] rio-tiler v2

[vincentsarago]

I'm going to use this ticket to mention some work I'd like to do for rio-tiler next major version

[vincentsarago]

refactor satellite submodules

Why : Right now each submodule (cbers, sentinel2. landsat8) are AWS PDS specific. I'd love for rio-tiler to support more provider and dataset

How:

rio-tiler/
    landsat8/
           c1/ (include collection ?)
                   aws/
                        tiler.py (currently rio_tiler.landsat8)
                   gcs/
                   utils.py 

Pro:

• support multiple providers
• better collection definition

Cons:

• Increase module verbosity from rio_tiler.landsat8.c1.aws import tiler as landsat8Tiler

Alternative:
Sort collections by provider

rio-tiler/
    aws/
           landsat8/
                   tiler.py (currently rio_tiler.landsat8)
           sentinel2/
           sentinel1/
            utils.py

[vincentsarago]

Make rio_tiler.main.py default rio-tiler module

I think this could make import simpler e.g

import rio_tiler

bounds = rio_tiler.bounds(...) 
metadata = rio_tiler.metadata(...) 
data, mask = rio_tiler.tile(...)

[vincentsarago]

FYI, I've just pushed a new repo https://github.com/vincentsarago/rio-tiler-experiment where I'm experimenting new idea for rio-tiler.

RIght now the main idea is to sue context manager

with cogTiler("src.tif") as cog:
    tile, data = cog.tile(x, y, z) 

Why ?

The Object/context manager architecture provides a warper around rasterio.open method. The idea is to have the input file (src.tif) available after the tile creation. This enable access to src metadata like internal colormaps or scale/offset if you need it without the need to open the data a second time.

Opinions

This is still a draft and I'm open to suggestion ;-)

[rowanwins]

This enable access to src metadata like internal colormaps or scale/offset if you need it without the need to open the data a second time.

I like the idea of being able to access metadata from the datasource in a wider range of places, so +1 on that!

The only other comment I want to add for consideration for the long-term is it would awesome if this could stay as a rio-tiler library that can be used for many raster formats, and not become too tied to being only a rio-cog-tiler library. For example I've just started using v2.0a11 library to start dabbling on a netcdf server, there are so many useful things that rio-tiler provides that are pretty fiddily when using rasterio directly.

Thanks for a great library!

[vincentsarago]

@rowanwins thanks for the feedback,

FYI I've created https://github.com/cogeotiff/rio-tiler-crs which use the concept by using context manager (so you have access to the input dataset when creating the tile. We may bring this to rio-tiler but I was kinda hesitant because it's quite a big shift.

The only other comment I want to add for consideration for the long-term is it would awesome if this could stay as a rio-tiler library that can be used for many raster formats, and not become too tied to being only a rio-cog-tiler

I don't think I'll tie rio-tiler to COG only, even if the submodule is called rio_tiler.io.cogeo it will work with any raster format.

[vincentsarago]

We've moved a lot recently, and most of the idea have been implemented