CITYOBJECT_ID vs ROOT_ID in the surface_geometry table about 3dcitydb HOT 2 CLOSED

Well, neither option 1 nor option 2.

You should store the individual gml:MultiSurface geometries of each boundary surface (bldg:RoofSurface, bldg:WallSurface and bldg:GroundSurface) as separate geometry hierarchies in SURFACE_GEOMETRY with each hierarchy having its own ROOT_ID. The CITYOBJECT_ID of each hierarchy references the boundary surface for which it is defined. So, in THEMATIC_SURFACE you reference the ROOT_ID of the corresonding geometry hierarchy for every boundary surface (e.g., using the LOD2_MULTI_SURAFCE_ID column), and the geometry hierarchy points back to the corresponding tuple in THEMATIC_SURFACE using the CITYOBJECT_ID.

The representation is thus like in the CityGML dataset: the geometries are associated with those features for which they are modelled.

If you also want a geometry for the building, then you can add a separate volume geometry in SURFACE_GEOMETRY whose ROOT_ID is referenced from the BUILDING table (e.g., using the LOD2_SOLID_ID column) and which points back to the tuple in BUILDING with its CITYOBJECT_ID. The polygons making up the volume would be copies of the polygons of the boundary surfaces. This is required because they cannot share the same ROOT_ID hierarchy.

In CityGML, the polygons are likewise reused by using XLink references from the building solid geometry to the polygons of the individual boundary surfaces (see CityGML specification and some example datasets at http://schemas.opengis.net/citygml/examples/2.0/building/). If you correctly use the IS_XLINK flag in SURFACE_GEOMETRY, then the XLinks can be correctly re-created when exporting the data.

My recommendation is to create simple example datasets and to use the Importer/Exporter tool to load them into the database. Then you can check how the tables have been populated and how the feature tables are linked with SURFACE_GEOMETRY. The Importer/Exporter tool is our reference implementation for the 3DCityDB.

Hope this helps.

from 3dcitydb.

In fact, I have done that: import a small dataset using the Importer/Exporter and analyse the tables created.

What I missed was the BUILDING_ID in the THEMATIC_SURFACE table. It is the one that solves my problem, as it allows to retrieve all the boundary surfaces making up a building. Therefore, there is no need to add the building in the SURFACE_GEOMETRY table, unless it has its own solid representation.

It all makes sense now.

Thank you very much for this detailed answer.

from 3dcitydb.