-
Notifications
You must be signed in to change notification settings - Fork 14
2. Tutorial LoD1.3 building reconstruction
The gfc-lod13 repository contains the flowcharts necessary to perform LoD1.3 building reconstruction. This tutorial will explain how to use those flowcharts. If you haven't already read the Introduction to Geoflow first.
You can find a general description of the building reconstruction method in section 3 of this paper.
In short the method takes as input:
- one or more building footprints, and
- a classified point cloud with at least the building class and the ground class.
Based on this a 3D building model is automatically created in Level of Detail (LoD) 1.3. The model is exported as OBJ, CityJSON or GIS vector file (eg. GPKG, PostGIS).
The building reconstruction algorithm consists of many small nodes and many of these nodes have one or more parameters. In general these parameters will have sensible default values to work with the national Dutch AHN3 point cloud (~10pt/m2 density) and the BAG footprint dataset. However, when working with point clouds with different characteristics than AHN3 you may want to adjust some of the parameters. This is explained in the Parameter tuning section.
The gfc-lod13 repository repository contains a number of flowcharts, an example configuration file and a sample dataset. At the time of writing we are talking about these files:
-
reconstruct_one.json
: production flowchart with the algorithm to reconstruct a single building. Don't run this flowchart independently. -
runner.json
: production flowchart to sequentially reconstruct multiple buildings (eg. a 'tile'). Under the hood it loads thereconstruct_one.json
flowchart and runs that for each building. This is the one you would typically run to get results fast. -
config.toml
: An example configuration file that lists the global parameters relevant forrunner.json
. -
parameter_tuning.json
: A copy ofreconstruct_one.json
that is optimised for parameter tuning, eg. by adding Painter nodes at various stages so that intermediate outputs can be inspected interactively while tuning parameters. This one can be ran on its own. -
test-data
: An example input, eg. point cloud and footprints for a small area. These files are loaded by default when opening one of the above flowcharts (as long as you maintain the same directory structure as in the gfc-lod13 repository).
In order to run these flowcharts you need to install Geoflow and the necessary plugins. The easiest way to do this, is to install a binary distribution of geoflow-bundle, ie. see the geoflow-bundle Release page.
To perform the reconstruction for the test dataset and to verify if everything is behaving as expected simply run Geoflow with the runner.json
flowchart. Ie.
geof runner.json
on the command line or just open the GUI application, load the flowchart and click on 'Run all root nodes' (in the flowchart menu).
If everything works this should produce the following output files in the folder that contains runner.json
:
cityjson/1.json
cityjson/1.json
obj/LoD12_3D_1.obj
obj/LoD13_3D_1.obj
You can open these files in a compatible software to inspect them.
By default the runner.json
flowchart will write its 2D vector output to a PostGIS/PostgreSQL database. This means you need to set up such a database and provide the connection details to geoflow (see config.toml
file for details). If you don't provide these details the flowchart will crash when it tries to write to the DB. To prevent this from happening (in case you don't want to set up the database) you can simply select and delete the OGRWriter nodes in the runner.json
flowchart.
If you want to run with your own data you can specify several paramaters with the geof
command, either by passing them directly on the command line (append eg. --OUTPUT_FORMAT GPKG
) or by passing a configuration file that contains them.
For an overview of the available global parameters, please consult the example configuration file. You can override these parameter values either in the GUI (globals menu) or through the CLI.
Notice that any relative path will be treated as being relative to the location of the flowchart file (runner.json
). Of course you can also specify absolute paths.
When run as above the software will create 6 output layers (tables):
-
lod11_2d
: Input 2D footprints with elevation attributes (no groundpart separation as in LoD12) -
lod11_3d
: Input footprints extruded to fixed height (no groundpart separation as in LoD12) -
lod12_2d
: LoD1.2 output as 2D footprints with elevation attributes -
lod13_2d
: LoD1.3 output as 2D footprints with elevation attributes -
lod22_2d
: LoD2.2 output as 2D footprints with elevation attributes -
lod12_3d
: LoD1.2 output as 3D model -
lod13_3d
: LoD1.3 output as 3D model -
lod22_3d
: LoD2.2 output as 3D model
The attributes from the input are copied to the output features. In addition a number of attributes are added depending on the LoD. The LoD12 layer has the most attributes (best for analysis).
Attribute name | Description |
---|---|
dak_type |
Type of roof detected in point cloud (see next table) |
rmse |
Root mean square error between 3D model and input point cloud (only roof points) |
h_maaiveld |
ground elevation |
h_dak_50p |
roof elevation 50th percentile |
h_dak_70p |
roof elevation 70th percentile |
h_dak_min |
min roof elevation |
h_dak_max |
max roof elevation |
t_run |
total reconstruction time in ms (for all LoDs) |
roofplane_cnt |
number of detected roof planes |
roof_pt_cnt |
total number of points in roof planes |
wall_pt_cnt |
total number of points in wall planes |
usegmented_pt_cnt |
number of unsegmented points |
val3dity_codes |
val3dity error codes for the model given as a JSON array |
data_area |
area in footprint that has a roofplane above it |
data_coverage |
portion of the geometry covered by roof points |
error_his* |
histogram of errors measure from point cloud to mesh triangles |
m2pc_error_hist |
histogram of errors measure from mesh vertices to point cloud |
m2pc_error_max |
maximum errors from any mesh vertex to point cloud |
lod11_replace |
bool that indicates whether the LoD1.2, LoD1.3 and LoD2.2 output was replaced by a LoD1.1 model |
reconstruction_skipped |
bool that indicates whether full LoD1.2/LoD1.3/LoD2.2 reconstruction was skipped for this feature (and also LoD1.2 if lod11_replace==false ) |
is_ground |
bool that indicates if this part is a groundpart. If true the part is a ground part, otherwise it is a roof part (lod13_2d/lod22_2d only) |
labels |
semantic labels of triangles in the same order as they are stored in the geometry |
dak_type value |
Meaning |
---|---|
2 |
roof with at least one slanted surface |
1 |
roof with multiple, only horizontal surfaces |
0 |
roof with a single horizontal surface |
-1 |
no point was found for the building |
-2 |
could not detect a roof surface, even though points were found |
If you want to tune the reconstruction parameters to your own data, you can use the parameter-tuning.json
flowchart.
WIP