rename the repo

[vincentsarago]

now that we have the official titiler.xarray on pypi we should rename this repo

ref: https://pypi.org/project/titiler.xarray/0.19.0/

[abarciauskas-bgse]

how about titiler-xarray-api?

[vincentsarago]

to me it seems this project (deployment) was oriented for VEDA use so I would reflect that in the name. Except if you think there will be some part of this project that would be re-usable by other project?

[abarciauskas-bgse]

🤔 I think we need:

1. A demonstration of how to create a deploy-able instance of titiler which includes titiler.xarray
2. Deployment code for instance(s) required by VEDA, whatever repo does that should attach a role with NASA Earthdata access to the deployed lambda

I do think this repo could be reused by another project, maybe not directly but forked or copy/pasta. And I understand we may want an even simpler example. So I guess I think this repo could still be the VEDA-dedicated example which includes caching and deployment, and it could be referred to as an example until we have a simpler one.

[hrodmn]

I think titiler-xarray-api or titiler-xarray-application makes sense here. It's not a catchy or clever name but it is descriptive 🤷.

We could define the module like titiler.application.xarray which would complement titiler.application. I don't think that would be a problem since this repo does not import titiler.application.

[vincentsarago]

We could define the module like titiler.application.xarray

I guess you mean titiler.xarray.application?

[hrodmn]

I tried refactoring the package to be titiler.xarray.application and it can be imported alongside titiler.xarray. @vincentsarago @abarciauskas-bgse does repo name titiler-xarray-application and package name titiler.xarray.application sound ok to you?

[vincentsarago]

oh I guess I didn't really though about it but if it works 👍

[hrodmn]

I spoke too soon! So far I have been unable to properly set up titiler.xarray.application as a namespace package that can be loaded along with titiler.xarray. It might be possible but will be simpler if we just pick a non-conflicting name. titiler.application.xarray works in this case because we do not import the titiler.application package.

[abarciauskas-bgse]

🤔 I don't think I can help as far as namespacing the package, but let me know if you want to rubber 🦆 on it @hrodmn. I do think it would be ok to rename the repo with a veda (e.g. titiler-xarray-veda, or titiler-md-veda) identifier since that is what we are deploying it for but feel its better to keep the application name out of the code, since there is nothing outside of the deployment that is VEDA-speciic

• Would it help to use md or multidimensional instead of xarray like https://github.com/developmentseed/titiler-md-demo?
• Are you planning to keep the caching implementation?

[hrodmn]

titiler.xarray.application is the cleanest sounding module name, but I think the only way to make it work is to remove titiler/xarray/__init__.py so it is possible to extend the namespace. That means working out a different solution for storing version in titiler.xarray. If we don't do this, we can't add new modules to titiler.xarray in packages like this one.

It will be much simpler to just think of a different name for this repo! I think it makes sense to keep deployment-specific details out of the repo/package name.

How about repo titiler-xarray-api and package titiler.xarray_api?

[vincentsarago]

If we don't plan to release on pypi the name could also be just app 🤷

I would try to avoid using the same namespace as titiler.application to avoid confusion but also if you want to have titiler.application installed in the same env

Or what about titiler.multidim ?

[hrodmn]

• Would it help to use md or multidimensional instead of xarray like https://github.com/developmentseed/titiler-md-demo?

Thanks for the suggestions @abarciauskas-bgse and @vincentsarago. I like the idea of titiler-multidim for the repo and titiler.multidim for the package name. That leaves the possibility of a pypi release if we decide to go down that road.

• Are you planning to keep the caching implementation?

Yes I am keeping the redis cache functionality in #71 following @vincentsarago's suggestion