Nisar dem notebook

[HarshiniGirish]

No description provided.

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[nemo794]

Would it make more sense to use the NISAR DEM vrt files to access/subset the COGs? (vs. searching for individual COGs and manually combining/subsetting them.)

ASF just released documentation/tutorials for this: https://nisar-docs.asf.alaska.edu/nisar-dem/#vrt-reference-files

[HarshiniGirish]

https://gist.github.com/HarshiniGirish/9d84ec88a0ecacd300c51adb5688b4a5

When I try to open the HTTPS VRT https://nisar.asf.earthdata, cloud.nasa.gov/NISAR/DEM/v1.2/EPSG4326/EPSG4326.vrt, I get HTTP 302. Can you please take a look and confirm what’s happening? @nemo794 @wildintellect

[wildintellect]

302 is a redirect, that wouldn't surprise me, but also I'm wondering if the EDL login issues today are also involved.
So we'll need to do a little more research on how to make the vrt work.

[nemo794]

302 is a redirect, that wouldn't surprise me, but also I'm wondering if the EDL login issues today are also involved. So we'll need to do a little more research on how to make the vrt work.

Hmm, the VRTs should be stored in the exact same way (redirects and all) as the COGs which are currently used in the notebook.

If there were EDL issues today, probably best to simply wait until those are resolved to try again with the VRT?

[HarshiniGirish]

Quick update: I’m still seeing HTTP 302 for the VRT (even now)

[nemo794]

I just now followed the CLI instructions here for setting up AWS environment variables and then subsetting the VRT, and it worked correctly: https://nisar-docs.asf.alaska.edu/nisar-dem/#subsetting-via-vsis3

[wildintellect]

Right what's missing is passing the correct GDAL auth headers in the https requests. Maybe @jsignell has an example handy of using EDL+rasterio

[wildintellect]

I think it's something like https://gis.stackexchange.com/a/461792
But why are we even messing with the https version when the S3 version works fine and is better for MAAP anyways?

[jsignell]

Right what's missing is passing the correct GDAL auth headers in the https requests. Maybe @jsignell has an example handy of using EDL+rasterio

I don't have something at hand. I would look to the openscape docs to find the right incantation

[chuckwondo]

I think it's something like https://gis.stackexchange.com/a/461792 But why are we even messing with the https version when the S3 version works fine and is better for MAAP anyways?

Good question, and yes, the advice in that post should do the trick.

Further, the reason that the approach that the OP used (i.e., basic auth) won't work is precisely because of the redirection that occurs. Using basic auth in this case is not only insecure (because the creds get sent to the wrong server), but also ineffective because they get stripped on redirection, and thus never reach the intended host.

Including https might be good for completeness, in case somebody attempts to use things outside of an AWS env, but to Alex's point, perhaps we skip this (unless somebody specifically requests it, in which case this can be added later).

Regarding the S3 use case (and actually, for the https case as well, if kept or added later), please use rasterio.Env(...) as a context manager surrounding the call to open rather than setting env vars in the code. See the full list of GDAL config options that you can pass as kwargs to rasterio.Env().