valley bottom output when buffer size is vastly overestimated

[kbartelt]

While running VBET for the Middle Owyhee watershed I used a very high large buffer size amount... Below shows an example of the VBET output:

Has anyone had this happen before? @Albonicomt @MatthewMeier

It looks like the slope of the hillslope did initially cut off the polygon as intended, but then when the landscape flattens out again it is included in the valley bottom.

@wally-mac @joewheaton and I were wondering how much you can overestimate for the buffer parameters before you run into this.

Link to data: https://usu.box.com/s/uer2j50szrpl287cwhen67enl5ewrayl

Unfortunately I don't remember what parameters I used because I ran this a while ago.

[wally-mac]

Wow! This is the first time I have see this type of valley bottom output. Thanks for sharing! I guess there is an upper limit to how much one can overestimate valley width. I think we should revisit running VBET in this watershed with a more standard valley width and see what the results are. Mic once your workload mellows out can you give this a go and please keep track of the parameters you use? (BTW: it would be great if future version of VBET would store the input parameters for you).

On Tue, Oct 30, 2018 at 5:05 PM kbartelt notifications@github.com wrote:

While running VBET for the Middle Owyhee watershed I used a very high large buffer size amount... Below shows an example of the VBET output:

[image: image] https://user-images.githubusercontent.com/39836333/47754614-19f19000-dc61-11e8-83ef-b037cc42299b.png

Has anyone had this happen before? @Albonicomt https://github.com/Albonicomt @MatthewMeier https://github.com/MatthewMeier

It looks like the slope of the hillslope did initially cut off the polygon as intended, but then when the landscape flattens out again it is included in the valley bottom.

@wally-mac https://github.com/wally-mac @joewheaton https://github.com/joewheaton and I were wondering how much you can overestimate for the buffer parameters before you run into this.

Link to data: https://usu.box.com/s/uer2j50szrpl287cwhen67enl5ewrayl

Unfortunately I don't remember what parameters I used because I ran this a while ago.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Riverscapes/RCAT/issues/11, or mute the thread https://github.com/notifications/unsubscribe-auth/AU-QUoxFVbYN_lBmO0sPg5ENteZtDlrJks5uqNs0gaJpZM4YDCsB .

-- Wally Macfarlane 435.512.1839

[MatthewMeier]

@kbartelt I have never seen this before but it seems like the perameters that you are using are too large for the network. It looks to me like you minimum or small buffer is correct. However your medium buffer is to large. I have never seen this happen before. For further documentation on the perimeters to use or average ranges of values refer to the documentation that Jordan Gilbert produced found here.

[Albonicomt]

@kbartelt, I haven't seen this happen as extensively as your screen shot shows. I have seen similar patterns occur on a much smaller scale. Although it could make sense if you are running a valley bottom in an area similar to yours, where the main river system has cut a canyon and outside the canyon has relatively low changes in slope. Based on what I know on how the VB tool uses the slope threshold to further refine the valley bottom, it would make sens that the area between the active river system and the canyon walls are eliminated, but that portion of the Buffer that extends over the canyon walls onto the "flatish" land above "flatish," meaning the land that has slope values below your slope threshold.

This is interesting and a cool discovery on the limitation of the Valley Bottom tool. It does look as if, depending on the basin, there is a limit to how large you can make your VB buffer parameters, although I wonder how much you can play with the slope threshold to further adjust the "Over-Buffer-Effect".

You can look up your parameters in the xml document the tool creates. I will take a look and see if I can find them. For future runs, to better record your parameters, I would suggest including them in your outputname. I believe that is Scott's style of record keeping, he's really good at keeping track of all the metadata.

For example: When filling out your output name, include all the adjustable parameters in the output name, to help you keep track of your parameters. "Huc#_ValleyBottom_Unedited_100_50_20_10_3_5_15"

[Albonicomt]

@kbartelt, It looks like you have two runs of this watershed based on your xml. here are screen shots of both runs with your parameters. Which run is your screenshot above?

[kbartelt]

@Albonicomt thanks for looking into this. That is good advice to include the parameter values in the output name.

The screenshot is of the valley bottom shapefile that was used as a BRAT input. I just checked the xml for the actual shapefile rather than the VBET project xml and I don't see the parameter values stored there, but from the file creation time I am pretty sure it was the first of the two runs.

Sorry for the lack of documentation with this... I'll make sure to do that in the future.