Issues with Prerequisites for Downloading BRAT - Mesa Verde NP

[joewheaton]

Just shoving a conversation from email up here that could be helpful for others troubleshooting.

​On Mon, Aug 20, 2018 at 9:02 AM Braden Anderson banderson1618@gmail.com wrote: No, it wouldn't be a problem at all. Just a reminder, you'll need to delete the segments from the network in the inputs, and then run the BRAT Table tool again. It might be easier to clip the input network to the area that you care about, rather than deleting segments by hand, but I'll leave that up to you.

Cheers, Braden

On Mon, Aug 20, 2018, 8:43 AM Angela Yragui angelayragui@gmail.com wrote: I see, yes I was looking for the wrong name. I found my table and examined the attribute data, sorting iGeo_Len from smallest to largest. There's many (100+) segments that have the value of 0 for iGeo_len, iGeo_ElMax, iGeo_elMin, and iGeo_Slope. Selecting them in the attribute table shows me on the map that they should not have the value of 0. I took a screenshot of this so you can see what I'm looking at.

I only care about the BRAT model for Mesa Verde National Park, which you can see is the black outline in the screenshot. Since these segments with iGen_Len of 0 are outside of the park, would it be problematic if I deleted those segments?

On Fri, Aug 17, 2018 at 10:33 AM, Braden Anderson banderson1618@gmail.com wrote: The tool should have created a shapefile for BRAT, and then started calculating the attributes for it. The file would be named whatever you gave for the following input: "Name BRAT table output feature class". It would have been one of the last fields entered when you ran the BRAT Table tool. Maybe you weren't looking for the right name?

The input in question is the 300m Reaches input, yes. I'm not sure how small they need to be for the program to round them to zero, but I think that any segment smaller than a meter can probably be deleted.

On Thu, Aug 16, 2018 at 5:18 PM, Angela Yragui angelayragui@gmail.com wrote: Thank you Braden. I wasn't able to find my BRAT_Table.shp, I think probably because the tool wasn't able to execute?

Is this input referring to the 300mReaches flowline input? If so, the attribute table has values that are small enough they would round to 0 for StreamLen, SegLen, and ReachLen. I'm not sure why that would happen but maybe that's my issue.

Thanks, Angela

On Thu, Aug 16, 2018 at 4:55 PM, Braden Anderson banderson1618@gmail.com wrote: Hey Angela,

This is an odd one. I've looked into the code, and the "0" that's causing the division by zero error is the attribute "iGeo_Len". That attribute is meant to represent the length of a segment in meters. I don't know how a segment ended up with a length of 0. This could be a problem with the input, or a problem with how we calculate that attribute.

If I were you, I'd go into the attribute table of the BRAT Table output (if I remember right, this is after we changed the folder structure, so it should be in the 01_Intermediates folder, which is in the Outputs folder, which is in the project root. I've attached a picture, with the location of the BRAT Table circled in red). Once you have the attribute table open, sort the table by the attribute "iGeo_Len", from smallest to largest. If there's a value of zero for a segment that obviously shouldn't be 0, then we have a code problem. If there's a zero for some random segment that's so short that it was rounded down to 0, then the answer is probably to just delete that segment from the input.

Let me know what you find. Hopefully this helps.

Cheers, Braden

On Thu, Aug 16, 2018 at 4:41 PM, Angela Yragui angelayragui@gmail.com wrote: Hello all,

I'm hoping one of you may be able to help me with a new BRAT problem I'm encountering. Sara helped me immensely earlier in the week with a data preprocessing step (thank you!) but I didn't know who to direct this next question to.

I'm using version 3.0.10 and currently attempting to run Step 2 BRAT Table. These are my results: Executing: BRAT_table_tool "C:\Users\tspector\Documents\Yragui_BRAT\Project Folder" # # # C:\Users\tspector\Documents\Yragui_BRAT\Flowline_300mReaches_Proj.shp C:\Users\tspector\Documents\Yragui_BRAT\DEM_copy.tif # C:\Users\tspector\Documents\Yragui_BRAT\evt_copy.tif C:\Users\tspector\Documents\Yragui_BRAT\bps_copy.tif # # # # # Output_Network #

Start Time: Thu Aug 16 16:01:46 2018

Running script BRAT_table_tool...

Adding "iGeo" attributes to network

Traceback (most recent call last):

File "", line 307, in execute

File "C:\unzipped\pyBRAT_3.0.10\BRAT_table.py", line 108, in main

igeo_attributes(seg_network_copy, inDEM, FlowAcc, midpoint_buffer, scratch)

File "C:\unzipped\pyBRAT_3.0.10\BRAT_table.py", line 267, in igeo_attributes

row[3] = (abs(row[0] - row[1]))/row[2]

ZeroDivisionError: float division by zero

Failed to execute (BRAT_table_tool).

Failed at Thu Aug 16 16:05:49 2018 (Elapsed Time: 4 minutes 3 seconds)

Any suggestions as to how I can get around this would be much appreciated!

Thanks,

Angela Yragui

On Thu, Jul 5, 2018 at 2:31 PM, Angela Yragui angelayragui@gmail.com wrote: Hi Sara,

Thank you so much for your advice. I'll take your suggestions and run with them! My mapping/data collection won't be done for few weeks and then I'll be giving the BRAT a try. You may hear from me again if I run into issues, I hope that's okay with you!

If you're interested to see how it turns out with this method let me know and I can update you.

Thanks again, Angela Yragui

On Thu, Jul 5, 2018 at 12:46 PM, Sara Bangen sara.bangen@gmail.com wrote: Hi Angela,

To answer your questions about incorporating your own vegetation data, the short answer is yes that should work. I myself haven't done this, but as long as you follow GIS 'best practices' for merging raster layers you should be good. A few things to note:

Sound like your data is a mix of points and polygons. To convert these to rasters you'll want the cottonwood points as a polygon. If it were me doing this, I would also check to see if the Landfire data already as the cottonwood point locations mapped as cottonwood. Since you are not mapping all the vegetation in your study area you will need to merge your veg data with the Landfire data. The model will not run properly if there are vegetation data gaps within your study area. As Braden pointed out, in order to run the capacity portions of the BRAT model, you will need to add a 'VEG_CODE' field to your vegetation input rasters (see 'Vegetation Input Rasters' on this page).
If you to run the entire BRAT model (i.e., the human-beaver conflict potential model, conservation-restoration model) you will also need a land use raster with specific additional fields coded. We tend to use the Landfire EVT raster as our land use raster (see 'Land Use Raster' on the above linked page). Hope that helps, Sara

On Thu, Jul 5, 2018 at 10:49 AM, Braden Anderson banderson1618@gmail.com wrote:

---------- Forwarded message ---------- From: Braden Anderson banderson1618@gmail.com Date: Thu, Jul 5, 2018 at 11:49 AM Subject: Re: Issues with Prerequisites for Downloading BRAT - Mesa Verde NP To: Angela Yragui angelayragui@gmail.com Cc: Wally Macfarlane wally.macfarlane@gmail.com, Joe Wheaton Joe.Wheaton@usu.edu, "Spector, Tova" tova_spector@nps.gov

Hey Angela,

Our coworker Sara Bangen worked more closely with the part of the code responsible for vegetation data, so I'll forward this to her to make sure I don't get something horribly wrong.

That said, I think that should work. The important thing is to make sure the field with the 0-4 scale is named "VEG_CODE", because that's how the code looks for that value.

Cheers, Braden

On Thu, Jul 5, 2018 at 11:26 AM, Angela Yragui angelayragui@gmail.com wrote: Hello again,

As I'm familiarizing myself with the BRAT model more, I'm having some questions come up as to how I can best use it for my specific project and I'm hoping you may be able to offer suggestions.

We've decided to collect our own vegetation data for our study area instead of using the recommended LANDFIRE data. We've already collected GPS points on the Cottonwoods and are currently working to collect GPS polygons for Coyote Willow. These are our two species we have in the Mancos River Canyon that are "preferred" by beaver, and the rest of the vegetation is less preferred - herbaceous, shrubland, conifer, sagebrush - but we are not mapping it. I'm thinking that I can convert the vector data of cottonwoods and willow into raster format, possibly merging it with LANDFIRE data to fill in our gaps of what we aren't mapping, then classifying it on the 0-4 scale to make it suitable for use in the BRAT.

Do you think this will work or do you have any suggestions as to how I could make it work? Are you aware of anyone else who has tried to do it this way? Any thoughts on this would be much appreciated.

As an update to my status of the BRAT model download, I still have not been able to install it on the government computers but on my personal laptop I was able to download it without issue. Hopefully we'll figure it out soon!

Thank you, Angela Yragui

On Thu, Jun 28, 2018 at 7:14 AM, Angela Yragui angelayragui@gmail.com wrote: Braden,

Thank you so much for your quick response! I'm glad that from my question you were able to make some updates.

I am having an error code come up when I try to install the scikit-fuzzy module. It may just be something with our computers here so I'm going to have our IT guy come check it out. If he can't figure it out, I'll be contacting you again very soon!

Thank you, Angela Yragui

On Wed, Jun 27, 2018 at 1:03 PM, Braden Anderson banderson1618@gmail.com wrote: Hi Angela,

Thanks for reaching out to us. We're always happy to help, since questions like this help us understand places where our documentation might out of date.

Unfortunately, this is one of those times. NumPy_mkl is no longer a required dependency. To make sure, I ran through the entire BRAT process on a clean installation of Windows 10 and ArcGIS 10.5, and I didn't have any problems, despite never installing Numpy_mkl. We're sorry for the inconvenience. I'll update the webpage right after I send this email. Thank you for bringing this problem to our attention!

Scikit-fuzzy is still a necessary dependency, in case you were wondering. If you have problems installing that dependency, let us know, and we can help as best we can.

Best wishes, Braden Anderson

On Wed, Jun 27, 2018 at 9:32 AM, Wally Macfarlane wally.macfarlane@gmail.com wrote: Hi Angela,

I’m dealing with an injury at the moment so I’m passing you along to my colleague Braden Anderson.

Braden, see below and please respond.

Thanks,

On Wed, Jun 27, 2018 at 9:20 AM Angela Yragui angelayragui@gmail.com wrote: Hello Joe and Wally,

I am a GIS Tech/Biological intern at Mesa Verde National Park in Colorado. A part of my project is running the BRAT to assess the Mancos River for beaver habitat suitability, but I'm having trouble with downloading the prerequisites for the model.

I have ArcMap 10.5 installed. Pip is updated to the latest version. I've been following the instructions and video found on the Python Prerequisites page. (http://brat.riverscapes.xyz/Download/ComputerSetup.html)

When I try to uninstall numpy (so that I can install numpy_mkl), I get the message "Cannot uninstall 'numpy'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall."

I'm not familiar with python so I've been googling answers and the only possible solution I've come up with is manually deleting numpy, which seems like that might open up a can of worms.

Do either of you have any suggestions?

I'm looking forward to using the BRAT - it seems like a great tool! Thank you for providing it for others to use :)

Thanks, Angela Yragui -- Sent from Gmail Mobile Sorry for typos and brevity courtesy of my 'smart' phone.

-- Sara Bangen

[joewheaton]

Hi Angela, you can post to this thread by just creating a GitHub account if you don't have one already.

While clipping down to the national park is not a problem for summarizing and subsequent analysis, I would suggest it might be sensible to do after you've run everything and just do that as a summary step. At a minimum, DO NOT clip the watershed and DEM and Drainage Area raster until you've run the iGeo stuff and got your correct drainage areas. Otherwise, for any watersheds originating outside the park (if they occur) you will be underestimating drainage area → underestimating Q → underestimating stream power. For most of the streams this won't be a problem, but for any mainstems it could be.

I'm also excited to see you guys running this with your own vegetation data. I would highly recommend running with both LandFIRE and your own veg layers (as two realizations based off two different inputs). All to often, we presume that higher-res and higher-fidelity is better. It may be better, but only the comparison will reveal if it is necessary. We've also seen more sensitivity of the output to position of the channel (and subsequent buffers). You could have great vegetation data, but if the 1:24K NHD channel is still in the wrong place, you're not capturing it. Anyhow, let us know how you get on.

Best Wishes, Joe

[bangen]

Angela - I took a look at the data you sent me and the length fields created by the script are all quite small. This leads me to believe you ran the segment network tool before projecting your data into UTM. If that's the case you'll want to project your data before running any of the tools.

[angelayragui]

@joewheaton Thank you for posting this issue on GitHub.

Since I've been running into some issues, I decided to simplify my analysis and run the BRAT with the existing vegetation data from LANDFIRE. If I have time I'll be trying to run it with my own vegetation data. I will let you know how it goes!

Thanks for the tip about the position of the channel, do you have a recommendation as to how I can check for this?

@bangen Thank you for checking out my data - I didn't realize that everything needs to be in UTM. Luckily that's an easy fix!

[angelayragui]

Would anyone be able to help me with this error I'm getting? Step 2 runs for 2-3 hours, three separate times, then gives me this mesage:

Traceback (most recent call last): File "", line 307, in execute File "C:\unzipped\pyBRAT_3.0.10\BRAT_table.py", line 108, in main igeo_attributes(seg_network_copy, inDEM, FlowAcc, midpoint_buffer, scratch) File "C:\unzipped\pyBRAT_3.0.10\BRAT_table.py", line 258, in igeo_attributes zSeg('START', 'iGeo_ElMax') File "C:\unzipped\pyBRAT_3.0.10\BRAT_table.py", line 250, in zSeg zonalStatsWithinBuffer(tmp_buff, DEM, 'MINIMUM', 'MIN', out_network, outField, scratch) File "C:\unzipped\pyBRAT_3.0.10\BRAT_table.py", line 182, in zonalStatsWithinBuffer stat = arcpy.sa.ZonalStatisticsAsTable(tmp_buff_lyr, 'ReachID', ras, os.path.join(scratch, 'stat'), 'DATA', statType) File "c:\program files (x86)\arcgis\desktop10.5\arcpy\arcpy\sa\Functions.py", line 6380, in ZonalStatisticsAsTable statistics_type) File "c:\program files (x86)\arcgis\desktop10.5\arcpy\arcpy\sa\Utils.py", line 53, in swapper result = wrapper(*args, *kwargs) File "c:\program files (x86)\arcgis\desktop10.5\arcpy\arcpy\sa\Functions.py", line 6372, in Wrapper statistics_type) File "c:\program files (x86)\arcgis\desktop10.5\arcpy\arcpy\geoprocessing_base.py", line 510, in return lambda args: val(*gp_fixargs(args, True)) ExecuteError: ERROR 999999: Error executing function. Failed to execute (ZonalStatisticsAsTable).

Failed to execute (BRAT_table_tool). Failed at Tue Aug 21 10:18:55 2018 (Elapsed Time: 3 hours 5 minutes 47 seconds)

[joewheaton]

@angelayragui this one has been quiet for a while. Before we assign it, can you give is an update if this is still an issue for you? If not, I will close it down. If so, we'll see if anyone can help...

[wally-mac]

I'm closing this down because I do not see a reply from @angelayragui.