feat: Sketching Overview dataclass

[kylebarron]

I'm thinking that the top-level GeoTIFF instance will create child Overview classes (potentially on creation, in the GeoTIFF constructor).

Then the Overview classes will be defined with their own methods. Like here we define the transform in terms of the full image's transform.

So thinking of like

geotiff = await GeoTIFF.open()
overview = geotiff.overview[0]
tile = await overview.fetch_tile(x, y)
tiles = await overview.fetch_tiles(xs, ys)

Questions:

• Should these be actual dataclasses defined with @dataclass? Not sure what the expected benefit of that is
• Do we want to support fetching tiles concurrently (potentially with request merging) from different overview levels? Or are we ok with a simpler API where we only support fetching multiple tiles (in a way that allows request merging) from a single IFD?

cc @geospatial-jeff

[geospatial-jeff]

Do we want to support fetching tiles concurrently (potentially with request merging) from different overview levels? Or are we ok with a simpler API where we only support fetching multiple tiles (in a way that allows request merging) from a single IFD?

Simpler API to fetch from specific IFDs is better, let libraries like rio-tiler decide when it's best to fetch which IFD (see here). We could add some helper functions like this to async-geotiff in the future if it becomes useful.

[geospatial-jeff]

I like this better because it's one less layer of abstraction, you could of course still call through the overview too.

geotiff = await GeoTIFF.open()

# calls geotiff.overview[z].*
tile = await geotiff.fetch_tile(x, y, z)
tiles = await geotiff.fetch_tiles(xs, ys, z)

[kylebarron]

I like this better because it's one less layer of abstraction, you could of course still call through the overview too.

geotiff = await GeoTIFF.open()

# calls geotiff.overview[z].*
tile = await geotiff.fetch_tile(x, y, z)
tiles = await geotiff.fetch_tiles(xs, ys, z)

👍 This is the question I was trying to ask in the intro

[kylebarron]

I like this better because it's one less layer of abstraction, you could of course still call through the overview too.

geotiff = await GeoTIFF.open()

# calls geotiff.overview[z].*
tile = await geotiff.fetch_tile(x, y, z)
tiles = await geotiff.fetch_tiles(xs, ys, z)

👍 This is the question I was trying to ask in the intro

Though here, one complexity is that there's a difference between z the IFD index and z the logical overview in the presence of internal masks. It's not plainly obvious just from the function signature what the z is referring to. So I might actually start with just implementing fetch_tile on the Overview class, which then would manage also fetching the mask data if there's an associated mask, which should be a more painfully obvious API.

[vincentsarago]

Yeah I personally don't need to have materialized overviews (at least in a first version of async-tiff). Just having a way to get the metadata within the GeoTIFF object would be great.

Though here, one complexity is that there's a difference between z the IFD index and z the logical overview in the presence of internal masks. It's not plainly obvious just from the function signature what the z is referring to. So I might actually start with just implementing fetch_tile on the Overview class, which then would manage also fetching the mask data if there's an associated mask, which should be a more painfully obvious API.

Maybe we will need a way to group the IFD 🤷

[kylebarron]

Maybe we will need a way to group the IFD 🤷

I like the idea of "grouping" them with the Overview class. The Overview as defined here holds both the image IFD and an optional mask IFD