Performance issues with XtoCityDB

[ChungTingLao]

XtoCityDB works in the following principle:

• the original data is usually a table/vector data with footprint geometry and height information
• the data is first uploaded to PostGIS as a table using GDAL
• SQL scripts are executed to convert the data into CityDB schema
• The data is further processed in the same way as CityDB data e.g. footprint extraction, 3D tile generation

Typically, the original data do not contain building geometry information beyond LoD1. The current XtoCityDB upload workflow automatically upgrades the data to LoD2. As a result, the speed of the XtoCityDB upload is always slower than uploading LoD2 CityDB data, despite the original data being simple.

Depending on the applications, LoD2 may not be needed, and the upgrade will bring additional cost with little benefit. Alternatives to XtoCityDB should be developed to allow efficient upload of simple building data when high level of detail is not required. This may either be achieved by modifying the XtoCityDB workflow or introducing a simpler alternative workflow.

[ChungTingLao]

In addition, footprint augmentation script can crash XtoCityDB upload. Postgres seems to be hanging at creating a table that is supposedly empty. The same script runs fine on equivalent CityGML.