Urban flood risk mitigation model (area of analysis)

Dear InVEST Enthusiasts

I would like to know what could be the best option to delimit the analysis area, I am only going to select the watersheds of my interest for it.

In this case, is a small city (in the northern Amazon in Colombia) delineated in black, it is between 2 microbasins, but is in the middle of a wetland area (white-shaded). The main rivers flow south-north and west to east.

The criteria to delimit the area could be (see photos A and B):

a).take the microbasins 1 and 2 where the city is located plus the surrounding adjacent basins 3 to 11, because they take sections of the most important rivers in the area.
b). take just the delimitation of the wetland area
c). Take the basins where the wetland area is included

d). (See photo C) Take the layers (1-5) that correspond to the official hydric zoning in this area

Considering the option to select, could you recommend to me which soil group layer (Future water or ORNL-DAAC’s ) would be the most suitable to continue elaborating the model?

Best regards and thanks so much


Hi @Diego_Guarin -

With the caveat that I’ve not used this model in an analysis, I’ll note a few things based on my understanding of the model and inputs.

Since the Urban Flood Risk model does not route water down the flow paths of the landscape, it does not quantify how, for example, upslope wetlands might reduce flooding for a downslope city. It only shows how much local runoff and retention is provided by each pixel/land cover type, the fate of which is unknown. Because of this, I would think that it’s less useful to include larger surrounding watersheds in your analysis. If you wanted to get a better idea of how the larger watersheds and wetlands regulate water flow to the city, a different, routed model would be better, like the Seasonal Water Yield model, or other more complex ones that aren’t part of InVEST.

On the topic of the soil group layer, it’s really up to you to decide which one seems like the best match for your landscape. Both are coarse, and, when I’ve compared them in my projects (this input is also used for Seasonal Water Yield) they are often rather different in a given area of interest. If you have more local information or expertise about soil types and their runoff potential, then you could use it to determine which of the global layers represent your soils most accurately.

I’d be very interested to hear the views of others who have more extensive experience with the UFR model.

~ Stacie


Dear Stacie,

Thanks so much for your response, I will consider the points you mentioned to run the model and I will let you know how it works.

Also, It would be interesting to hear the views of others.



UFR model test.zip (193.3 KB)

Dear Stacie @swolny

I ran the model just to see how it works as a test, but when running, the error seems to be in the Biophysical table Empty or Nan values were found in the table.

The table has some empty cells because there is no data based on the ESA Worldcover classification, so I tried to fill the empty files with “0” or delete the no data file, but there was always the same.

I will try to use the USGS classification to see the difference.

But meanwhile, if you can indicate to me where the error is, I would really appreciate it.

I attach the files, to check what is still missing. Thanks so much


Hi Diego -

Looking at the biophysical table bioph - copy1_6.csv, I see two things that need to be changed.

First is probably related to the error. Even though your 0 values represent NoData, you must assign values to CN_A, CN_B etc. You can just give them values of 0. But they cannot be empty.

Second, as noted in the User Guide, the values in the CSV table must be separated by commas, but the ones in bioph - copy1_6.csv are separated by semicolons. I know that this caused problems in previous versions of InVEST, not sure if it still does, but it would be a good idea to use the recommendations in that User Guide entry, and check to make sure that the values are actually separated by commas.

~ Stacie

Dear Stacie @swolny

I changed the semicolons to commas and saved the CSV files as normal but when I run the model I get the error: Missing a row in the biophysics table for lucode (0).

I send you 2 CSV tables with their log files, and if you could tell me what is the error in those tables I would appreciate it.

I really don’t know why this error occurs, since I have taken as an example other CSV tables from other users, but I have not found differences with those.

Thank you very much again and have a nice day



bioph _ test_2 (1).csv (284 Bytes)
bioph_test 1.csv (287 Bytes)
Test_1_InVEST-natcap.invest.urban_flood_risk_mitigation-log-2023-05-04–13_04_19.txt (3.4 KB)
Test2_InVEST-natcap.invest.urban_flood_risk_mitigation-log-2023-05-04–12_42_22 (1).txt (3.4 KB)

Based on these tables, it doesn’t really make sense why it’s giving that particular error, the table appears to be formatted correctly and have a row with lucode of 0. Since this is an older version of InVEST, just in case this is a bug that’s been fixed, would you please try the latest Workbench (3.13.0) and see if the error still happens?

If it does still give the same error with the latest Workbench, it might be best to send me all of your inputs so I can look more closely. The best way to do it is this:

1/ In InVEST Workbench, go to the tab where you’re entering your model inputs.
2/ Click on “Save As…” in the left side of the screen.
3/ In the “Datastack options” window that appears, click on “Parameters and data”.
4/ Give the output file a name (leaving it as the default is fine too), and make sure that the file extension is “.tgz”.
5/ Save the file and send it to me at swolny@stanford.edu.

~ Stacie

Dear @swolny

The model is not working with the latest workbench 3.13.0 either :frowning: I was working with the workbench 3.11 before.

Then I am sending you the .tgz file to your email under the subject: Consultation: Problem with_UFRM_Biophysical table.

Thanks so much



Hi @Diego_Guarin,

I’m with the NatCap Software Team. Stacie forwarded me your data and it looks like there is a bug in the model that doesn’t allow for the Biophysical Table to have rows of all 0s. To work around this, it would be easiest to define the nodata value of your LULC raster to 0. Then, remove that corresponding row from the Biophysical Table. I went ahead and did this and would be happy to send that data along. Let me know if it’d be okay to attach it here or if you’d prefer I send it another way.

Having made those edits to your files I ran the model again. It looks like in your Soil Hydrologic Group raster, there are values of 12, 13, 14. That raster must only have values of 1, 2, 3, 4. Here’s some documentation on that.



Dear @dcdenu4 Doug

Thanks so much for your response, yes please you can attach here the file, no problem, and regarding the Soil Hydrologic Group Raster I was using the Hydrologic Soil-Cover Complexes classification (see attached image) and not the Hydrologic Soil Groups classification, it was also a mistake on my part.

Thanks again and I remain attentive.

Have a nice day


Hey @Diego_Guarin,

Find attached the updated LULC raster with nodata set as 0. I’ve also attached the corresponding biophysical table with the row removed. Let us know how it goes!

gg-nodata.tif (39.0 KB)
curve_number_table_path_csv_without_nodata_row.csv (265 Bytes)



Dear @dcdenu4 and @swolny

Thanks so much ! It worked as a test, but without the Built Infrastructure Shapefile, but when I run the model with the Built Infrastructure Shapefile , it does not work . I attach the log file
for your review

InVEST-natcap.invest.urban_flood_risk_mitigation-log-2023-05-16–18_20_50.txt (2.6 KB)

Many thanks :slight_smile:


Dear @dcdenu4

I updated the fields of (type) in the attribute table of the built infrastructure Shapefile to combine them with the damage, however when running the model an error “not a string” appears.

I attach the logfile .txt and the csv table City_polig_rep of the attributes of the built infrastructure (there are some empty or incomplete spaces) could the error be due to those fields? If so, which ones should be deleted, or how should be completed?
I also attach the damage loss table Damage table_neu.

Thanks so much again

InVEST-natcap.invest.urban_flood_risk_mitigation-log-2023-05-17–12_28_48.txt (2.9 KB)
Damage_Table_neu.csv (38 Bytes)
city_polig_rep.csv (6.5 KB)

Looking at those tables, I wonder if the model is being case-sensitive with the field names. Try changing the field name “Type” to “type” and see if it helps.

However, this error actually appears to be related to “reproject_vector”:

ERROR Something went wrong when adding task reproject built infrastructure to target SRS (11)

in which case the problem might be with the coordinate system of city_polig_rep.shp. Often, the model catches coordinate system problems with error messages that are a bit more useful, but please double-check the coordinate system of that layer, and make sure that it’s exactly the same as your other spatial layers. If they appear fine, please upload city_polig_rep.shp so we can check it out.

~ Stacie

1 Like

Dear Doug @dcdenu4 and Stacie @swolny

I ran the model, I took a smaller area than the last time, and it works, thanks so much I attach the logfile here:

InVEST-natcap.invest.urban_flood_risk_mitigation-log-2023-06-17–14_25_53.txt (12.4 KB)

But I have a question looking at the *flood_risk_service_urb_*values there are not variations between the categories, is that ok to obtain such results without notorious differences? see attached image

Also, in order to interpret the results, it is better to display in single band pseudocolor? or in unique palette values.

Since this is the first time to run such a model in this region, it is only intended to show the amount of local runoff and retention provided by each pixel/land cover type. Based on the results obtained I would like to know if they can be taken as suitable to be interpreted and analyzed as a first approach.

Thanks so much again and have nice day



Hi Diego -

I would expect the aggregated results to be different for each polygon in your Area of Interest input. It looks like you used “study_area.shp” as your Area of Interest data - does that contain multiple polygons, or just one? If just one, then you will only have a single value and there will be no variation.

If “study_area.shp” does contain multiple polygons, are the values in the attribute table of flood_risk_service_urb.shp different for each polygon, or are they the same? If they’re different, then it’s just a matter of working with the GIS symbology to visualize them correctly. If the model output values are all the same for all of the polygons, then that’s strange and we would probably need to look more closely at your inputs and outputs to see what’s happening.

~ Stacie

Dear Stacie,

Yes, I have selected the polygons of the area where it can be better differentiated the values of flood_risk_service_urb. See image.

The values of: Runoff_retention_m3, Runoff_retention_urb, and Q_mm_urb did not change. They are the same as in the picture of the previous message.

I attach also the logfile for your review

InVEST-natcap.invest.urban_flood_risk_mitigation-log-2023-06-20–14_38_30.txt (16.8 KB)



Ok, so the different area of interest polygons do have different values, that’s good. In the previous map showing Runoff_retention_urb I also see differences across the study area, which should correspond to a large degree with the different land cover types. So do you still have concerns about the results?

~ Stacie

Dear Stacie

Thank you very much, :slight_smile: Yes, indeed, I have some doubts about the interpretation of the results, in fact, I would like to send you a brief explanation by email just to know if I am interpreting them correctly.



Honestly, I don’t have much experience with this model, so am not the best person to critique results. Is there someone else with more experience who can help? If not, I’m willing to sanity-check, but might need to call in reinforcements.

~ Stacie