move titiler-xarray within main titiler repo?

[vincentsarago]

TiTiler is evolving and it's hard to keep track on all titiler-* subproject, which is why I would like to ear people's opinions about moving the core code of titiler-xarray within the main titiler repo

I don't think we'll move over everything (e.g not the infrastructure code)

[hrodmn]

I think it is a good idea. titiler-xarray sounds like a special application but it is just an implementation of titiler that focuses on the XarrayReader, right?

[vincentsarago]

Yes, The idea of moving it to titiler repo is also to be able to re-use the Reader to other applications (like titiler-cmr 😉)

[abarciauskas-bgse]

If I understand correctly, we probably want to move the ZarrReader code to core titiler (I would call it XarrayReader, not ZarrReader) and merge/add some of the factory methods defined here to titiler core. Seems like the factory methods in titiler core call self.reader, which would be either an XarrayReader or a rasterio reader (i.e. 2 different reader "backends"). I can't recall where is the issue for dynamically defining the reader type). Do we need to detail which methods would work for both backends and which would need to throw a "not implemented" error for one or the other backend? Perhaps the next step is a more specific implementation outline, unless you think that is overthinking it @vincentsarago .

This repo could still be used to demonstrate how to implement those methods in a deployable application (like titiler-pgstac and titiler-cmr)

[vincentsarago]

👍 Yes the maint idea is to have a NetCDF/Zarr reader (name TBD, but I think it would just be titiler.xarray.io.Reader), which can be reused elsewhere.

We would still have a custom Factory because such Reader won't support all the endpoints defined in titiler.core factories.

Supporting both Rasterio and Xarray dataset in one set of endpoint is tricky because it would add a lot of QueryParameters specific to each backend and I don't think I want to have this by default for now. I prefer having separate set of endpoint for now.

BUT this can be done in titiler-pgstac/titiler-cmr/titiler-stacapi where users should not call single dataset endpoints but use pre-defined mosaic render.

[abarciauskas-bgse]

@vincentsarago in discussing developmentseed/titiler-cmr#34 we (@sharkinsspatial @maxrjones @hrodmn and me) were wondering if the ZarrReader logic should mostly be moved to rio_tiler's XarrayReader, rather than the core titiler library - would you agree?

A few other things that came up:

• source CRS should be able to be passed as a parameter (perhaps just another DatasetDependency) and the fallback (which is currently hard-coded as 4326) should be configurable at the application level (perhaps in settings?)
• @maxrjones has an idea for how to make sure the spatial coordinates are always in the "right" order for generating an image
• The XarrayReader in rio_tiler should allow passing a file path that Xarray can open
• To be considered/tested: Will mosaicing work?

We may open a PR to rio_tiler with an updated XarrayReader that we think would work for our use cases, if we have time this week. We understand the goal would be that the same API methods would be available for the XarrayReader and the rasterio-based Reader.

[vincentsarago]

@vincentsarago in discussing developmentseed/titiler-cmr#34 we (@sharkinsspatial @maxrjones @hrodmn and me) were wondering if the ZarrReader logic should mostly be moved to rio_tiler's XarrayReader, rather than the core titiler library - would you agree?

I would say No, mostly because the ZarrReader comes with too many dependencies. I'm planning to make slight change to the XarrayReader in rio-tiler to avoid over customization in the ZarrReader but not a full integration.

@maxrjones has an idea for how to make sure the spatial coordinates are always in the "right" order for generating an image

👀

I'll start draft PR on both titiler and rio-tiler so you have visibility on what I'm doing