5.1. IFC to CityGML Conversions
For IFC to CityGML conversion, mainly three software were tested (
Table 8) with different settings.
Most of the tests used
Safe Software FME algorithms, directly or as plugins in third-party software, such as
ESRI ArcGIS, with different scripts and configurations for the conversion (Some examples of how to use FME to make such conversion can be found at
https://knowledge.safe.com/articles/591/bim-tutorial.html).
Table 9 shows the details of such settings, together with the level of expertise of the participant using it (from L1—“beginner” to L4—“developer”) (L1—Novice user (nearly the first time using the software); L2—regular user; L3—expert user (knows very well technical details and less documented tricks); L4—developer of the tested software.). The column “Test ID” defines a code used in the following sections to report the related results. On the right part of the table, the converted datasets are reported.
Although the FME Quick translator is not recommended by the Safe Software vendors as a reliable option to perform complex transformations and conversions, it was used in several tests, mostly by non-expert participants. For this reason, the consequent results are included in this section as well. Some tests with FME Quick translator, in fact, reported that not all the features that were read were transformed (e.g., 3147 IfcTypeObjects out of 49826 features read for the UpTown.ifc dataset). Some explanation of this was given by the participants as for example, solids may be too complex, not closed or not orientable. Some solid geometry may be missing traits, appearance, measure or attributes. However, this has to be expected with such tool, mainly conceived to make simple format conversions (such as GIS-to-GIS), without the need of complex transformations or schemas mapping.
ESRI ArcGIS Pro was tested with its Data interoperability extension which implements an FME-based algorithm though, with the same readers as above.
Finally, the
IFC2CityGML tool [
9] was tested for IFC4 data (converting the data to CityGML v.3).
5.1.1. Specific IFC Geometries Conversion to CityGML
By inspection of the converted specific IFC geometry dataset, using 3D viewers, two main results were obtained:
- Case A
Everything is
GenericCityObject with
Lod4Geometry (see
Figure 2).
- Case B
Everything is building with
lod4Solid geometry, except for the yellow geometry (corresponding to the A5 geometry, see
Section 3.2.1) which is an
lod4multisurface geometry (see
Figure 3)
Not all the objects in the IFCgeometries datasets were converted (see
Figure 2 and
Figure 3). The geometries that were not converted are the ones generated by extrusions of crane rails (A-shapes), revolutions and swept disks. The A5 geometry, which is converted as
lod4multisurface in the Case B, is the only geometry modelled as a shell (namely, shell-based surface model, an explicit collection of faces). The other elements are extrusions, revolutions or results of boolean operations between solids. One boundary representation is in the IFC dataset (B1), however it is not stored as a shell but as a faceted boundary representation.
For some reason, the datasets where the objects were interpreted as
bldg:buildings with
lod4solid geometry (
Figure 3) appear to be mirrored with respect to the alternative conversion (as generic city object) as well as to the original file.
Only this dataset could be analysed within the geovalidation tools, since the others were too heavy, converted from both the IFC 2x3 version and IFC 4 to CityGML v.2. In
Table 10 and
Table 11 the most relevant results of the validations, and inspection, are summarised. It is possible to notice how few of the converted objects result in a valid geometry. Moreover, the results of
IFC2CityGML tool, producing a CityGML v.3 file could not be tested by val3dity, since CityGML v.3 is not supported. The semantic schema is instead generally converted to a valid output (although it was very simple, for those datasets, including few simple entities).
5.1.2. UpTown.ifc Conversion to CityGML
The converted
UpTown.ifc models (ranging between 1 GB and 1.48 GB) were too heavy to be validated with the previous tools. Therefore they were only inspected in the azul 3D viewer. In all the cases, everything is converted to
GenericCityObject with
lod4geometry. The information about the IFC entities is only stored in the attributes (e.g.,
Table 12). The attempt to visualize it in
FZK Viewer failed and only a line could be visualized.
5.1.3. Savigliano.ifc Conversion to CityGML
The
Savigliano.ifc model, in IFC 4, was successfully converted by
IFC2CityGML [
9] and the
FME Quick translator (
FME19qt-L1) as well. In addition, the dimension of the models (25.5 MB and 13.27 MB, respectively) does not allow to check their validity (geometric and semantic) by means of geovalidation tools.
When visualized in azul, we can see that the model converted by
FME maintains all of its parts without any attempt of harmonization: no selection of objects nor change in representation (i.e., each parallelepiped wall is still represented by means of 6 connected surfaces even though it is no more a solid but a multi-surface). Instead, everything is converted to
GenericCityObject with
lod4Geometry as geometry, with similar pattern to the Case A described in
Section 5.1.1. The top part of the building is missing (
Figure 4).
Similarly, the model converted by
IFC2CityGML also loses its top part. Moreover, the participants doing the test also report the loss of some elements, after conversion with the rule set (Note that while
IFC2CityGML supports multiple rule sets [
38], only one rule set was available for this task.) (
IfcStairFlight,
IfcSlab,
IfcRailing,
IfcDoor,
IfcWindow,
IfcBuildingelementProxy). As they notice in addition, most missing elements seem to be
IfcClosedShell objects, which had issues already when checking into
BIMserver. On the other hand, the most successfully converted elements probably use
IfcExtrudedAreaSolid representation instead. One possible reason is the fact that the conversion was developed based on a limited set of models from practice and reflects on the elements available in these models.
In this case, the semantic mapping follows an approach that kept more semantics: the converted elements are
buildingConstructiveElements, organized in
bldg:Storeys and in one
bldg:Building in turn, according to CityGML version 3 data model. The data model proposed by CityGML v.3 allows the validity of such kind of model, although it could be discussed that the spatio-semantic paradigm [
33] is not changed in a harmonization effort with a GIS-consistent representation.
5.1.4. Myran Conversion to CityGML
All the converted Myran models were generally too large to be opened in the geovalidation tools (
http://geovalidation.bk.tudelft.nl), or did not work properly anyway. However, in the cases where the semantic schema could be checked, it was valid.
When exported by FME Quick translator-based tools, the Myran.ifc model has a similar behavior than Savigliano.ifc and UpTown.ifc, maintaining most of the elements, without any selection (e.g., indoor-outdoor) and any kind of transformation in their representation. All the objects are converted to GenericCityObject with a generic lod4Geometry. Although it is not possible to understand what kind of geometry is used, apparently the solids are not converted to faces. However, as it was already discussed, the Quick translator is not the most proper FME tool to perform such a complex conversion, as recommended by the software vendors themselves.
With the Myran.ifc model, an attempt further was developed by two of the participants in order not to limit the conversion to the storage format but to actually map the semantics correctly between the two data models and change the kind of geometry used. In particular, this was done within the tests: FME19-L3; FME17-RVTr-L1; FME17-IFCr-L1; AGIS-FME-L1; AGIS-FME-IFCr-L1; AGIS-FME-RVTr-L1.
In the FME19-L3 test a CityGML LoD4 model was obtained (
Figure 5) by means of a very complex workspace.
In the other tests, the attempt is also done of getting to generalised boundary surfaces of the building for an LoD3 (According to the criteria followed by the CityGML standard)-like representation.
Among those last ones, the models that could be opened in viewers were quite similar. Doors are correctly converted to bldg:doors, windows are correctly converted to bldg:windows; roof is roofSurface and floor surface is converted to bldg:floorSurface. However, some of the elements (walls, stair, the railing and the slab, the columns and pavement of the balcony and the signs) are (incorrectly) converted to buildingInstallations.
All the converted geometries become
lod3MultiSurface, which is a correct conversion, according to the features of current practice for CityGML data. However, mainly triangulated surfaces are generated and the geometry is not completely controlled, in some cases: each solid is converted into multi-surfaces, which are supposed to represent the same shape (this change is almost successful in the roof slabs representation, although it is possible that the geometry is not completely closed), but in most cases they are converted in a bunch of triangles probably also duplicated (See
Figure 6,
Figure 7,
Figure 8 and
Figure 9).
Notwithstanding the residual flaws, these last tests are the closest to achieving a proper conversion result. They used a complex transformation workflow composed by many steps (filtering, selection, mapping, transformations)—see the details and download the built workspaces among the delivered answers by participants at
https://www.dropbox.com/s/5oof86wys9db6e7/Task4_DeliveredResults_human.docx.
IFC2CityGML is also achieving a nice result, which is compliant to the kind of representation allowed to the version 3 of CityGML, despite adopting a different representation paradigm from the one usually adopted in 3D city models.
5.2. CityGML to IFC Conversions
In
Table 13, the software tested for the conversions from CityGML to IFC in the Task 4 of the benchmark is summarised.
CityGML2IFC and
FZK Viewers were tested with all the three available files, whilst
FME was tested only with the
BuildingsLoD3.gml with the
Quick Translator option and with the
RotterdamLoD12.gml by means of a more complex workspace.
Looking at the results of the conversion, it is possible to notice how generally a change in the format occurs, with little transformation from the typical features of 3D city models to the ones typical of BIM. Of course, in this conversion direction, details should be added to the model, which imply choices that are not straightforward and easily generalizable for any conversion (e.g., thickness of the walls, addition of windows and so on). The need of such transformations should be decided according to specific use cases.
5.2.1. BuildingsLoD3.gml Conversion to IFC
In the conversion from CityGML to IFC of the
BuildingsLoD3.gml file (
Table 14), we can notice that the conversion of semantics follows straightforward rules, as it is reasonable. The geometry as well is converted to the most similar kind of geometry in the converted format, without any further processing. Therefore, the surfaces remain surfaces and the solids remain solids.
Moreover, the roof of a small protruding part at the entrance of one building is represented as bldg:outerFloorSurface in the CityGML model, and is converted to IfcBuildingElementProxy.
The chimneys are represented by means of bldg:BuildingInstallation, which is in turn a composition of bldg:Wall and bldg:ClosureSurface. They are completely missing in some of the converted models by FZKViewer and the one using FME Quick Translator.
The mapping was the same for all the software, except for the cited minor changes, and the export to IFC v.4 and v.2x3 give the same results.
The case of
CityGML2IFC is a bit different, since the tool is developed to manage LoD2 CityGML data. Therefore, in this case doors and windows lose their semantics and their identity as an object, being included in the respective walls (
Figure 10). The only entities remaining here are
IfcWalls, from the conversion of
bldg:Walls and including also
bldg:Doors,
bldg:Windows and
bldg:Installations;
IfcRoof, coming from the conversion of
bldg:RoofSurface, and
IfcSlab [BaseSlab, GroundSlab] coming from the conversion of the
bldg:GroundSurface. The
Bldg:OuterFloorSurface element is lost.
5.2.2. RotterdamLoD12 Conversion to IFC
The RotterdamLoD12.gml model was converted by the FZK Viewer, FME, by means of a complex built workspace and CityGML2IFC tool.
The Rotterdam models converted by the FZK Viewer could only be opened by FZK Viewer itself (which gives syntax errors though); it makes other software crash before opening, instead (e.g., BIMVision and RDF IfcViewer).
After the conversion, many surfaces (both bldg:walls, some bldg:groundSurfaces and some bldg:roof parts) are now IfcBuildingElementProxy. Some of them could be the LoD1 representation of the dataset, which was included in the dataset together with the LoD2. The isolation of the geometry having the most suitable LoD gives an additional complexity for this kind of multi-LoD dataset. Probably the LoD2 is the most suitable, since closer to the BIM detail, although it should be finally decided based on use cases.
In the CityGML2IFC test, it was already reported in the delivered results that the software totally ignored the LoD1 part of the file. It successfully converts parts of LoD2 data, which is reasonable since being developed to convert from LoD2 CityGML data. However, there was a further problem, probably related to the conversion of the parts of the data where LoD1 and LoD2 overlap. Some parts could therefore be missing, but the remaining objects are consistent: bldg:wallSurface to IfcWall; bldg:GroundSurface to IfcSlab and bldg:RoofSurface to IfcRoof.
In the
FME workspace test, a processing of the geometry in order to extrude the faces making them solids was applied, as explained in the delivered description. This is a step forward towards building a consistent representation paradigm with BIM. However, such thickness is not always visible in the model, as inspected with RDF IfcViewer (
http://rdf.bg/product-list/ifc-engine/ifc-viewer/). The semantic mapping of entities in this case is quite consistent, resulting in
IfcWalls,
IfcSlabs,
IfcRoof and
IfcSite generated in the area surrounding the buildings. There are some remaining inaccuracies, for example some
IfcSlabs are used to represent walls (
Figure 11a). In addition, the representation of
IfcSpaces is inconsistent: they are generated only in a part of the buildings and in some cases the volumes do not fit precisely into the walls but are instead slightly different, intersecting or overlapping them in some cases (
Figure 11b).
The geometry is in all the cases converted from the GML MultiSurface to the IFC SurfaceModel. However, although the converted RotterdamLoD12.gml datasets can be opened in some 3D viewers (with warnings and reported errors sometimes), they cannot be opened for example in Autodesk Revit, which is one of the most used software. The result of the conversion made by FME 2019 can be opened in Revit, although only the IfcSite is shown, without the IfcBuildings. It is of course a big issue if such datasets are supposed to be used as reference in software for design.
5.2.3. Amsterdam Conversion to IFC
The conversion of the amsterdam.gml model was tested with the FZK Viewer, to both IFC v.2x3 and v.4 and FME Quick translator.
All the converted models have quite identical characteristics. They presents the buildings exported as IfcBuildings and the rest of entities as IfcBuildingElementProxy, as fair for the IFC v.2x3, since other entities explicitly related to infrastructures are not yet in the model. The semantics of the objects remain in the Name attribute of each entity. In addition, the other attributes are converted and associated to the objects correctly.
However, the geometries are almost all flattened to 2D shapes, as visualized in RDF IfcViewer (
Figure 12).
This is probably not a problem, since the use cases requiring the whole city to be used in IFC are not so usual yet, although, for example, infrastructure design could have an advantage from it. In the results, some participants observed that the Amsterdam dataset is large, with many objects. Therefore, if the focus of conversion is only buildings, the other entities should be removed, since they make the conversion process slow and software unresponsive. However, city elements such as the roads, the terrain and even city furniture could be probably among the most relevant object to be considered as reference for buildings and infrastructure design.
5.3. Conversions Discussion
The results of both conversions from IFC to CityGML and from CityGML to IFC show how it is quite difficult to perform a complete and consistent conversion from one kind of model to the other one. This considers both the interoperability needs of producing a valid output format and the harmonization issues of making the features of the input model homogeneous with the output one.
One of the closest attempts was performed by IFC2CityGML, which has the advantage of the CityGML v.3 representation paradigm allowing the full inclusion of all the BIM concepts within the model without the need to convert them to geo-concepts.
Other good examples are the two ones employing
FME, as described within the
Section 5.1.4, considering the transformation of the solid geometry typical of BIM to the surfaces facing and enclosing the outside part of the building. One of them (FME19-L3) achieved the conversion to CityGML LoD4 with nice results with respect to both geometry and semantics, by developing a very complex processing model.
Others showed how challenging it is to implement a methodology selecting only the necessary parts of the BIM, transform them to a different representation paradigm, by maintaining correctly mapped semantics, and fix it to comply with validity criteria of both geometry and semantics, in association to the application of a generalization to CityGML LoD3.
One of the final questions to participants was about suggestions to improve the input IFC files in order to obtain better conversions. Among those, the participants listed:
Correct georeferencing;
a property that states whether an entity has a volumetric or surface geometry;
modelling interior and exterior separately;
a property identifying which floors are above ground;
openings included in wall and slab entities.
Correct grouping in storeys (e.g., the Myran.ifc dataset has correct semantic information w.r.t. attributes but not for the relationships among entities, i.e., roof of one storey is part of another storey, a whole storey is defined for just plumbing and beam elements which are not just problematic for analysis but also semantically incorrect);
avoid geometries overlap;
correct and consistent use of IfcSpaces.
The conversion CityGML to IFC counted on a limited experience with respect to the conversion IFC to CityGML, because of the fact that most of initial efforts were dedicated to the use of BIM information to be integrated in 3D city models, and not the other way around, which is also implying more formal challenges (not just the technical ones).
In addition, it is important to note that in general, IFC to CityGML is a lossy conversion. IFC schema and models typically have more fine grained details than city scale CityGML models do. Therefore, it is reasonable to expect better results from an IFC (BIM) to CityGML (city model) conversion than the other way around (CityGML to IFC).
The output is generally generated by tools without a deeper consideration of complex BIM and IFC norms or best practices. The output data should be compliant with the minimal requirements of the IFC standard, but is lacking in terms of the logical structure and relationships that a typical domain expert would know.
Most of conversions from CityGML to IFC produce boundary representation models which are probably valid within the IFC model, although different parameters should be taken into account in this regard. For example, what use case will they be used for? What kind of information does this use case need? Within it, a representation of extremely general IfcRoofs and IfcWalls are useful? Would the representation of windows help or not? What kind of geometry would be necessary? And so on.
The generation of a BIM with its own proper representation paradigm (walls with thickness and maybe materials, slabs and so on) would need a way more complex methodology, adopting a combination of more sophisticated technologies and studies supporting them.
As some of the participants discussed, additional support could come from the storage of relevant to typical BIM requirements in the CityGML dataset, such as materials, wall thickness or other classification information.
Within the benchmark, not the whole set of proposed procedures in literature could be tested. This would be an extremely difficult task since many procedures are only described theoretically or do not make their implementations publicly available. However, the measures for potentially reducing this gap were taken by inviting everyone to join in the tests (which would allow developers to test their tools without making them freely available). The tested procedures are therefore the ones most available at the moment for any user interested in making conversions, which was the actual scope of interest of the benchmark.
It is also worth noting that very few open source tools have been, which largely reflects the lack of open source tools currently available for this task. While this weakens the benchmark results, this is more of a shortcoming of the state of the art than a shortcoming of the benchmark itself.
The study could enlighten, first of all, that some geometries encounter difficulties in being converted, as it is apparent from the tests with the
IFCgeometries.ifc dataset (
Section 5.1.1). Moreover, it made the need clear of an overall methodology considering not only the interoperability issue but also the harmonization side of the problem, which is not completely tackled yet.
In addition, the multi-LoD files present more challenges, since the geometries from different LoD can overlap, notwithstanding being part of consistent and valid models. Therefore an initial step selecting only the LoD to be considered for the conversion should help, in most of cases.
It is clear how an aware composition of intermediate processes (such as FME transformers or self-developed algorithms) is necessary to reach high quality results.
The steps involved in the most successful conversions are generally summarized as: feature mapping—attributes mapping—geometry mapping and processing—mapping of relationships and properties.
That implies that a sufficient knowledge of both standards (IFC and CityGML) and of the tool is necessary.