Luis López

If you share your notebook maybe we can take a look at what's happening.

If I test the current approach to verify in-region execution it works from Openscapes (2i2c) is this the same endpoint? @yuvipanda `http://169.254.169.254/latest/meta-data/placement/region` https://github.com/nsidc/earthaccess/blob/e187ae001162d7b844e621c53abbbf26d87305f3/earthaccess/store.py#L140

Ah, this reminded me of an issue the VEDA hub reported, when using earthaccess the library didn't detect in-region execution and used the HTTP links, this is probably why this...

I'll try to take a look this week, we are of course entering dask/xarray territory, I think having this workflow figured out will benefit all earthaccess users. FWIW, unmanaged memory...

Currently we only have S3 credentials endpoints on a per DAAC basis, which covers the typical use cases(getting data from a DAAC) but with Giovanni, Harmony and other NASA-wide services...

Interesting, in theory if the collection belongs to GES_DISC, the S3 credentials for GES_DISC should work. I assume this is not the case because this Giovanni Zarr store is not...

This sounds great @battistowx we should pair this week or the next one if you have time, it should be a simple thing to implement with your code!

I think it would be great if we can expose `earthaccess.__store__.in_region` to `earthaccess.in_region(default="us-west-2")` and perhaps using an nicely formatted __repr__ output besides the boolean value?

What's the status of this one @MattF-NSIDC ?

Sorry for the delayed response @danielfromearth, I think we can ignore `client_id`, this is only telling URS which app is requesting the user's info and this one is actually not...