The Wyoming/Montana USGS Water Science Center added a new set of equations to StreamStats that allow estimates of peakflow to be computed in Montana based on three types of channel widths. There isn't a way for StreamStats to estimate these channel widths based on GIS layers, so to get results from the channel-width-based peakflow equations, users need to enter a field-measured value for WACTCH and WBANKFULL, and enter a CHANWD_RS value. If values for these three basin characteristics are not populated, it affects the remainder of the peakflow report and the equations estimating peakflows from other basin characteristics will not be populated into the report.
We talked about using 0's as placeholders in the text field, then if users know the correct values they can edit them and if they don't the equations will still be calculated in the report. John mentioned this could maybe be done in the services to return a 0 to the client for those three characteristics, I think this could also be done in the client. We should decided to either do this in the client or the services and then close the repeat issue in the opposite repo.
The three characteristics are WACTCH, WBNAKFULL, CHANWD_RS.
The Wyoming/Montana USGS Water Science Center added a new set of equations to StreamStats that allow estimates of peakflow to be computed in Montana based on three types of channel widths. There isn't a way for StreamStats to estimate these channel widths based on GIS layers, so to get results from the channel-width-based peakflow equations, users need to enter a field-measured value for WACTCH and WBANKFULL, and enter a CHANWD_RS value. If values for these three basin characteristics are not populated, it affects the remainder of the peakflow report and the equations estimating peakflows from other basin characteristics will not be populated into the report.
We talked about using 0's as placeholders in the text field, then if users know the correct values they can edit them and if they don't the equations will still be calculated in the report. John mentioned this could maybe be done in the services to return a 0 to the client for those three characteristics, I think this could also be done in the client. We should decided to either do this in the client or the services and then close the repeat issue in the opposite repo.
The three characteristics are WACTCH, WBNAKFULL, CHANWD_RS.