Fix hardcoded EPSG code and time window in 0b_Download_HLS_data.ipynb

[dshean]

Cell 3 of https://github.com/uw-cryo/DeepDEM/blob/main/notebooks/0b_Download_HLS_data.ipynb

crs = CRS.from_epsg(32610)
start_date = datetime(year=2015, month=9, day=4) end_date = datetime(year=2015, month=9, day=18)

This is specific to Mt. Baker test dataset, and will create issues for other sites/times.

[kvenkman]

Fixed this - the first line was supposed to be an example of how to set the CRS when it can't be read from an input file. I've commented out the line.

[dshean]

@kvenkman that is only part of the issue. The start_date and end_date are hardcoded to Sept 2015. If you try to run this for a Jan 2025 pair, you will not get an appropriate HLS dataset returned.

[kvenkman]

Yes, the user would have to provide the knowledge of when the stereo image pairs were acquired to constrain the search window for the HLS data. Since the notebooks will be run in an interactive manner by the user, the expectation is that they would modify it as needed.

I opted to write it up in this way, since 1) we don't expect a particular filename convention to be followed for the stereo images on which we can perform substring operations, and 2) there might be scenarios where users would like to opt for a longer time window for searches.

[dshean]

OK. I'm fine using manual entry of date ranges for now. But anything requiring user input (like paths) should be broken out in a separate cell at the beginning of the notebook, with clear doc/flags that it needs to be updated. Too easy to forget to update when buried in middle of a cell like this.

Also, I'm not sure I agree with item 1 above. The co-registered WV stereo DEM products (and hopefully the orthoimages) should have standard YYYYMMDD_HHMM timestamps in the filenames (@ShashankBice if not, let's make sure we standardize in the upstream scripts). This is an assumption for most of the legacy code for WV DEM products: https://github.com/dshean/pygeotools/blob/master/pygeotools/lib/timelib.py#L87. There are better "intelligent" or "fuzzy" parsers out there these days that can attempt to automatically identify datetime strings and formatting in filenames.

Regardless, we should improve the DeepDEM framework for relevant metadata of the input layers, esp as we integrate other fields from the original XML for each image (e.g., view and sun angles).

[kvenkman]

About the standardized filenames - I was thinking that there may be users who are not using our processing scripts to generate ortho images. But we could include code to do this parsing and show an example filename in the comments.

At any rate, I've added a warning markdown cell at the start of the notebook requesting user input on the dates that inform the search window.