Interfacing BAGIS and PRMS5 - Subbasins

[jdduh]

New spec for the subAOI tool

1. Rename subAOI to subbasin throughout the BAGIS-P interface
2. The total area of all subbasins equals to the AOI area. That is, the AOI areas that are not within any user-defined subbasins form their own subbasin (with the same subbasin ID).
3. Add a new nsub table in the BAGIS-P output parameter file. The nsub table has a dimension of nsub with two parameters: hru_subbasin and subbasin_down. hru_subbasin is a unique sequential ID number for each subbasin. subbasin_down is the ID of the downstream subbasin whose inflow is the outflow from this subbasin.

[lbross]

Do you have any sample AOIs that contain subAOIs? It's been a while since I worked on this section of code.

Documentation on the original implementation.

[jdduh]

Please use this one: ftp://webservices.geog.pdx.edu/BAGIS/BAGIS_aois/animas_AOI_prms.zip You might already have this AOI, but this is a new version with several subbasins.

[jdduh]

Here is a screenshot of the AOI and its subasins. You can find 5 (sub)AOI folders in the AOI folder. The area that's not covered by any of the subAOIs is itself a subbasin.

[lbross]

I have questions on two of the items.

2. total area of the subbasins: Not sure what George wants here. Do we need to add another entry to the subbasins layer for everything that isn't in a subbasin with a different id? Do we record the subbasin areas somewhere in the parameter file? How is this supposed to work with item #3? Are these areas considered upstream or downstream of the most upstream subbasin?
3. Attaching proposed new table to see if I have it right. This would be the table generated from the allsub subaoi layer in Animas.

If you have a current template from George with these changes, that would help too.

[jdduh]

We don't need to create a subbasin for the areas that are not defined by a subAOI. Instead, we only need to assign a value to the nodata cells in the subbasin ID layer. The value, ideally, would equal nsub. There is no need to keep track of the area of the subbasins. In the example AOI that I provided, there are 5 user-defined subbasins. If a user uses all of them to create the subbasin ID layers, then the output ID layer will have 6 subbasin. The 6th subbasin is represented by the white color (i.e., nodata).

I don't understand this question. "Are these areas considered upstream or downstream of the most upstream subbasin?" I believe all user-defined subbasins will go all the way up to the AOI boundaries. There will be no non-user-defined subbasin upstream to a user-defined subbasin.

BAGIS-P output parameter file won't be directly compatible with PRMS5. I believe CSU team has developed a tool to ingest BAGIS-P parameter files for PRMS5.

Set 0 (zero) as the subbasin_down value for the most-downstream subbasin (i.e., the non-user-defined subbasin).

[lbross]

Ha! I am intentionally resetting the cells that aren't in a subbasin to null, so this should be an easy change. Should the undefined areas be considered an additional subbasin and be added to nsub? In our example, we have 5 subbasins. If we add the undefined area, nsub would be 6 and we can make that the subbasin id for the undefined area.

It sounds like the non-user defined subbasin (6) should be added as the last line on the new nsub table? And subbasin_down for 5 should be 6 and subbasin_down for 6 should be 0?

Should I expect this new table to be in the template? Or should I plan to add it?

[lbross]

Need to determine which AOIs are nested. Convert subaoi layer to polygon. Not sure how to determine nested aois and subbasin_down values. @jdduh to ponder how to do this with ArcMap tools. On hold until the 2021-2022 project year.

[lbross]

For now I will reclassify the undefined areas to the highest subbasin id + 1 rather than noValue.

[lbross]

Your question about CS4 reminded me that we need to be cognizant of the versioning for ArcMap. My ArcMap development environment is on CS3 and is 10.7.1. This means that the addIn "should" work for 10.7.1 or later. My laptop is still at 10.5.1. I could merge the changes from the main branch to a separate branch I maintain for 10.5.1 and I can test it on my laptop. But I don't want to do waste the work if we don't need a 10.5.1 version. Do you know what version of ArcMap George is using?

[lbross]

I have posted a subaoi.gdb.zip in the BAGIS/For Geoffrey folder on basins. This gdb contains the original allsubs layer and an allsubs2 layer where the undefined portion of the aoi is set to a unique subasin id. Please review and if the data is correct. You'll notice little slivers of the main AOI outside of the subaoi boundaries as we discussed last week. Let me know if I should publish a new add-in? And if so for which versions of ArcMap?

Another question: Do we want to update subaoi.gdb to subbasin.gdb? The only problem I can think of is that it would no longer be included in the ebagis upload unless Jarrett updates the code.

[jdduh]

George and NWCC are using ArcMap 10.5.1. Please keep the subaoi.gdb name unchanged. Once I have identified the cause of the slivers, I will provide additional spec for eliminating the slivers when we begin integrating PRMS5 into BAGIS (-H/-P).

[lbross]

This is done. I merged the code from the 10.7 branch to the 10.5 branch and built an add-in on 10.5. Because ArcMap is forwards compatible, this should also work on 10.7. I noticed on the FTP server that we only had a folder for 10.5 and later add-ins. This include the fix for issue #54, renaming subaoi to subbasin, and setting a value for cells on the subbasin layer that aren't in a subbasin.

Note that I changed the field name in all of the tables from subaoi_id to subbasin_id. This means that the subbasin layers will need to be regenerated before they can be used to generate/export parameter files. This shouldn't take long and I thought it would be better moving forward with the updated terminology.

[jdduh]

Seems to work as designed. I noticed that the ID field name is SUB_BASIN_ID. Just want to confirm that this is the correct field name used in the parameter export function. It's fine to name the field either as sub_basin_id or subbasin_id.

[lbross]

Great! Yes the ID field name is SUB_BASIN_ID. I maintain it in a constant variable shared by all the functions.

[jdduh]

Just notice that PRMS' subbasin ID parameter name is "hru_subbasin". Please use this name instead of SUB_BASIN_ID in the parameter viewer and the export file. There is no need to publish a new addin. I can ask the users to change the heading using a text editor for now.

[jdduh]

Ok, here is a bug that needs to be fixed. The addin needs to be republished. It seems that the hru_subbasin values in the output parameter file are based on the subbasin ID layer's VALUE field, not its sub_basin_id field. Here are some screenshots to support my oberservation.

Attribute table

Parameter Viewer Map

VALUE map

SUB_BASIN_ID ma p

[lbross]

Took longer than I thought, but this is fixed and a new addin posted. The values in the output parameter file have been incorrect probably since we created the tool. The field is renamed to hru_subbasin across all files. This means that the subbasin layer(s) will need to be regenerated to avoid runtime errors.

[jdduh]

With the new modification, users must specify an AOI as the input otherwise the tool will throw an error. Currently, the AOI folder picker gives a warning that the folder selected is not an AOI but allows the process to continue. Please stop the process if the user doesn't select a valid AOI as the input.

Note: this is not an urgent item. Put it at the end of your to-do-list.

[lbross]

Is this request for the subAOI tool? If so, I just tested and found that if I select a folder that isn't an AOI then all of the buttons are disabled so the process can't continue. Please let me know the order of events you find that are allowing the process to continue.

[jdduh]

Yes, it's the SubAOI Id tool. Please disable the Create SubAOI ID layer using selected subAOI(s) button if the user didn't select a valid AOI.

[lbross]

Got it. This was a bit of a corner case because the buttons were only enabled if the selected folder was NOT an AOI BUT did contain valid AOI folders. It is fixed and ready for the next BAGIS-P release.