Earthdata Forum

Hi, I am using the python script to download ATL13 data. I came across a unique problem where I am getting data for the tracks far from the polygon I requested data for. The open altimetry suggests that there is data for a track passing through pigeon lake in Alberta, Canada. But the script throws no data available. If I give year round dates, it downloads files from tracks that are far from my ___location. Here is the inputs (dates and polygon):

short_name = 'ATL13'
version = '006'
time_start = '2023-05-01T04:00:00Z'
time_end = '2023-06-30T04:59:59Z'
bounding_box = ''
polygon = '-114.18417342612825,52.95560380439842,-113.91363509605013,52.95560380439842,-113.91363509605013,53.10261557297814,-114.18417342612825,53.10261557297814,-114.18417342612825,52.95560380439842'

I have a similar issue as well. Please let us know if anyone else has this or if there is a workaround to solve this.

Hi Amit,

Apologies for not seeing this question until now.

You've mentioned that you have used https://openaltimetry.earthdatacloud.nasa.gov/data/ to confirm that there is ATL13 data available in your bounding box region, which is great as it is a useful tool for discovering the presence of data in small regions and on particular days... especially with the way the laser can point off the rgt. One can download subsetted files directly from OpenAltimetry using the Select a Region tool and viewing the graphed elevation profiles to see the download links.

That being said, the spatial subsetter does better with larger bounding boxes due to the segment structure of the data.

You also mentioned that you'd been using the data download python script. I should note that that script had been running into an issue with the way it was searching and was missing granules. A fix to the script was deployed recently on 10/18. This may also have been part of the issue.

I hope with this information, all will go smoothly!

--Diane

Hi, thanks for the response. I am still having similar issues even with the new script for the data download. I am not getting the data withing the bounding polygon I specified.

I tried a larger bounding box as you suggested, but still couldn't get the data I need for the Pigeon lake, Alberta, Canada ___location. Openaltimetry shows the existance of data, but the script is not able to access those files.

Please suggest a work around. Thanks for the support.

Hi Amit,

I want to do a quick check that your extended bounding box really is much larger than you think necessary. It is an odd situation, so I'll try to explain it with the attached image.

What you're seeing in OpenAltimetry (OA) is the truth: there is a RGT going across Pigeon Lake with ATL13 data. You might find with drawing a small bounding box there, that OA fails to find a granule even though it's showing it. This is due to the way the RGTs are represented in the Earthdata search system (EDSC) - they unfortunately do not match what you see in OA. I kept extending my drawn bbox in OA until I successfully got a granule return, then downloaded it to find that the correct granule is ATL13_20240314073718_13212201_006_01.h5. I then went into EDSC to find the representation of that granule. Where it is drawn, is how far you need your longitude to extend to be able to find it in EDSC.

In the image you can see the two green lines representing the RGT in EDSC. The red arrow is pointing at Pigeon Lake and represents the longitude shift. Go west further than you think with the longitude in your script!

Let me know if this works.

Cheers,
Diane

Hi,

Thanks for the response. I have already tried out what you suggested in your response. I found that the RGTs pertaining to the relevant data of Pigeon lake is far from the actual ___location of the data.

My problem is, I am trying to automate the process of data downloading and processing for my project. I am using the updated Python script provided at your website. In my setup, I am giving a polygon input for data download to my script, which downloads and further processes the data by subsetting from it. If i dont know what should be the extent of my polygon, I cant automate the process.

I hope you understand my problem. Is there a solution available to programatically download the relevant data.

Hi Amit,

Apologies for not addressing all aspects of your problem! I'll try to do so now. ATL13 data retrieval can definitely be frustrating.

I understand that you are using our python script found off the bottom of https://nsidc.org/data/data-access-tool/ATL13/versions/6 to retrieve the data, right? Your first post had a section of the parameters entered from this script shared (thank you!). Note that this script as provided uses the `bounding_box` or `polygon` option for filtering only. It does not subset the data.

As we discussed, the polygon you provided, which is tight around that particular lake, is too small to grab any data. This, unfortunately, is due to the polygons in the search system that estimate the ___location of the data, as you've discovered. The issue is that the search via the script (as well as the GUI in Earthdata Search) depends on grabbing these polygons to be able to retrieve the granules. ATL13 is particularly bad with the offset. To solve this, I recommend extended the longitude bounds of your `bounding_box` or `polygon` much further than you'd think (by full or half degrees even!). Keeping the latitude narrow is fine and can reduce the returned granules, as can a tight temporal constraint. I know this isn't ideal for programmatically searching with areas and we need to adjust this issue in the system.

For an example, try using this api call - pasting it in your browser should return a single granule that is the one of interest (I realized that in my last example I'd landed on a different date from the time constraint you had in your original example so that may have been confusing - this call has an even larger longitude span!):

https://n5eil02u.ecs.nsidc.org/egi/request?short_name=ATL13&version=006&time=2023-06-15T20:48:02,2023-06-16T02:52:57&bounding_box=-116,50.96,-113.91,56.10

This single granule actually contains 4 reference ground tracks. It's a lot more than pigeon lake. You may have done something with the script to do spatial subsetting on your end, but if that is a desired delivery format, you'll notice there is an option at the bottom of the Data Access Tool page (link above) for "Large/Custom Orders" - this redirects you to the Earthdata Search option.

For a different subsetting option (and a whole different approach), we made these services available on our cloud-provided data via Harmony not too long ago. Information for that can be found here: https://nasa-openscapes.github.io/earthdata-cloud-cookbook/tutorials/IS2_Harmony.html.

However, all of these options still have the issue with the estimated polygons (each showing all 4 rgts for each granule) in the search system being quite far off from the better information seen in OpenAltimetry. This is an issue we are aware of and hoping to fix in future releases of ATL13.

That was a lot. I hope it clears the situation up!

--Diane