Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (14)
Ähnlich wie Sjors Donkers - Automatic generation of CityGML LoD3 building models from IFC models
Ähnlich wie Sjors Donkers - Automatic generation of CityGML LoD3 building models from IFC models (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Sjors Donkers - Automatic generation of CityGML LoD3 building models from IFC models
- 1. Automatic generation of CityGML LoD3 building models from IFC models M.Sc. Geomatics P5 presentation by Sjors Donkers Supervisors: Hugo Ledoux / Junqiao (John) Zhao Graduation professor: Jantien Stoter 1
- 2. Geomatics 2
- 4. Where the fields overlap Large scale (mm) Geomatics World Country City Region Small scale (km) CityGML Building Architecture Building Floor Section Room Component IFC 4
- 5. What is high detail for CityGML? • LoD ≤ 2 can be automatically generated • LoD ≥ 3 requires manual labour LoD4 LoD1 LoD2 LoD3 LoD0 5
- 6. Research question Is it possible to generate valid and semantically rich CityGML building models at LoD3 from IFC models, and can this method be extended to LoD4? 6
- 7. Structure • What is IFC / CityGML and when is it valid? • Methodology for the conversion • Experimental results • Possibilities for LoD4 • Conclusions, recommendations & future work 7
- 8. Conversion from IFC to CityGML IFC CityGML 8
- 9. IFC example •Many objects •Complex semantic network •For content creators 9
- 10. CityGML LoD3 example •Few objects •Simple hierarchical semantics •For users / analyses 10
- 12. Validity criteria for CityGML LoD3 •Semantics: • Normal vector constraints on surface types •Geometry: You should be able to walk on a FloorSurface, CityGML: on a CeilingSurface but not • A building has only an exterior shell ISO19107: • The shell must be 2-manifold B Vertices should not be close to other geometries A 12
- 13. Degenerate geometry Floating-point arithmetic: Exact arithmetic: 0.1 + 0.2 ≠ 0.3 0.1 + 0.2 = 0.3 = 0.30000000000004 Degenerate when: Float-orientation ≠ Exact-orientation Distance d = 0 (float or exact) 13
- 15. Structure • What is IFC / CityGML and when is it valid? • Methodology for the conversion • Experimental results • Possibilities for LoD4 • Conclusions, recommendations & future work 15
- 16. Methodology for the Conversion 2 Geometric transformation 1 Semantics mapping 3 Refinements 16
- 17. 1 Semantic mapping CityGML has semantics for and between: • Solids / Objects • Trivial attributes • Faces • Boundary surfaces (But not limited to only boundary surfaces!) • Curves • Requires the terrain which is out of scope 17
- 18. 1 Semantic mapping IFC example structure Project Site Building Building Building Geometry Storey Storey Space 18
- 19. 1 Semantic mapping IFC CityGML • Beam • Member • Stairs • Door • Roof • Wall • Slab • Window •… • Ceiling • Door • Floor • Roof • Wall • Window • Ground • Closure ?? 19
- 20. 1 Semantic mapping A combination of: Building Roof ROOF Slab Slab 1. Type • IfcSlab 2. •Predefined type IfcMember • IfcRoof FLOOR 3. •Decomposed by ROOF • LANDING 4. •Surface normal BASESLAB • USERDEFINED • NOTDEFINED Constraints: The object has to be contained in a building Must be a Space or a subtype of BuildingElement 20
- 21. Methodology for the Conversion 2 Geometric transformation 21
- 22. 2 Geometric transformation 1. All IFC geometries are connected using the Boolean union operation 2. Interior geometries are removed 22
- 23. 2 Geometric transformation Real buildings are not watertight ! ? 23
- 24. 2 Geometric transformation Concepts for extracting the exterior shell • Generated • Implemented • Evaluated Morphological closing Using an oriented cubical structuring element 24
- 25. 2 Morphological closing Morphological closing = dilation followed by erosion Dilation: Erosion: 25
- 26. 2 Morphological closing 1. Geometries are dilated thereby closing the gaps 2. Interior geometries are removed 3. The exterior shell is eroded back to it original size 26
- 27. 2 BuildingInstallations • BuildingInstallations are separate objects • Objects must not overlap each other 1. BuildingInstallations are unioned 2. The building solid is subtracted 27
- 28. Methodology for the Conversion 3 Refinements 28
- 29. 3 Refinements - geometric • Coordinates are rounded in preparation of writing • The geometry is regularized • Solid geometry is made 2-manifold • Degeneracies are removed 29
- 30. 3 Refinements - semantic • Faces without semantics are created during closing • Semantics are asigned based on the normal and the neighbours Conversion complete! 30
- 31. Implementation • Nef polyhedra are used for Boolean operations • Nef polyhedra in CGAL do not support semantic faces • Semantics are reattached after the geometric transformation 31
- 32. Structure • What is IFC / CityGML and when is it valid? • Methodology for the conversion • Experimental results • Possibilities for LoD4 • Conclusions, recommendations & future work 32
- 33. Experimental results – no roof IFC CityGML 33
- 35. Validity and quality • Geometric validity checked using 3D Validator: All models are valid! • Some near degeneracies remain • Artefacts occur when closing is applied 35
- 37. Validity and quality • Geometric validity checked using 3D Validator: All models are valid! • Some near degeneracies remain • Artefacts occur when closing is applied • Mismatched semantic • Lacking semantics in IFC 37
- 38. Conversion evaluation • Computation time ~5-15 minutes • With outliers from 6 seconds to 95 minutes • Creation of Nef polyhedra and Boolean operations are slow • Morphological closing roughly double the computation time • Generated CityGML files are smaller than input IFC files • Detriangulation leads to a file size reduction of ~66% • ~50% of the file space is dedicated to BuildingInstallations 38
- 39. Structure • What is IFC / CityGML and when is it valid? • Methodology for the conversion • Experimental results • Possibilities for LoD4 • Conclusions, recommendations & future work 39
- 40. Generation of LoD4 rooms • Rooms cannot be detected from the geometry • IfcSpaces are (almost) equivalent to Rooms in CityGML • In the implementation: Geometry from IfcSpaces Semantics base on surface normal 40
- 42. Possibilities for LoD4 conversion • In IFC objects can be linked to spaces • The same semantic mapping can be used • But needs to be extended with: Furniture and other LoD4 specific objects Connectivity relations between openings 42
- 43. Structure • What is IFC / CityGML and when is it valid? • Methodology for the conversion • Experimental results • Possibilities for LoD4 • Conclusions, recommendations & future work 43
- 44. Conclusions • A new source for CityGML LoD3 building models • Small additions to the IFC will align the two standards even more • Generating LoD4 building models is only a small step away • The methodology enables the creation of • • • • • • up-to-date high detail models that adhere to the standards of CityGML and ISO19107, thereby increasing the availability of high detail models and the interoperability between Geomatics and Architecture and reducing the costs for the creation of high detail city models 44
- 45. Conclusions Other uses of this research: • Semantic mapping for use in a reverse conversion or UBM • Geometric transformations for the simplification of any CAD model • Refinement methods to optimize the geometry for analyses 45
- 46. Recommendations Recommendations for IFC: • IfcSpace for the exterior of the building • Add semantics for balconies, dormers, external IfcSpaces Recommendations for CityGML: • Refine the definitions of how to model CityGML • For the geometry of BuildingParts & -Installations • For the semantics of doors and windows 46
- 47. Future work • Mapping of new IFC4 classes and trivial attributes like the address • Extraction of the terrain intersection curve • A higher level of interoperability between IFC and CityGML • Alignment of the standards • Generation of LoD2 and LoD4 building models • Generation of other city objects (tunnels, bridges) 47
- 49. Automatic generation of CityGML LoD3 building models from IFC models M.Sc. Geomatics P5 presentation by Sjors Donkers Supervisors: Hugo Ledoux / Junqiao (John) Zhao Graduation professor: Jantien Stoter 49
Hinweis der Redaktion
- The semantics need to be extracted from IFCThis is an example of an IFC structureGeometric objects only in the leafsSo for each of these leafs the semantics need to be converted
- For some objects the mapping is easy, a door is a doorFor others it is less clear
- In those cases the mapping depends on a combination of semanticsFirst the typeSecond the predefined typeIf that does notyield a result we have to look at its parentsIs it part of a roof? And this has to be done recursivelyNow that we’re pretty sure this is a roof,the semantics also depend on the normal of the surface
- Inreality, buildings are not watertightChimneys, air-vents and cracks beneath doors all create gaps in the exterior
- Concepts for closing these gaps have been generatedimplemented and evaluatedThe best concept is morphological closing,using a structuring element which is rotate to match the buildingWhy? Reliable, predictable, stableBut what is it actually?..
- Well it is dilation followed by erosionDilation of a triangle is an expansion of the cube at every location making it biggerErosion does the reverse. It shrinks the geometry with the cube. In this case the original triangle is recreated.So how is this helpful?..
- Well if the building with gaps is dilatedsuddenly the interior geometries can be removedBut the building is still bigger so it needs to be eroded back to its original sizeNOTE: that an artefact has been created during the transformation
- BIs are notpart of the buildinggeometry.BIs are for example the carport here or the stairs thereSo separate objects and objects must notoverlap each otherThis is prevented by unioning them such that they do not overlap eachotherAnd the building geometry is subtracted such that they do not overlap with the building..Ideal case the transformation is complete, but…
- The coordinates need to be rounded as you can only store a limited amount of decimalsThe geometry is regularized which removes all non-volumetricpartsThe geometry is made 2-manifold, by means of a convexdecompositionThe boundary surface and the solid geometry are stored separately in CityGMLBy cutting the solid geometry in multiplepieces all solids become 2-manifold.This operation leaves shapeintact while geometry is optimized for analysisLastly degenaracies are limited by unioning coplanar faces thereby removing as many vertices and edges as possible
- As you may remember faceswithoutsemantics were created during the transformationFor these faces new semantics are assigned based on there normal and their neighbours.For example for a down-facing surface that is connected to a ceiling surface the ceiling surface semantics are used.There are some smaller processes, but basically that is the final step of the conversion. Connected faces with the same semantics are grouped Opening surfaces are linked to boundary surfaces (wall / roof)
- For this conversion a prototype program has been developed.It uses the IfcOpenShell and CGAL programming librariesFor Boolean operations Nefpolyhedra are used,these sadly do not support semantics.Therefore the semantics are reattached after the geometric transformation
- ValidDegen but due to implementationArtefactsdue to morphological closing underneath roof overhang etc
- To evaluate the impact of the size of the cubical element, this graph was madeOn the y-axis the percentage of area is plotted that is added due to the closing operationAnd here are the output models at respective stagesFirst there is only a small impactSecond stage doors and windows are collapsing, definitely toomuchIn the final stage increasing the size of the cube does not even matterAs every model is different a maximum of 300mm is recommended
- Furthermore there are notreattached properly due to the implementationAnd some semantics are not optimal as IFC does not provide enough informationGround, Space, Dormer and Balcony
- Computation time ~5-15 minutes With outliers in both directionsIt very difficult to tell how long a conversion is going to take the first timeCreation of Nef polyhedra and Boolean operations are slowMorphological closing roughly double the computation timeGenerated CityGML files are smaller than input IFC filesWhich is useful but remarkable since other increased it by 20 to 50 timesDetriangulation leads to a file size reduction of ~66%~50% of the file space is dedicated to BuildingInstallationsGeneralization could bring more balance to thatIf looking to implement the methodology might want to look for an alternative (Nef)20 50 times larger
- Well for geometry exteriorshell can off course be reused,But Rooms cannot be extracted with the same operationLuckily IFC provides Spaces which are almost equivalent to the rooms in CityGMLFurthermore,Spaces are meant for energyanalysesSo I made an implementation in which the Geometry from the spaces are usedAnd semantics are generated based on the surface normal
- Bottom-up view to see separation of roomsSo what are the possibilities?
- In IFC objects can be linked to the spacethus the semantics of the wall roof window and door can be transferred in future implementations.
- Reverse conversion or UBMAny CAD model can be simplifiedArchitect influence of environmentReal estate agent query for large south facing windows
- The methodology presented here can be used as the foundation for all
- So the work I showed you is for the creation of LoD3 and 4 models. But as PoC I also created LoD2 and LoD1 from the LoD3 modelTo emphasize how much closer this conversion brings to bringing these two formats together