You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I utilized your tutorial to split a small watershed at the location of the gage. The geometry results of split_catchment do not match those of the NLDI get_basin. I pulled the NHD flowlines for high and medium resolution. It looks like the difference in geometry is associated with the difference in flowline resolution. Is it safe to assume that split_catchment does not use high resolution flowlines/DEM data for delineation?
What did you expect to happen?
I expected to be able to split the basin at the gage to get upstream watershed geometry that matches the NLDI get_basin geometry.
I was able to use split_catchment successfully on two other small watersheds with no discrepancies. It's possible I found an edge case with this specific gage? I wouldn't expect the difference to matter much on larger watersheds but it could potentially on small watersheds.
Is it safe to assume that split_catchment does not use high resolution flowlines/DEM data for delineation?
Right, the backbone network of NLDI is currently NHD MR. They are working on adding support for HR too. Currently, there aren't many web services that use the HR version since the network itself is still a work in progress and missing some important elements such as catchments.
Also, the source code for the split catchment functionality that PyGeoAPI uses is available here. You can install and work with it locally!
EDIT: I will look into the discrepancy that you mentioned and let you know if I find anything interesting.
What happened?
I utilized your tutorial to split a small watershed at the location of the gage. The geometry results of split_catchment do not match those of the NLDI get_basin. I pulled the NHD flowlines for high and medium resolution. It looks like the difference in geometry is associated with the difference in flowline resolution. Is it safe to assume that split_catchment does not use high resolution flowlines/DEM data for delineation?
What did you expect to happen?
I expected to be able to split the basin at the gage to get upstream watershed geometry that matches the NLDI get_basin geometry.
I was able to use split_catchment successfully on two other small watersheds with no discrepancies. It's possible I found an edge case with this specific gage? I wouldn't expect the difference to matter much on larger watersheds but it could potentially on small watersheds.
Minimal Complete Verifiable Example
MVCE confirmation
Relevant log output
Anything else we need to know?
No response
Environment
SYS INFO
commit: None
python: 3.12.8 | packaged by conda-forge | (main, Dec 5 2024, 14:06:27) [MSC v.1942 64 bit (AMD64)]
python-bits: 64
OS: Windows
OS-release: 10
machine: AMD64
processor: Intel64 Family 6 Model 186 Stepping 2, GenuineIntel
byteorder: little
LC_ALL: None
LANG: None
LOCALE: ('English_United States', '1252')
PACKAGE VERSION
async-retriever 0.19.1
pygeoogc 0.19.0
pygeoutils 0.19.0
py3dep 0.19.0
pynhd 0.19.0
pygridmet N/A
pydaymet N/A
hydrosignatures 0.19.0
pynldas2 N/A
pygeohydro 0.19.0
aiohttp 3.11.11
aiohttp-client-cache 0.12.4
aiosqlite 0.20.0
cytoolz 1.0.1
ujson 5.10.0
defusedxml 0.7.1
joblib 1.4.2
multidict 6.1.0
owslib 0.32.1
pyproj 3.7.0
requests 2.32.3
requests-cache 1.2.1
shapely 2.0.6
url-normalize 1.4.3
urllib3 2.3.0
yarl 1.18.3
geopandas 1.0.1
netcdf4 1.7.2
numpy 2.2.2
rasterio 1.4.3
rioxarray 0.18.2
scipy 1.15.1
xarray 2025.1.1
click 8.1.8
networkx 3.4.2
pyarrow 19.0.0
folium 0.19.4
h5netcdf 1.4.1
matplotlib 3.10.0
pandas 2.2.2
numba N/A
py7zr N/A
pyogrio 0.10.0
The text was updated successfully, but these errors were encountered: