Skip to content
This repository has been archived by the owner on Jun 1, 2023. It is now read-only.

FYI: Not all segments have HRUs #40

Open
jzwart opened this issue May 11, 2020 · 1 comment
Open

FYI: Not all segments have HRUs #40

jzwart opened this issue May 11, 2020 · 1 comment
Labels
wontfix This will not be worked on

Comments

@jzwart
Copy link
Member

jzwart commented May 11, 2020

There are 40 (out of 456) segments in the DRB without HRUs. PRMS-SNTemp pulls information from closest segments with HRUs for values such as segment rainfall, temperature, and cloud cover.
Not sure if this is an 'issue', but good to be aware of.

@aappling-usgs aappling-usgs added the wontfix This will not be worked on label Jun 15, 2020
@aappling-usgs aappling-usgs changed the title Segments without HRUs FYI: Not all segments have HRUs Jun 15, 2020
@hcorson-dosch-usgs
Copy link
Contributor

Jeff, Sam, and I had noted this same issue when considering how best to calculated area-weighted drivers (based on HRUs) for the DRB segments.

I can join the the segment identifiers table (nsegmentNationalIndentfier.csv, using the field seg_id_nat) to the segments shapefile (Segments_subset.shp using the field seg_id_nat). Then I can join the HRU identifiers table (nhruNationalIdentifier.csv, using the field hru_id_nat) to the HRUs shapefile (HRU_subset.shp using the field hru_id_nat). If I then join the the segments (using the field seg_id_reg) to the HRUs (using the field hru_segment), I get joins for 761/765 hrus - 4 near the bay don't match any segments. If I join the other direction -- HRUs (using the field hru_segment) to the segments (using the field seg_id_reg), 416 of 456 segments have matches.

For example, the highlighted segment here (seg_id_nat = 1811) doesn't have any HRUs associated with it, because those 3 teal ones that surround it are associated with the purple segment upstream (seg_id_nat = 1813):
InkedMicrosoftTeams-image_LI

For the forecasting work, we ended up skirting this issue by only calculating area-weighted gridMET for the 5 forecasted segments (each of which has 2 matched HRUs).

But if we want at least one matching HRU for each segment in the future, we concluded that the best approach would be to use a spatial join. This is the python workflow I'd outlined (and started to work on, but paused) after some experimentation in Arc:

  • Load in segment_subset shapefile and reproject as needed
  • Load in HRU shapefile and reproject as needed
  • Calculate the areas of the HRUs
  • Buffer segment_subset polyline by some distance, e.g., 100m
  • Intersect the buffered polygon with the hru polygons, retaining seg_id_nat and hru_id_nat as attributes
  • Calculate the area of each intersected polygon
  • Group the resulting intersect polygons by seg_id_nat and hru_id_nat and compute the total amount of overlap (sum of areas) between the buffered segment polgyon and each overlapping hru (b/c might be many small overlapping areas)
  • Convert those total overlapping areas to percentages of the total area of the buffered polygon
  • Filter out all grouped polygons that are less than a X percentage of the total buffered polygon area (e.g., 10%)
  • Pull the hru_id_nats associated with the remaining grouped polygons for each seg_id_nat

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

3 participants