-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The cloud_hosted
flag for granule queries doesn't work
#565
Comments
Another option would be to eliminate the By eliminating the parameter, it is up to the user to either know whether or not the collection is cloud hosted, or to issue a separate collection query first to determine whether or not it is cloud hosted. Given that we would need to make such a collection query under the covers anyway, if we keep the |
Thanks for framing this problem @chuckwondo, I'm inclined to retain the |
@chuckwondo I believe this example aligns with this particular problem:
This is an example in a CryoCloud book tutorial by @mrsiegfried and @wsauthoff which returns files back from the on-prem copy of the data, with the same DOI. If you do the same search in Earthdata Search and set their "Available in Earthdata Cloud" filter, the correct cloud-hosted collection is returned. This is especially problematic for DAACs including NSIDC who are still migrating to Earthdata Cloud and have both on-prem and cloud-hosted collections available. This may be another good use of a decision committee per #761 . I'm also inclined to retain these parameters in |
Interestingly, this behavior is only problematic if
This will return the correct cloud hosted granule results. If you swap to DOI instead, it will return the ECS (on-prem)-hosted file. |
I think the problem is that DOI is only searchable at the collections level see (and also not all granules have a DOI), so internally However, this call to I think this should be a separate issue. One solution would be to add
|
As discovered in discussion of #563, using the
cloud_hosted
parameter for a granule query does not work.This reproduces the problem:
The specified collection is not cloud hosted, so the query should return an empty list of results, but instead returns a non-empty list of results.
Alternatively, instead of returning an empty list of results, we could raise an exception. If we take this route, we would need to decide whether to use a built-in type, such as
ValueError
orTypeError
, or define a custom exception.The text was updated successfully, but these errors were encountered: