Find Areas at Risk of Flooding in a Cloudburst

Find Areas at Risk of Flooding in a CloudburstIn recent years, Denmark has experienced a number of sudden, extreme rainfall events. These events, known as cloudbursts, overwhelm stormwater systems and cause flood damage to homes and businesses. One way to help municipalities prepare for the next cloudburst is to map the “bluespots” in the landscape—low-lying areas without natural outflows. Planners can use bluespot maps to decide where preventive measures will best protect buildings and infrastructure.

In the new Find Areas at Risk of Flooding in a Cloudburst lesson on the Learn ArcGIS website, you’ll examine and run a geoprocessing model that finds bluespots in a study area near Copenhagen. You’ll then compare the bluespots to building locations. For more experienced users, a second model calculates the volumes of bluespots and estimates how much rainfall would be needed to fill them. The models can also be run with your own elevation data. Ready-made versions for both metric and U.S. units, as well as for situations where building footprint data is not available, are included with the downloadable data.

This Learn ArcGIS lesson was created by Dr. Thomas Balstrøm of the University of Copenhagen.

This entry was posted in Analysis & Geoprocessing, ArcMap, Hydro, Location Analytics, Public Safety, risk assessment, State Government and tagged , , , , , , , , , . Bookmark the permalink.

Leave a Reply

4 Comments

  1. richeymrr says:

    The “Find Areas at Risk of Flooding” model produced areas of flooding next to buildings (expected) and vertical red lines with spaces in-between (unexpected). Is the spacing due to the terrain of the DEM? The direction of the red lines are similar to the direction of the contours lines. I’m thinking as I write this, that that is what the model is trying to mimic. Thoughts,suggestions?
    Thanks, Mike-

  2. richeymrr says:

    Hi Tim,

    Thanks for submitting the detailed answers.

    ad 1) Correct – I consider diagonal flows as a possibility, so that’s why Region Group considers 8 neighbors.
    ad 2) Correct. If the DEM input is referenced in feet in the US models, you must multiply the volume calculation expression by 12 to get the result in inches.
    ad 3) Correct – no need to change the values in the attribute table. Just modify the label values.

    A shame this discussion wasn’t posted on the blog. Some other users might have enjoyed it.

    Regards, Thomas

    Tim:
    Thanks for the explanations. I believe I discovered the reason for the vertical banding being introduced. I wanted to get a quicker turn-around on some of the results, so I clipped a small area of the raster image. When I zoomed in on the DEM, I noticed a “one pixel width” white space where there was no raster data. This is probably the culprit.
    I just re-ran the bluespots on this small area on another computer and received this error.

    Hi Mike,

    I’m glad the results look better now. I wonder if the vertical banding might actually represent features of the topography, like ruts or channels of some sort? As I said, I’d be happy to look at your data if and when it might be useful – Thomas said the same.

    1. The original identification of bluespots happens in the raster environment. Thomas wanted diagonally-connected raster cells to be interpreted as belonging to the same bluespot. This is accomplished by setting the Number of Neighbors parameter in the RegionGroup tool to 8, illustrated in the image below left. However, in the next processing step, which converts the raster dataset to polygons, that diagonal connectivity is lost. The tool automatically converts diagonally-connected cells to separate features, as in the image below middle. The purpose of the Dissolve tool is to re-establish the diagonal connectivity. Since polygons 2 and 3 (middle) still have their their region group IDs—i.e., there is a field in the table in which both those polygons still have a GRIDCODE value of 2—they can be dissolved into a single polygon feature on that value (image below right).

    graphic wouldn’t post. (email me if you want to see it and I’ll email it to you) michael.richey@kcmo.org

    2. I don’t think the Identify Bluespots model has any unit conversion formulas in it. As long as your input cell size is correct (in the model environment settings) and your vertical accuracy parameter is correct, you should be fine. In the Identify Bluespot Fill Up Values US model, I think the only unit conversion formula is in the Calculate Field (3) process, where the fill up value is calculated as (Volume * 12 / Area) so the results are expressed in inches. The model should give correct results with no action on your part ASSUMING the units of your input data are feet. If the input values of your DEM are metric—which isn’t so uncommon in the US—then you would still need to run the metric version of the model and manually convert the results to US units after the fact. This is how it seems to me but I don’t feel 100% sure of myself, so Thomas might want to add his comments.

    graphic wouldn’t post. (email me if you want to see it and I’ll email it to you) michael.richey@kcmo.org

    3. If you use the Adjusted Fill Up Values layer file to apply the symbology, you would need to change the symbol labels. You wouldn’t need to make any conversions in your attribute table. (See if the image below is helpful.) However, since you said that you added a Fill+40 field to the table, I think you should avoid using the layer file altogether. Instead, just symbolize your output on the Fill+40 field and apply a yellow-to-red color ramp or some other graduated color ramp that you like. Your range values and labels will both be correct.

    graphic (email me if you want to see it and I’ll email it to you) michael.richey@kcmo.org

    Thanks for the information that the Fill Up model failed when you ran it across a network. I assume you mean all the components—the model and the data—were on a network drive. I think all our testing was on local installs of the model and the data. I haven’t heard other reports of the model failing when run over a network, but that doesn’t prove anything. I’ll try to look into this a little further. Thomas may have some knowledge about this because he has more firsthand experience with users running the model in his classroom.
    Tim

    Hi Tim:
    I added in the Fill+40 field per your suggestion for the “Bluespots Fill Up model”. Instead of just displaying only red, now there are a range of colors. That’s encouraging. Still getting some vertical banding of colors.

    A few questions:

    1 .Can you explain the BSPolyDissolved layer and it’s purpose?

    2. When running the “US” option, is a conversion being made in the model from Metric to US, or does a conversion need to be made on the data in the attribute table?

    3. Same question for symbology table. Since it displays in mm, I’m assuming I need to convert those values into US.

    Thanks, Mike-
    Ps. I ran both models across the network. The “Bluespots Fill Up model” crashed at the “Fill” step. The Models ran fine locally. Not sure if anyone else has had this issue.

    Hi Mike,

    Those results definitely look odd and I don’t have a good explanation for them offhand. If you want to share your model and data, I’ll be happy to look at it and see if I can figure anything out. You can share your model and data by making a geoprocessing package and sending it to me. If it’s too big, I can give you a Box location to upload it to. See A quick tour of creating a geoprocessing package for documentation. If it’s confusing, let me know and I can boil down the steps for you.

    As for the sewer system capacity value… I assume you’re running the Identify Bluespots Fill Up model, right? (Because that value doesn’t come into play in the other model.) There’s nothing built into the model to represent that number. The only thing that happens, in the last section of the Assess flood risk to buildings lesson, is that you apply some symbology which changes the way the fill up values are labeled.

    For example, if the calculated fill up value for a bluespot is 20mm, then that bluespot gets symbolized with the value 60mm. The underlying assumption is that if the sewer system can carry off 40mm of water, then it would actually take 60 mm of water to fill a 20mm hole. But this is represented only with the layer symbology, not with any values in the model.

    If you wanted to incorporate a sewer system value into your output attribute table, you could do that. Open the attribute table for the BSTouchBuildings layer, add a field, and calculate the field values to be FillUp + x, where x is the value you want to represent the sewer system capacity. Like this:

    graphic won’t display. email me if you want t osee it. michael.richey@kcmo.org

    Then symbolize the BSTouchBuildings layer on that attribute. Does it make sense to you?

    In reality, this kind of sewer capacity value is going to be an oversimplification, as I’m sure Thomas would agree. The capacity of the sewer system depends on where storm drains and pipe networks are located for one thing. Overflows in some bluespots may be handled efficiently while overflows in others may not. Also storm drains can get blocked, etc.

    Tim

  3. richeymrr says:

    Executing (Fill (2)): Fill c:\Cloudburst\ResourceData.gdb\Roa_bldg_clip c:\Cloudburst\Roanoke_bldg.gdb\AllSinksFilled #
    Start Time: Tue Dec 08 14:25:37 2015
    Succeeded at Tue Dec 08 18:56:13 2015 (Elapsed Time: 4 hours 30 minutes 35 seconds)
    Executing (Fill): Fill c:\Cloudburst\ResourceData.gdb\Roa_bldg_clip c:\Cloudburst\Roanoke_bldg.gdb\SmallSinksFilled 0.025
    Start Time: Tue Dec 08 18:56:13 2015
    ERROR 010298: Unable to allocate memory.
    ERROR 010067: Error in executing grid expression.
    Failed to execute (Fill).
    Failed at Tue Dec 08 18:56:14 2015 (Elapsed Time: 0.79 seconds)

  4. richeymrr says:

    I’m running the bluespot model on my 80 acre test area with 100 foot variations in elevation. “Fill (2)” took 6 hrs. to complete. “Fill” has been runnning for over 15 hrs. and I’ve seen the “blue” precentage bar hit 100% two times this am. Not sure what is going on. The model is being run locally from my PC, however the data is being accessed over the Network. Anyone else experiencenig delays like this ?