Here is the answer provided by our GES DISC staff.
There are two ways to get the DatasetId.
1. The search API (https://disc.gsfc.nasa.gov/information/ ... 0Searching) does provide a way to get the DatasetID; here is the code snippet from that HowTo article that prints out the DatasetID and the Label, a more human-readable description of the dataset:
2. An easy but non-programmatic option is to use our web site and go through the “Subset / Get Data” interface. Use the subset option accordions to set up the desired subset constraints, and then click on the “Get Data” button. When list of URLs to download appears, click on the small JobID link in the bottom right corner of the dialog box and it will show you what the syntax of your API request should look like, including the datasetID and any other relevant parameters.# Report on the results: DatasetID and Label
if total > 0 :
for item in response['result']['items']:
print('%-20s %s' % (item['dataset']['id'], item['dataset']['label']))
For example, a spatial and variable subset of GPM IMERG half-hourly data using OPeNDAP:
This is the JobID link: https://disc.gsfc.nasa.gov/api/jobs/arg ... 0dfc100df2
This is what it shows (carriage returns inserted for clarity):
s5p l1 bd1
succeeds (as do equivalent searches for bd2 and bd3), but
s5p l1 bd1 hir
throws the following error in the "# Report on the results: DatasetID and variable subsetting information/# Check for subset services" block:
Traceback (most recent call last):
File "gesdisc_ss_test.py", line 77, in <module>
this appears to be related to a non-subsettable HiR product, since screen I/O contains the lines
The OPeNDAP service supports variable subsetting for S5P_L1B_RA_BD1_HiR_1
The OPeNDAP service supports variable subsetting for S5P_L1B_RA_BD1_1
however, no actual data query for either S5P_L1B_RA_BD1_1 or S5P_L1B_RA_BD1_HiR_1 (and similar for BD2 and BD3) appear to be possible. in my set-up, a query for datasetID OCO2_L2_Lite_FP_9r succeeds, but changing that to any of the S5P L1B id strings returns "API Error: faulty request". the query places no constraints on variable names ("*"), the requested time period is covered by all products, and no other OCO2-specific constraints are given. since the query succeeds for OCO2, i can rule out errors in the set-up. i am stumped.