When ground points are missing underneath footprint

[esgn]

Hi again,

Sorry for another lengthy thread 😄

Generating first datasets with the develop branch of roofer, I noticed roofer has the same behaviour as geoflow when the lidar crop corresponding to a footprint contains only points classified as building.

These cases are easily spotted in results as reconstructed buildings are dropping well below the ground surface (see picture above).

I isolated the example above and ran different tests :

• Here are the cropped data produced by roofer (very useful feature). The crop.zip contains the lidar crop and the footprint.
• Using the develop branch I generated only the building using the filter option (another very useful feature 😉). The result cannot be viewed in ninja and the LOD0 and LOD2.2 geographical extent are way off in terms of altitude => tile_00000.city.zip
• I did a quick patch on StreamCropper.cpp here esgn@070566c to get the minimum altitude of all points inside the lidar crop and use it if min_ground_elevation is not set. The CityJsonSeq result tile_00000_v2.city.zip is valid and usable this time.

When grounds points are missing from the lidar crop I imagine the following options could be considered :

• Get minimum altitude from all points inside the lidar crop : Seems ok but could lead to anomalous case if no lidar point is near ground level (could result in floating building I presume). An advanced min_ground_elevation approach with a simple statistical approach could be of use here.
• Get minimum ground altitude from an attribute of the footprint : IGNF data model for buildings includes an altitude_minimale_sol (minimum ground altitude) attribute that could be of use here. It's a bit more advanced to implement I guess. However, it can also happen that this attribute is NULL on some of our buildings...
• Get altitude from the footprint geometry if it's a PolygonZ and if the Z coordinate is the ground altitude. It wouldn't work in our case as Z is at roof gutter level. I don't know if it could work for BAG for example.
• Find ground points in input LIDAR data near the footprint : I don't know if this is doable using the roofer codebase. This could also lead to anomalous results in some context I presume (very steep slope, ...).

👉🏻 Have you already considered dealing with this case ? It seems to me that different approach could be tested and if nothing works a fallback to error case would be possible.

👉🏻 If I were to look into getting minimum ground altitude from an attribute of the footprint : Do you think it is feasible with the current roofer architecture or is too complicated to deal with ?

Thanks for all you work,

[Ylannl]

Thanks for your thoughts on this. Indeed the current approach is not ideal in case the terrain has large variance in altitude.

• Getting the ground altitude from an attribute is feasible, and should not be too much work to implement.
• Getting the ground altitude from polygonZ is also feasible. In fact this is already partially implemented, but currently only usable through the API and not the roofer executable. It would be fairly easy to make this work in the executable too.
• Finding the nearest terrain point to a building (if outside of the ground buffer around the footprint) would be tricky with the current architecture.
• Getting minimum altitude from all points inside the lidar crop: while it may work for many buildings I imagine there are very annoying edge cases.

Another solution that maybe worth considering is to build a coarse terrain model (say ~5m resolution) while reading the pointcloud in the StreamCropper, and then interpolate from that.