OPBG Ancillary Data Issue

alaroy · by **alaroy** » Fri Jun 26, 2026 3:50 pm America/New_York

It appears that something caused ancillary data queries to the file search CGI to start failing on 6/17/2026 sometime around 9:00 AM EDT

When we query the file search cgi with any of the following commands

curl -s -d "sdate=2026-06-22&search=PM1EPHND_NRT.A*.*.061&results_as_file=1" https://oceandata.sci.gsfc.nasa.gov/api/file_search

Code: Select all

curl -s -d "sdate=2026-06-22&search=PM1ATTNR_NRT.A*.*.061&results_as_file=1" https://oceandata.sci.gsfc.nasa.gov/api/file_search

curl -s -d "sdate=2026-06-22&search=AM1EPHN0.A*.*.002&results_as_file=1" https://oceandata.sci.gsfc.nasa.gov/api/file_search

curl -s -d "sdate=2026-06-22&search=AM1ATTN0.A*.*.002&results_as_file=1" https://oceandata.sci.gsfc.nasa.gov/api/file_search

curl -s -d "sdate=2026-06-22&search=SNPP_VIIRS.*T*.GEO.nc&results_as_file=1" https://oceandata.sci.gsfc.nasa.gov/api/file_search

We are presented with this error

Code: Select all

<!doctype html>
<html lang=en>
<title>422 Unprocessable Entity</title>
<h1>Unprocessable Entity</h1>
<p>Please provide a more specific request by adding more parameters to your query.</p>

These queries have successfully worked for many years so I am inclined to think something changed on the NASA’s end.

If this is intended behaviour, what parameter(s) should add to my query to make it more specific, please?

If it is not the intended behavior could someone please investigate and if possible restore its previous behavior.

Thank you!
Andrew L.

by **OB Web - jdawson19** » Fri Jun 26, 2026 4:31 pm America/New_York

Hello,

Sorry, you're right, this is a change we added recently. The intention was to restrict large, open-ended queries, which were causing our database to suddenly slow down.

The good news is that there's a simple fix. Assuming that you're looking for files like "PM1ATTNR_NRT.A2026177.1810.061", which has a datatype ID of 512 and is from Aqua-MODIS, you can just add some variation of "dtid", "sensor", and/or "edate". Here's some examples that are working on my end:

Code: Select all

curl -s -d "sdate=2026-06-22&edate=2026-06-26&dtid=512&search=PM1ATTNR_NRT.A*.*.061&results_as_file=1" https://oceandata.sci.gsfc.nasa.gov/api/file_search
curl -s -d "sdate=2026-06-22&edate=2026-06-26&sensor=AQUA&search=PM1ATTNR_NRT.A*.*.061&results_as_file=1" https://oceandata.sci.gsfc.nasa.gov/api/file_search
curl -s -d "sdate=2026-06-22&sensor=AQUA&search=PM1ATTNR_NRT.A*.*.061&results_as_file=1" https://oceandata.sci.gsfc.nasa.gov/api/file_search

Note: I don't recommend that last one, because we're soon going to add some additional logic to *assume* the end date, if not provided. More explicit dates are recommended if you want the specificity.

Let me know if that doesn't work!

alaroy · by **alaroy** » Mon Jun 29, 2026 1:36 pm America/New_York

Thank you for your response quick response. Limiting the number of files searched to not bog the database down too much makes sense.

Since we’re retrieving attitude and ephemeris for MODISA, MODIST and SNPP it would be better to query by the three sensor names rather than 5 data type ids. However, when I try the ones above with sensor=AQUA in the query I get the error:

Code: Select all

curl -s -d "sdate=2026-06-22&edate=2026-06-26&sensor=AQUA&search=PM1ATTNR_NRT.A*.*.061&results_as_file=1" https://oceandata.sci.gsfc.nasa.gov/api/file_search
The database had an error, please modify your query.

If I use the numeric sensor_id I get similar results:

Code: Select all

curl -s -d "sdate=2026-06-22&edate=2026-06-26&sensor_id=7&search=PM1ATTNR_NRT.A*.*.061&results_as_file=1" https://oceandata.sci.gsfc.nasa.gov/api/file_search
The database had an error, please modify your query.

I’m probably missing some detail here but I’m not sure what it is. Any pointers you can give us would be appreciated!

Thanks again!
-Andrew L.

by **OB Web - jdawson19** » Mon Jun 29, 2026 2:18 pm America/New_York

Ah very sorry, that's a case that slipped through the cracks on our end. I've just changed the database procedure on our end, so this query is working for me now:

Code: Select all

curl -s -d "sdate=2026-06-22&sensor=AQUA&search=PM1ATTNR_NRT.A*.*.061&results_as_file=1" https://oceandata.sci.gsfc.nasa.gov/api/file_search

Let me know if that doesn't work for you!

by **OB Web - jdawson19** » Mon Jun 29, 2026 4:24 pm America/New_York

After some discussion, we have realized that there would be a more efficient way to query for this. It would instead be better to use our "dtype" argument. We think that these are the three queries that would satisfy what you're looking for:

Code: Select all

curl -s -d "sdate=2026-06-22&sensor_id=7&dtype=anc&results_as_file=1" https://oceandata.sci.gsfc.nasa.gov/file_search
curl -s -d "sdate=2026-06-22&sensor_id=8&dtype=anc&results_as_file=1" https://oceandata.sci.gsfc.nasa.gov/file_search
curl -s -d "sdate=2026-06-22&sensor_id=14&dtype=geo&results_as_file=1" https://oceandata.sci.gsfc.nasa.gov/file_search

Let us know if those work for you. We'd prefer to remove the ability to query for an entire mission in one go, because it's a heavy burden on our DB

Forum

OPBG Ancillary Data Issue

OPBG Ancillary Data Issue

Re: OPBG Ancillary Data Issue

Re: OPBG Ancillary Data Issue

Re: OPBG Ancillary Data Issue

Re: OPBG Ancillary Data Issue