C++ API

[ipadjen]

Working pull request

todo:

• Use footprint containing vertex elevation for building base
• Expose (some) reconstruction parameters (through a configuration struct probably?)
• Error handling? eg if reconstruction is not possible due to insufficient points
• Docs
• Tests
• Make it header only?

[balazsdukai]

• docs: see https://github.com/3DGI/roofer-dev/tree/develop/experiments/docs-doxygen
• tests: see https://github.com/3DGI/roofer-dev/tree/develop/experiments/tests-catch2
• expose parameters: I would use reconstructor-builder (eg ReconstructorBuilder) to configure the reconstructor that does the reconstruction :-). If we do bindings, it is also straightforward to expose the builder methods and still do the configuration in c++.

[Ylannl]

Some further remarks:

1. We discussed to make different reconstruction functions for different LoD's. In retrospect I think this should not be done, let's just keep the reconstruction API as simple as possible and provide one function (possibly with overloads, like you have now) that can do everything. Each LoD could still be reconstructed by using the right parameters. This means that the reconstruct app won't use the API, but this is ok.
2. Regarding lifting the floor of the building mesh. A good option here could also be to triangulate the input footprint (with vertex elevations), and then for each point in the mesh floor: locate it in the triangulation, do (linear) interpolation (I have some code snippets for this) and update the z of the floor vertex in the mesh accordingly. This would be quite robust I think. Especially in handling cases like when a polygon hole is created in the floor of the building during reconstruction (ie a hole that is not present in input footprint).

[Ylannl]

I added the most basic parameters.

There are a lot more parameters that could be added, but those are tricky to tune without looking at output of intermediate steps in reconstruction pipeline. So I started with the most basic ones here that are easy to understand and not dependent on the quality of the point cloud. These should be sufficient for most use cases.

Ideally we can in the future have a method to automatically judge the point cloud quality (eg based on pointdensity, and planarity) to set the quality dependent parameters automatically to sensible values.

[Ylannl]

For later reference, some things to look at/consider.

[Ylannl]

we could also do this using templates/concepts

[Ylannl]

remove?

[Ylannl]

Probably better to define a concept for Footprint

[Ylannl]

use the roofer::logger

[Ylannl]

As mentioned before, consider use a concept for ElevationProvider (?)

[Ylannl]

remove?

[Ylannl]

FYI I merged this now, to keep the code in sync with other developments. I suggest we open a new PR for the API for the remaining work.