Miss-match between HF-2.2 and 2.1 subsetting

[skoriche]

The Hydrofabric 2.2 and 2.1 sub-setting result shows noticeably different watershed size and outlet points for a given USGS-gage (see the two attached examples). Part of the mismatch could either be due to differences in version, but the basin size and outlet shown on water‑data also disagree with both subsets. I understand that additional number of nexus in HF2.2 could be present and the location might also be different between both versions. The other case could be if (I do not have info about this) the USGS-gage is moved to a different (one down-stream basin, as the HF 2.2 subset suggests—but I have not confirmed any change on the website or via the API. For reference, the map marks the gage’s current water‑data latitude and longitude with a red star.

[skoriche]

@mikejohnson51 @program--

[mikejohnson51]

That gage should physically be located where the red star is. The fact that the network splits at that point gives me confidence that the hydrofabric data is accurate. If you check the Hydrolocation XY coordinates, I’d bet they match that spot.

Regarding how the gage is indexed on the POI/flowpath network: we were specifically asked to index it to the downstream nexus to align with the data nudging approach. So, there’s a real distinction here between the gage’s physical location and its network representation—and that difference matters. While this headwater/simple example seems a little strange, it makes much more sense in more complex systems where flying water exisits and consistency is key across the full fabric.

In V3, when we introduce flowlines, this issue should become irrelevant. I’m aiming to have V3 ready by DevCon.

[skoriche]

Thanks for the quick clarification and explanation—much appreciated [@mikejohnson51]. That makes sense now.

If the gage is intentionally indexed to the downstream nexus (rather than its physical location) to support the data nudging workflow, then the subsetting behavior observed in HF v2.2 aligns with that design choice. In this case, it seems the entire area draining to that nexus—including the two catchments to the left—is masked in the subset, which explains why those catchments are grouped together. Just wondering if this is only the case for HF2.2 and the associated updates to the newer version of "[hfsubsetR]" modules?

As a result, the simulated streamflow over the subsetted area will naturally be higher than what’s observed at the gage itself, unless we extract the modeled flow specifically from the flowpath segment just upstream of the gage. I agree that this approach likely pays off in more complex networks with flying water, where consistency across the hydrofabric is critical.

Looking forward to the introduction of flowlines in v3—excited to see how it resolves this.

P.S.: I am going to check for all CAMELS basins and let you now if this is the case for other basins too.