Atlanta WorldView Stereopair Example

[bpurinton]

wip

See: https://docs.google.com/document/d/1QxcpthDnxT4pV8Lpi4VCKfsYRhWzGrlkbW_DDr9g8to/edit?tab=t.0

One request - I think for the first tutorial, you should just use the overlapping subsections (P00X) for the cropped processing extent you’ve chosen. Can do this manually using the shp they provide, or just open browse and manually determine which P00X to use. This is simpler and more likely what most people will encounter.
When that is functional we can then prepare a separate tutorial wiht the dg_mosai workflow, perhaps processing the full strip (which will take longer, but good to show, as this “full strip” processing is a common case).
FYI, you will also need wv_correct here, as these are older WV-2 images with large detector array geometry artifacts.
Also, please feel free to modify the doc with more information about this, so others don’t encounter this in the future.

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[bpurinton]

@dshean, here is a PR that contains a few bug fixes and some re-organization, with the main point of it being the addition of this beginner friendly Atlanta SpaceNet processing and plotting notebook.

You're welcome to read through that notebook and provide feedback when you have time. I won't merge this PR just yet.

It took awhile to produce (also due to some bugs it shook out [good thing!]) but I'm pretty happy with the direction it headed in. It feels like something you could give to a complete beginner, and, assuming they were able to install ASP, could produce some meaningful and understandable results from.

[dshean]

Looking good! Great to see it all come together. I sent a list of notes and feedback in Slack.

[bpurinton]

Updated progress on feedback and edits to close out the year!

Here is a nicely rendered version of the notebook for viewing

---

general notes on processing and notebook

Done

• For a tutorial like this, it would be nice to have the plots inline with the relevant sections (e.g., bundle_adjust asp_plot result plots after the bundle_adjust call).
• There is enough of a cross-track angle for these acquisitions that the convergence angle is closer to 36-37° (see geometry plot), not 23° as you suggest under “Selecting a Stereopair”
• You can specify COP30_E directly in fetchdem call, which should avoid the “Adjust vertical Reference” section. I try to avoid the dem_geoid utility, and relying on PROJ 3D CRS transformations when possible.
• You can also specify output projection with fetchdem. Do not use proj strings at this point in examples - they are outdated. EPSG code is likely simplest option.
• The reference DEM filename should be defined as a variable if possible. “ref.tif” is ambiguous and should not be used, at the very least, it should be “ref_dem.tif”. The “# Rename for clarity” needs attention.
• The region of interst has “western-longitude”, etc. labels but the values are all in projected coordinates.
• The mapproject --tr value should be a variable set with --t_projwin and --t_srs, not hardcoded. Try to use variable names (tr, projwin, srs) consistent with the asp option names. We usually use the more nadir MEANPRODUCTGSD for --tr. In this case, I see 0.47 m. Your note about “0.5 meters (WorldView-2 panchromatic GSD)” is incorrect, it is closer to 0.42 m.
• Try to avoid corr.map.tif for mapproject output, use an underscore corr_map.tif
• Suggest using 2.0 m DEM (factor of ~4) instead of 1.0 m here, which should help with output quality.

TODO

• It would be ideal to define the output projection once, or to leverage ASP mapproject and point2dem capabilities to automatically select the appropriate UTM projection. I see it defined in the “Bundle Adjustment Residuals” section, which makes it harder to just plug in new images for a different site and run this notebook end-to-end.
• It might be useful to also have an example that sets the projwin to the intersection extent of the two original P002 and P003 images, rather than an arbitrary projwin.
• The number of points in the bundle_adjust solution is relatively low. It might be useful to inspect the resulting adjustments and visualize to see if the resulting changes are realistic. WE could go back to using ip_per_tile, or use a mask to isolate points over exopsed ground (which is important for sites with vegetation). This one is a deeper issue, we can discuss more before action.

asp_plot output

Done

• Geometry plots should come before the cropped, mapproject images
• The reference DEM minus stereo DEM plot shows a large offset that looks like a ~30 m geoid vs. ellpsoid height difference. It seems like this might be an issue with refdem preparation (see notes above about fetchdem). It’s important to track this down - if the refdem is using the wrong datum, then the mapproject step will introduce issues. The ICESat-2 differences are much more reasonable, median of 1.26 m.
• Suggest adding scalebars to the zoom image chips, in addition to the zoom DEM chips. Would be nice to get rid of big whitespace, and maybe put the images before the DEMs.
• Looks like you need to update you sliderule client (“ERROR:sliderule.sliderule:Version check failed: Client v4.19.1 is incompatible with the server v5.0.1”)
• Your x_shift, y_shift, and z_shift values in the alignment_report_df are incorrect. These shoudl be pulled from “Translation vector (North-East-Down, meters): Vector3(0.23873671,0.16951572,1.2110283)“. Right now you’re reporting the ECEF translation components.
• It would be nice to have a final plot for the aligned DEM and the ICESat-2 points, and maybe some before/after histograms, which I think exist somewhere in the asp_plot code already.

TODO

• The processing_parameters Object has no record of the mapproject step and the smaller projwin - could be useful to include (lower priority)
• It looks like the bundle_adjust plots use a larger extent than the projwin, which is a little confusing. Let’s discuss options here.
• Let’s talk about the ICESat-2 filtering (I’m actively working on this). We’re throwing out a lot of good ground returns with the current datetime filters for “seasonal”
• It looks like there are two pc_align calls in the icesat.alignment_report output? - would be good to document this.