Forum

Thank you, John! I was using an old CMR support mail cmr-support@earthdata.nasa.gov that no longer works. I'll continue with support@earthdata.nasa.gov

Best,
Simon

Hi Danielle - I don't see any emails (neither personal nor to the relevant group). Could you cc me directly on the thread?

Is this expected?

https://e4ftl01.cr.usgs.gov/MOLT/MOD09A1.061/2025.05.01/

Question: how many parallel reads from the CMR API are you okay with? We are currently limiting our catalog scans to 10 parallel workers, and with the increasing number of datasets we read, it's starting to take longer and longer to just find the next batch of assets. Would 20 parallel workers be ok...

Thank you, Danielle, everything is working again.

Hi - we are seeing "internal error" responsed to API queries like https://cmr.earthdata.nasa.gov/search/granules.json?downloadable=true&collection_concept_id[]=C2545314541-LPCLOUD&page_size=1000&revision_date[]=2023-08-19T05:44:51.667000,2025-05-13T18:05:42.398841&sort_key=...

Hi There,

We're seeing 1-2 pixel shifts. As each pixel represents 1000 meters so that is the displacement.

You can refer to the script

https://code.earthengine.google.com/67dac3a2dbc456730fd15363ef870a1f

Hi There,

We have tried with random files and we see the same issue in these two datasets.

MYD11A2.A2022249.h12v10.061.2022258145454.hdf
MOD11A2.A2022249.h12v10.061.2022258143859.hdf

The problem is that not every dataset uses the filename to indicate the data version (and if they do, there's no consistenvcy - eg, SMAP uses _01, _02, _03 etc instead of the timestamp). So it would have been better to rely on more structured entries in CMR, but I realize that achieving consistency ...

Thank you, noted. I would argue that because the actual data haven't changed, the "updated" field shouldn't change - the switch from one storage system to another is an implementation detail. Instead, the "revisionDate" field indicating the CMR metadata update time should change....