Rainfall surface elevation interpolation underneath viaducts

Gemeente_amsterdam Duco de Vries

Hi all,

I spotted some weird bumps in the surface elevation in Tygron (based on AHN4) created in the rainfall overlay. When comparing to the AHN4 it looks like it is just on the outside of the edges where there are gaps in the AHN-DTM. These "bumps" cause some odd result in the rainfall calculations. Is there a way to overcome this problem?

I uploaded a screenshot (1) with the DEM exported to QGIS, including a hillshade overlay and the calculated surface max value and (2) the AHN4

Thanks in advance

Len Geisler

Hi Duco,

This seems to be related to the bridges nearby. The Tygron software attempts to fill up the gaps in the DEM using other information. In this case the BGT bridges (or rail tracks) most likely.

For the top screenshot; Did you export the DEM elevation from the "Digital Terrain Model" overlay found in the "Topography" group or the "Surface Elevation" found in the "Step 6: Output Overlays" results of the rainfall Wizard? One is optimized for the water calculation and is the actual elevation used the other is more the raw information for general purposes in Tygron. They are ofcourse closely related. I also think there might be a resolution difference on the output which blurs the exact effect a little bit.

As a solution you can try. In the rainfall wizard there is an "Step 8: Advanced settings" setting you can change. The "include brdinges and flaoting buidlings in elevation" should be set to low. If you then look at the output overlay "Surface Elevation" in step 6 you will likely see less of the "bumps" and likely the water will also flow more freely between the bumps. This is the automated version of fixing this. The actual cause ofcourse is that there is no elevation data known in the source information. Filling this up manually will of course also result in different surface water flow.

Hopefully this answer helps to fix te problem!

Gemeente_amsterdam Duco de Vries

Hi Len,

The top screenshot is the "surface elevation" from the rainfall overlay. Actually the setting you mentioned was already set to low. Even when I upload my own DEM where I created a smooth surface, Tygron creates these bumps. However, these bumps seem to be related to the input in design_flood_elevation_m. The bumps cause a maximum difference of about the exact input I set under design_flood_elevation.

First I simply wanted to solve this by setting the design_flood_elevation to eg. 0,05 m, however this also affects the calculated "surface value". It looks like when the water rises above the floor level + the design flood elevation (in this case floor level +0,05 m), water can flow inside the building. This is assumption correct? Then it would actually be interesting to find the volume that flooded inside, would this be possible?

Thanks in advance!

Hedi

@Len Geisler

Len Geisler

Hi Duco,

Looking at your description and the Tygron version update notes it seems that you have stumbled on a bug.

• You describe that there's a relation between "designfloodelevation_m" and the metro lines. This attribute adjusts the elevation specifically for buildings like houses, flats, offices etc. but should not adjust constructions like metrolines.
• In the update notes 2022.5.2 (of the preview) I see this: "Bugfix for DEM in combination with metro lines.". This means that the problem is now fixed on the Tygron preview server. I can't reproduce it on the preview anymore. This might however mean that it is still on the LTS server. Hopefully this update also went live on the preview.

If the problem persists on the LTS there aren't many effective workarounds since you can't dictate the exact elevation grid with the same flexibility as the preview. I can think of some complex workarounds (with suboptimal results) but personally hope it's already solved on LTS aswell.

vincent.rd

Hello @Gemeente_amsterdam Duco de Vries and @Len Geisler ,

The issue you describe is caused by an incorrect artificial indent in the terrain where metro lines are present. This issue is already resolved on the preview server, and the fix will be rolled out in March to the LTS server too.

Regards, Vincent