[1pt] PR: Upgrade GDAL base image to v3.12.3 and resolve/upgrade Python dependencies

[mluck]

Upgrades GDAL base image to v3.12.3 (ghcr.io/osgeo/gdal:ubuntu-small-3.12.3) and upgrades Python dependencies. There were a few major hurdles in upgrading beyond the previous GDAL v.3.8.4 primarily due to the fact that v3.8.4 was the last version to use Python 3.10 and GDAL v3.12.3 uses Python 3.12, including:

• Numerous Python dependency conflicts
• numpy versions >= 2.0.0 are incompatible with the GDAL v3.12.3 Docker image. numpy and scipy were forced to downgrade after the Python packages were installed via Pipfile.
• Python 3.12 manages packages in a virtual environment which made them unable to be found.
• A change in gdal_rasterize caused 0s to be written as nodata which tripped up fim_pipeline.sh.
• Incompatibility between TauDEM v5.3 and GDAL v3.12.3 resulted in an Error message. The outputs are still valid so the error message was suppressed.

In addition, an upgraded pdal was added to the Dockerfile and pillow was upgraded to v12.2.0.

Resolves #1735 and closes #1810.

Changes

• Dockerfile.dev and Dockerfile.owp: Upgrade GDAL base image to v3.12.3; adds system break flag for installing Python packages in an unmanaged environment; upgrades pdal; downgrades numpy and scipy
• Pipfile and Pipfile.lock: Upgrade and resolve Python dependencies and conflicts
• src/
  • delineate_hydros_and_produce_HAND.sh: Suppress GDAL Error message
  • run_by_branch.sh and run_huc.sh Suppress GDAL Error message and fix gdal_rasterize nodata issue

---

Testing

Built Docker images using both Dockerfile.dev and Dockerfile.owp and tested both by running fim_pipeline.sh on HUCs 03100204 and 12090301.

---

Deployment Plan (For FIM developers use)

• Does the change impact inputs, docker or python packages?

  • Yes
  • No (f no.. skip the rest of the Deployment Plan section)

• If you are not a FIM dev team member: Please let us know what you need and we can help with it.

• If you are a FIM Dev team member:

  • Please work with the DevOps team and do not just go ahead and do it without some co-ordination.

  • Copy where you can, assign where you can not, and it is your responsibility to ensure it is done. Please ensure it is completed before the PR is merged.

  • Has new or updated python packages, PipFile, Pipefile.lock or Dockerfile changes? DevOps can help or take care of it if you want. Just need to know if it is required.

    • Yes
    • No

  • Require new or adjusted data inputs? Does it have a way to version (folder or file dates)?

    • No
    • Yes
      • Require new pre-clip set or any other data reloads, such as DEMS, osm, etc. ie.. pre-requisite re-data upstream of your input changes.
        • Yes
        • No
      • Has the inputs been copied/exist in all four enviros:
        • FIM EFS
        • FIM S3
        • ESIP
        • Dev1

• Please use caution in removing older version unless it is at least two versions ago. Confirm with DevOps if cleanup might be involved.

• If new or updated data sets, has the FIM code, including running fim_pipeline.sh, been updated and tested with the new/adjusted data? You can dev test against subsets if you like.

  • Yes

Notes to DevOps Team or others:

Please add any notes that are helpful for us to make sure it is all done correctly. Do not put actual server names or full true paths, just shortcut paths like 'efs..../inputs/, or 'dev1....inputs', etc.

---

Issuer Checklist (For developer use)

You may update this checklist before and/or after creating the PR. If you're unsure about any of them, please ask, we're here to help! These items are what we are going to look for before merging your code.

• Informative and human-readable title, using the format: [_pt] PR: <description>
• Links are provided if this PR resolves an issue, or depends on another other PR
• If submitting a PR to the dev branch (the default branch), you have a descriptive Feature Branch name using the format: dev-<description-of-change> (e.g. dev-revise-levee-masking)
• Changes are limited to a single goal (no scope creep)
• The feature branch you're submitting as a PR is up to date (merged) with the latest dev branch
• pre-commit hooks were run locally
• Any change in functionality is tested
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future todos are captured in comments
• CHANGELOG updated with template version number, e.g. 4.x.x.x
• Add yourself as an assignee in the PR as well as the FIM Technical Lead
• Where applicable, has fim_pipeline been tested with multiple HUCs, including some other unaffected HUCs?

Reviewer / Approver Checklist

• Where applicable, has fim_pipeline been tested with muliple HUCs, including some other unaffected HUCs?
• If there are new inputs, have you confirmed that they have been copied to all enviroments?

---

Merge Checklist (For Technical Lead use only)

• Update CHANGELOG with latest version number and merge date
• Update the Citation.cff file to reflect the latest version number in the CHANGELOG
• If applicable, update README with major alterations