Skip to content

GEOS694 Final Project Peer Review - Saurabh #3

@ss2098

Description

@ss2098

GEOS694 Final Project Peer Review Rubric

Instructions

  • Remember this is just a class assignment, and your classmate's work. Please be respectful when providing feedback or comments.
  • Open an issue in your classmate's GitHub repository and copy-paste this rubric.
  • Go through the checklist, reflection questions and task below while consulting the repository.
  • If any checklist items require more explanation or links to code blocks, include them.

Checklist

  • Adheres to PEP-8 formatting (or consistent and explained when deviating)

The code is mostly readable and follows a consistent style. The scripts are organized into classes and methods, and the method names make the workflow pretty easy to follow. I also saw a recent commit specifically for updating formatting to comply with PEP8, so it looks like formatting was considered during development.

  • Commit history that reflects small and frequent commits since project assignment

The commit history looks strong and shows many small, specific commits. The commits are separated by task, such as adding toy problem files, adding packages to the conda environment, moving custom Canwell files into their own directory, updating README information, and making PEP8 formatting changes. This makes the development process easy to follow.

  • Clear installation instructions, installation tested if available

The README gives clear setup instructions using conda env create -f demDiff.yml and also gives a pip install -r requirements.txt option. I was able to create and activate the environment, but I found a syntax error when trying to run the parallel script.

  • Current version number

The current version listed in the README is Version 2.0.0.

  • Example problem with required data either provided or with a data fetching script

The repository includes a toy example with two DEMs from the Canwell Glacier area. This is useful because the example data have different CRS, vertical datums, and resolutions, so it is a realistic test case for the workflow.

  • Appropriate use of functions, tasks are broken into logical chunks

The code is broken into logical steps like loading, preparing, aligning, differencing, checking stable terrain, and saving the result. The parallel script also separates sector creation, sector processing, and mosaicking, which makes the larger workflow easier to understand.

  • Readability, organization, accessibility: Code is well-commented where necessary, files are organized in a logical manner, naming is intuitive or explanatory

The file names are clear, especially dem_diff.py, dem_diff_parallel.py, config_template.yml, and config_toy.yml. The comments and docstrings make the main workflow understandable, and the repository structure is easy to navigate.

  • Documentation is explanative of: what, why, how

The README explains what the project does, why it was made, and how to run both the basic and parallel versions. The example commands are helpful, although one command using --workers auto does not match the current parser behavior because the code expects an integer.

Task #1 appears to be the class-based implementation. The main workflow is organized into classes like DEMDifferencer and DEMDifferencerParallel.

Task #2 appears to be the parameter input system. The project uses YAML config files so users can change DEM paths, CRS information, nodata values, and options without editing the main Python scripts.

Reflection Questions

1. What does this code do?

This code compares two DEM files that may have different resolutions, CRS, or vertical datums. It lines them up properly and outputs a new raster showing the elevation difference between DEM2 and DEM1.

2. How does this code do it?

It reads the input paths and CRS info from a YAML config file, loads both DEMs with xdem, converts them to a common CRS/datum, aligns them to the same grid, and then subtracts one from the other. The parallel version splits the DEM into sectors so parts of the differencing can run at the same time.

3. What data does this code work with?

It works with raster DEM data, mainly GeoTIFF files. The example dataset uses a 2010 IFSAR DEM and a 2025 lidar DEM from the Canwell Glacier area.

4. What do you find cool/interesting/unique about this code?

I thought it was interesting that the code handles the messy parts of DEM differencing, like different CRS, vertical datums, and pixel sizes, instead of just subtracting the rasters directly. The stable-terrain check also seems useful because it gives a quick way to see if there might still be a vertical offset.

5. How can this code be improved?

The main improvement I noticed is fixing small run issues, like the f-string syntax error in dem_diff_parallel.py and the mismatch between the README command using --workers auto and the code expecting an integer. I would also suggest using os.path.join() for output paths so the code is less dependent on trailing slashes.

Task: Pull Request

  1. Find an error/typo/bug/inconsistency in the code, it can be really minor, this is just to practice making a pull request.

I found a syntax error in dem_diff_parallel.py inside the load_config function. When I tried running the parallel script with:

python dem_diff_parallel.py config_toy.yml --num-sectors 4

the script stopped before running because two f-strings had incorrect quotation marks.

The error was in this section:

raise ValueError(f"Config missing required section: "{section}"")

and also in the following required-field error message.

  1. Fork your classmate's repository and clone the repo to your own computer.

Completed. I forked the repository and cloned it to my local computer.

  1. Fix the error that you found on your local version and push the change to your forked repository.

Completed. I created a new branch called fix-parallel-fstring-syntax, fixed the f-string quotation issue in dem_diff_parallel.py, committed the change, and pushed the branch to my fork.

  1. Open a pull request in your classmate's repository requesting the change you made be incorporated into their repository.

Completed. I opened a pull request from my fork/branch into the original repository.

  1. In the pull request, write a small message describing the change, and any additional information you'd like to include.

Completed. In the pull request, I explained that the change fixes a syntax error in dem_diff_parallel.py so the parallel script can get past the config validation step.

  1. Link to your pull request in this issue, and link to this issue in your pull request.

Pull request link: #4

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions