Maven and integration with IFC about importer-exporter HOT 9 CLOSED

By the way, I like the 3dcitydb tools very much !
Gr.,
Barent Brouwers

from importer-exporter.

Thanks for your message. I hope you enjoyed the workshop and the 3DCityDB.

We use Ant as build tool, and provide the mandatory dependencies directly in the code repository (see lib folder). This is not to be understood as deliberate decision against Maven, but simply as how the project has been used and evolved over time. Some of the dependencies are not available as Maven artifacts though.

So far there has been no reason to migrate to Maven. If you clone the repository and create an Eclipse project from it, then all dependencies should be directly on your classpath. So you can start coding right away.

from importer-exporter.

Sounds great. BIMServer used to use citygml4j for exporting BIM models to a CityGML ADE (called the GeoBIM extension). citygml4j is still listed on the BIMServer website as external library.

So yes, I agree that the expert group you mentioned has the knowledge to bring this topic a substantial step forward. Would be great to have a joint meeting!

Please note that the 3DCityDB team involves the TU München, but also the companies virtualcitySYSTEMS (this is where I work) and M.O.S.S and individuals, all of whom constribute to the development.

from importer-exporter.

We discussed this afternoon about the interoperability between IFC (standard in BIM, Building Information Model, focused on buildings) and CityGML. IFC could deliver building geometry, with less detail, and semantic information to the CityGML model. In the exporter tool (3dcitydb -> KML/COLLADA/glTF), what kind of mapping is used to export from one model to the other ? Last year I did a project in which the http://mapstruct.org/ project is used. This is a very structured way for mapping java bean types. Perhaps this is a way for mapping the IFC model on the CityGML model.

from importer-exporter.

Interesting thought, indeed.

For parsing and writing CityGML, we use citygml4j which provides a Java object model for CityGML. The KML/COLLADA/glTF export does not use citygml4j as intermediate layer though but directly queries the database and writes the results to the specific export format.

Do you have a specific Java representation for IFC in mind? I have no experience with MapStruct, but possibly it allows a mapping to citygml4j which would allow loading IFC data into the database. Once the IFC data is spread over the database tables, export to KML/COLLADA/glTF will work. That said, an alternative and possibly stronger approach is to define a direct mapping between IFC and the 3DCityDB tables, which would additionally require the implementation of an IFC importer.

IMHO, simply identifying CityGML object classes with IFC object classes will however not be sufficient to reach interoperability. Although from 2009, this paper provides a good overview of the challenges when mapping from CityGML to IFC (or vice versa).

from importer-exporter.

I have asked the lead developer of BIMServer for more information about a Java representation for IFC :

lead developer : Ruben de Laat [email protected]

BIMServer : https://github.com/opensourceBIM/BIMserver/tree/master/BimServer

They are using https://eclipse.org/modeling/emf/ and the whole IFC model is caught by

https://raw.githubusercontent.com/opensourceBIM/BIMserver/master/BimServer/models/models.ecore

I hope this clarifies some things.
I am going to read the paper about the challenges. I think it should be possible to overcome these with an overall effort of TU München, TU Delft, TU Eindhoven, TNO and the http://www.3dgeosolutions.nl/ company (I work here !)

from importer-exporter.

The mentioned paper mainly focuses on the automatic reconstruction of building information models from uninterpreted 3D Models, by means of a two-stage reconstruction process. Stage two is the CityGML -> IFC conversion.
Perhaps it's wise to focus at first on the IFC -> CityGML conversion :

https://issuu.com/geomarespublishing/docs/gim-international-october-2016-2/27?e=0

"As IFC contains more detailed and more complex information than CityGML, the conversion from IFC to CityGML is relatively straightforward and stable. "

Reading the paper I have some first simplification ideas for the IFC -> CityGML conversion :

1. converting IfcWall and IfcWallStandardCase elements only to the exterior wall surfaces as CityGML WallSurface object, neglecting the interior wall surface.
2. In contrast to CityGML, IFC buildings are structured in storeys. So, when converting from IFC to CityGML, the resulting exterior wall surfaces from step 1 have to be merged to a single CityGML WallSurface object.

I think, during the IFC-> CityGML mapping with the MapStruct project many more rules like these will evolve.
My company, the 3D GeoSolutions company, wants to cooperate in this kind of mapping.
Moreover, we'd like to come to München to discuss this with the Geoinformatics group.

Greetings,

Barent Brouwers

from importer-exporter.

Sounds great too.
Is it possible for you or Thomas Kolbe to arrange a meeting with all these companies regarding this topic of an IFC -> CityGML mapping with the Mapstruct project ?
I could prepare some steps in the Eclipse IDE and show that to you all.

from importer-exporter.

With the latest release 4.0, we have split the source code into modules which are now available as Maven artifacts from Bintray. We now use Gradle as build system instead of Ant.

So this answers your original questions - well, after quite some time though :-). All the other questions on IFC->CityGML are outside the scope of this project. So I am closing this issue now.

A lot has happened in the field of CityGML and IFC since your original post. If you are still interested in this, we should continue the discussion using another channel.

from importer-exporter.