Disproportionately high iVeg numbers in BRAT Table - Githubissues

Riverscapes / pyBRAT

pyBRAT - Beaver Restoration Assessment Tool (Python)

http://brat.riverscapes.xyz

GNU General Public License v3.0

10 stars 10 forks source link

Disproportionately high iVeg numbers in BRAT Table #140

Closed kbartelt closed 6 years ago

kbartelt commented 6 years ago

Hi @banderson1618

Can you take a look at my BRAT Table and output for the Middle Owyhee ( #136 )? I noticed a few areas with some unusually high vegetation and dam capacity outputs in areas with a VEG_CODE input of 1 and 2.

If you look in the circled area in the first photo above there are a few instances of this. Thanks for the help!

All of my BRAT inputs/ outputs/ a final layer package are located here.

bangen commented 6 years ago

@kbartelt I'll take a look at this and get back.

bangen commented 6 years ago

@kbartelt Quick question. Did you select the option to in the BRAT Table tool to segment by roads?

kbartelt commented 6 years ago

Great, thank you @bangen

I did not select segment by roads. Is that something I should be selecting for future runs?

bangen commented 6 years ago

@kbartelt No, let's not segment by roads. I was just checking in case there was an issue with the segmenting and the ReachID field not being updated properly (potentially resulting in duplicate/non-unique ReachIDs) which could affect our attributing workflow.

banderson1618 commented 6 years ago

I've been looking into this more, and... I still have no idea what the problem is. I can't find any good patterns for what areas get clearly wrong values, and those areas still get way too high values if I set it to take the minimum instead of the mean veg code. The problem pops up throughout the entire watershed, but somehow we've never seen it before in any other watersheds. For some reason, not a single reach has a value below 1, even though 0 is a possible value in the raster.

I'm honestly baffled. This doesn't make sense to me. I'm gonna take a break and look back at this in an hour, because I'm not making progress right now.

bangen commented 6 years ago

@banderson1618 in case you were looking into this again I wanted to let you know I found the issue. I'm going to make a video and will post it here.

banderson1618 commented 6 years ago

I'd be very curious to know what the problem was, if nothing else.

bangen commented 6 years ago

@kbartelt and @banderson1618

Good news, the issue wasn't with the code itself. The problem was the 'VEG_CODE' fields were created as text/string fields rather than as integer fields. You can check out this video here for the in the weeds info.

Karen, you'll need to re-create the 'VEG_CODE' field for the EVT and BPS rasters. Make sure the field type is set to 'SHORT' (which is type integer).

I'm going to close this issue for now. If you re-run and have further issues let us know.

kbartelt commented 6 years ago

Ah okay that makes sense. Thank you for the help!!

banderson1618 commented 6 years ago

Good catch, that's a subtle bug!