Forum

Thank you for the example. We have been discussing this topic with the CMR team and have some additional information to provide: The "feed.entry updated" field represents the “date/time of the last update to the associated metadata” and is pulled from the granule metadata “ProviderDates” f...

Thank you for reaching out with your question. Or team has been investigating. In the CMR API response, there is a “feed:{ “updated” “field (as shown in your screenshot), which is the date/time the API search was executed and should be returned; this field is not related to the granule metadata. htt...

After additional testing and discussion with the OPeNDAP in the cloud team, we do not recommend using Panoply’s remote access method to access TEMPO data. TEMPO data are in the cloud and have OPeNDAP in the cloud links—the example you provided of data that work are from GES DISC’s on-prem OPeNDAP. C...

Can you please send the exact URL you are using so we can try to replicate the error? I tried displaying the radiance variable from the netcdf directly, and that works, so there may be something incorrect in the opendap method. Also, did you try to open this granule more than once? Do you always get...

As TEMPO data are in the cloud, these data are available through OPeNDAP in the cloud, which is set up a bit differently than the link you posted, which is an on-prem OPeNDAP instance. But one of the main differences is that currently, the OPeNDAP in the cloud does not offer collection-based landing...

Thank you for your question. OPeNDAP is currently available for the TEMPO RADT L1 data. I think the confusion may be from json response you posted. The "Not Provided" refers to the the Service Type and indicates that OPeNDAP does not have a further type classification in CMR; however, the ...

ESDIS data are located in Amazon region us-west-2. ESDIS policy requires that users be in-region to access the data. Additional guidance can be found in the ReadMe (https://data.asdc.earthdata.nasa.gov/s3credentialsREADME).

Thank you for letting us know of this behavior. I spoke with the Harmony development team and they said that this is not the expected behavior (i.e., it shouldn't be taking that long). They determined that the extended time was due to a bug related to how the authentication request was being queued ...

I am glad to hear that you were able to get your downloaded files. With max_results=2, Harmony captures 2 files, the first file from the original problem, and the second file that contains timestamp within specified limits. Therefore, Harmony reports the issue with no data even if it's just one file...

Thank you for reaching out with your question. The ASDC service team reviewed your code and determined that this issue comes from an unfortunate combination of request parameters. With max_result=1, the request is limited to the first granule that contains data for June 3, 2024. In this case, the fi...