Compatibility and Data Migration
The VC Database v5 is a major revision of the previous version v4. The database schema has been
completely redesigned and significantly simplified compared to v4 to support CityGML 3.0, while retaining
full compatibility with CityGML 2.0 and 1.0.
This page provides details on the compatibility of VCDB v5 with the VC Suite software stack. It also includes an
overview of the supported CityGML and CityJSON versions, along with a guide for migrating from VCDB v4 to v5.
Compatibility overview
The table below summarizes the compatibility between VCDB v4 and v5 and the related components of the VC Suite.
VCDB v3 is not included, as it is no longer recommended for production use.
| Software | Version | VCDB v4 | VCDB v5 |
|---|---|---|---|
VC Publisher |
6.x |
|
|
≤ 5.x |
|
|
|
VC Warehouse |
6.x |
|
|
≤ 5.x |
|
|
|
VC WFS |
≤ 4.x |
|
|
VCDB Importer/Exporter |
≤ 5.x |
|
|
VCDB Continuation Tools |
1.x |
|
|
vcdb-tool |
1.x |
|
|
To benefit from CityGML 3.0, the simplified database schema, and new features of the VCDB v5, a
database migration from previous versions of the VCDB to v5 is required. As a consequence,
some legacy tools such as the VC WFS can no longer be used.
|
Supported CityGML and CityJSON versions
Although the database schema is designed with CityGML 3.0 in mind, VCDB v5 remains backwards compatible, offering full support for CityGML 2.0 and 1.0.
Data can be managed without loss in VCDB v5 as long as the same CityGML version
is used for both import and export. Changing the CityGML version between import and export may result in
data loss, as CityGML 3.0 is not fully backwards compatible with versions 2.0 and 1.0.
For example, when importing CityGML 2.0 data into VCDB v5, you can be confident that it can be exported
back as CityGML 2.0 without loss. However, exporting to CityGML 3.0 might lead to data loss due to differences
in data models and supported features between the two versions. The vcdb-tool
automatically converts data between versions where possible and offers additional options to handle
differences on-the-fly when automatic conversion is not feasible (see below).
The same principles apply to CityJSON: Data can be managed without loss when using the same CityJSON version for both import and export. Changing versions may result in data loss unless automatic conversion is possible.
| CityJSON is a JSON-based encoding of a subset of the CityGML data model. As such, it is less expressive than the GML/XML encoding of CityGML, which may also contribute to data loss when switching between CityJSON and GML/XML. |
Upgrading CityGML during import and export
As mentioned above, the vcdb-tool performs automatic conversions between CityGML versions during import and export,
where possible, to minimize data loss. When automatic conversion is not feasible, the following options
are provided for the import and export commands to help upgrade deprecated CityGML 2.0 and 1.0 structures
into valid representations in version 3.0.
| Option | Description |
|---|---|
|
Maps LoD4 geometries onto LoD3, replacing any existing LoD3 geometries in the data. |
|
Maps LoD0 roof edge geometries onto roof surfaces with LoD0 surface geometry. |
|
Maps LoD1 multi-surfaces onto generic thematic surfaces with LoD1 surface geometry. |
|
When to use the upgrade options?
Whether to apply upgrade options depends on which CityGML version serves as the primary or target version in your
VCDB
|
The vcdb-tool does not provide specific options for downgrading CityGML 3.0 content to versions 2.0 or 1.0.
Therefore, CityGML 3.0-specific features, geometries, or attributes stored in VCDB v5 will be lost
when exporting to earlier versions unless an automatic conversion is possible.
|