Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

UDMS 2004


Published on

The presentation in UDMS 2004

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

UDMS 2004

  1. 1. TOWARDS THE IMPLEMENTATION OF THE BUILDING INFORMATION MODELS IN GEOGRAPHICAL INFORMATION SYSTEMS Umit Isikdag, Prof.Ghassan Aouad Dr. Jason Underwood, Dr. Nigel Trodd * University of Salford *Coventry University
  2. 2. Summary <ul><li>Introduction to study </li></ul><ul><li>Definitions about building information modelling </li></ul><ul><li>2 scenarios explaining... </li></ul><ul><li>Step by step approach to the implementation </li></ul>
  3. 3. Introduction... <ul><li>G eographical I nformation S ystems are commonly used information systems to plan and manage the urban built environment. </li></ul><ul><li>i.e. t hey are used to manage the urban infrastructure and cadastre, and urban growth. </li></ul><ul><li>Some urban management tasks; disaster management ( e.g. evacuation and post disaster rescue) operations , delivery of goods and services, require detailed information about buildings. </li></ul>
  4. 4. Problem definition <ul><li>The current state of art in; </li></ul><ul><li>Transfer of building information to GIS </li></ul><ul><li>Representation of building information in GIS </li></ul><ul><li>is not sufficient enough, for developing a successful GIS based system to manage these tasks. </li></ul>
  5. 5. Problems in transfer of building information to GIS <ul><li>In most standard CAD models building are represented with their geometries, but the attribute information about the building elements (e.g the material of the wall) is not contained in the model. </li></ul><ul><li>But in recent years the building models, have evloved from CAD geometry models to building information models which contain attribute information </li></ul><ul><li>The information transfer efforts to GIS is focused on transfering the building geometry from standard CAD files, but not transfering (geometry+attributes) form building information models. </li></ul>
  6. 6. Problems in representation of building information in a GIS <ul><li>The buildings are typically represented with their 2D geometries and a height value in geographical information models </li></ul><ul><li>Geographical information models can handle 3D geometry but , </li></ul><ul><li>They are not designed to handle detailed information about building elements (e.g the height of a wall, the size of a column) </li></ul>
  7. 7. Aim of the research <ul><li>To investigate the methods and technologies in order to : </li></ul><ul><li>Provide higher level of building information to GIS s </li></ul><ul><li>Represent and visualise building information in GIS s </li></ul>
  9. 9. A brief history of information modelling in construction industy <ul><li>In the early days of CAD systems, the exchange of construction related data in the industry has been conducted through the exchange of drawings in neutral file formats . </li></ul><ul><li>AutoDesk’s DXF and IGES </li></ul><ul><li>In the early 1990’s the data exchange structures evolved from neutral CAD file formats to building information models , which are developed using EXPRESS modelling language </li></ul>
  10. 10. International Alliance for Interoperability and Industry Foundation Classes(IFC) <ul><li>In 1994, 12 U.S.A. based companies joined together to examine the potential for interoperability in the construction industry. </li></ul><ul><li>The organisations realised after the first effort that there was economic benefit to be gained from this interoperability of software. </li></ul><ul><li>I n October 1995 they established the International Alliance for Interoperability (IAI). </li></ul><ul><li>The participants then decided to develop a vendor neutral building information model for software interoperability and The first version of the IAI’s vendor neutral model Industry Foundation Classes (IFC) is released in 1997 . </li></ul>
  11. 11. What is an Industry Foundation Classes (IFC) Model IFC is an object oriented building information model that contains high amount of geometry and attribute information about a building Roof: Geometry: Triangle Material: Concrete Will be built on:10.1 2 .2004 Cost:1000£ Door: Geometry: Rectangle Material: Wood Will be built on:10. 11 .2004 Cost:100£
  12. 12. The Structure of IFC models
  13. 13. Structure of STEP Description Methods EXPRESS, EXPRESS-G IDEF1x ,NIAM, Integrated Resources Common Model Subsets Application Protocols Meta Models Application Reference Model (Defined by EXPRESS-G) Application Interpreted Model (EXPRESS) Implementation Methods Physical Files Structures(21) File Access Methods(22) Conformance Test assesses the implementation
  14. 14. IFC Schema : The Meta Model Meta Model file is called IFC Schema Meta Model file holds the IFC entities IFC entities contain descriptive information about IfcObjects. Meta Model is defined by EXPRESS The meta model file has the .exp extension ENTITY IfcOrganizationRelationship; Name : IfcLabel; Description : OPTIONAL IfcText; RelatingOrganization : IfcOrganization; RelatedOrganizations : SET [1:?] OF IfcOrganization; END_ENTITY;
  15. 15. IFC Physical File Physical Model file is called IFC file Physical Model file holds the IFC objects Physical Model is defined by STEP Standard Part 21 The physical model file has the .ifc extension #42 = IFCSHAPEREPRESENTATION (#26, 'Axis', 'Curve2D', (#41)); #43 = IFCCARTESIANPOINT ((0., 0.)); #44 = IFCCARTESIANPOINT ((2000., 0.)); #45 = IFCCARTESIANPOINT ((1760.000005364418, 239.999994635582)); #46 = IFCCARTESIANPOINT ((-239.999994635582, 239.999994635582)); #47 = IFCPOLYLINE ((#43, #44, #45, #46, #43)); #48 = IFCARBITRARYCLOSEDPROFILEDEF (.AREA., $, #47);
  16. 16. IFC Information Exchange Architectures
  17. 17. Information Exchange with IFCs IFC file (STEP-P21) XCAD YCAD Level1:Data sharing between applications using building information models as physical files
  18. 18. Information Exchange with IFCs Level 2: Accessing the IFCs through APIs IFC File (STEP-P21) IFC API SDAI API XCAD Client B YCAD Client A
  20. 20. Express Databases Express (ISO10303) Database Management System (ODBMS) IFC Meta Model (Schema) (ISO10303) IFC File (ISO10303-P21)
  21. 21. Information Exchange with IFCs <ul><li>Level 3:Database Level </li></ul><ul><li>Storing the IFC data in ISO10303 compliant databases </li></ul>EXPRESS DBMS IFC SCHEMA IFC FILE SDAI DB API Database API Clients XCAD YCAD
  22. 22. Alternative types of architectures Yes Yes, Database Schema Yes/No No Need for the schema No Yes (DB API)/No RDBMS ODBMS Storing IFCs in RDBMS / ODBMS Yes Building.ifc Accessing IFC with APIs EDBMS Building.ifc Data stored in form of.. Yes (DB API) Storing IFCs in EDBMS No IFC Physical File Exchange Need for an API to get information Architecture Type
  23. 23. A brief overview of GIS architectures
  24. 24. A brief overview of GIS architectures Application Component Pool Spatial Database Data Files Rst+ Vec+ Std (inc.GML) Web Services Components (WMS,WFS) Data Connectors Data Analysis Tools Data Converters Visualisation & Interaction
  25. 25. Analysis of the technology
  26. 26. 2 Scenarios <ul><li>R eal time visualisation of construction in 3D </li></ul><ul><li>Fire response software development in 3D </li></ul>3 major phases of implementation <ul><li>Exporting the data from the building information model </li></ul><ul><li>Importing the data to the spatial environment </li></ul><ul><li>Storing and visualising the model within a GIS environment . </li></ul>
  27. 27. Scenario 1 R eal time visualisation of construction operations in 3D
  28. 28. Scope <ul><li>A city council requires to make a dynamic 3D visualisation of the construction projects in the city by using a GIS, which means when a change in a building occurs, it will be automatically reflected in the 3D urban environment </li></ul>
  29. 29. Step/Criteria 1:Building model file type <ul><li>CAD file vs IFC </li></ul><ul><li>IFC : An Industry Standard </li></ul><ul><li>IFC :Rich in attributes (e.g time,material properties ) </li></ul><ul><li>IFC:Ready for 4D </li></ul>
  30. 30. Step / Criteria 2:Building Information Model Storage <ul><li>Physical file vs Database (as a data store) </li></ul><ul><li>The industry vision on this issue is on using a shared model database . </li></ul><ul><li>R eaching the model using a shared database enables all parties to notice an update in real time . </li></ul><ul><li>The file exchange method can be chosen in the pre-construction stages , where no real time data exchange is necessary. </li></ul>
  31. 31. Step / Criteria 3:Amount of data to be transferred from IFC model to GIS environment <ul><li>IFC vs IFC Geometry Objects </li></ul><ul><li>In this case the information needed by the city council is limited to the building’s outer geometry , so exporting all the information in the model is not a necessity . </li></ul><ul><li>An abstracted version of the building information model (which can be called B uilding I nformation M odel G eometry O bjects needs to be created. </li></ul><ul><li>This BIM-GO model can be an XML model or a subset of IFC </li></ul>
  32. 32. Step / Criteria 4: Transfer of information over the internet <ul><li>Submission of IFC subset model(BIMGO) vs Creating a Web Service </li></ul><ul><li>It will be difficult for the city council to interpret an model in a physical file because, they will need to use extra application interfaces </li></ul><ul><li>P rovide a web service (BIMWS) , to serve the model over the web. </li></ul>
  33. 33. Step / Criteria 5: Choice of the middlware platform <ul><li>CORBA vs EJB vs SOAP. </li></ul><ul><li>EJB is language (Java) dependent , so if any of the parties are not using Java based solutions EJB will not be sufficient. </li></ul><ul><li>CORBA is a good defined middleware platform, but it requires a lot of programming experience and development skills . </li></ul><ul><li>SOAP is easy to learn and develop , and XML based transparent message exchange gives is another advantage of it. </li></ul>
  34. 34. Step / Criteria 6: Storage of building topology <ul><li>Transient vs Persistent storage of data in GIS </li></ul><ul><li>As the visualisation application will use a real time data processing, t ransient (short time) storage is sufficient </li></ul><ul><li>Data can be stored persistently later if needed </li></ul>
  35. 35. Step / Criteria 7: Visualisation <ul><li>Standard GIS tools VR languages vs advanced VR environments and languages </li></ul><ul><li>The visualisation will include the outer shape of the building , but will not include the visualisation inside the building. </li></ul><ul><li>The visualisation can be done using the components of some off the shelf GIS packages or some standard VR languages (X3D) </li></ul>
  36. 37. Scenario 2 Emergency Fire Response Software
  37. 38. Scope <ul><li>T he fire department of the city wants to develop GIS based emergency fire response software. The software will use a database containing information about the buildings in the city including their 3D models. </li></ul>
  38. 39. Step/Criteria 1 : Digital Representation of Buildings <ul><li>3D Image extraction from photos vs Drawing by CAD vs 3D Scanning </li></ul><ul><li>Depends on the time and resources of the project,and also depends on project team’s experience </li></ul>
  39. 40. Step/Criteria 2:Building model file type <ul><li>CAD file vs IFC </li></ul><ul><li>CAD: Just represents geometry all other element attributes needs to be added to the systemmanually </li></ul><ul><li>IFC :Rich in attributes (e.g time,material properties ) </li></ul><ul><li>IFC: Vendor neutral model </li></ul>
  40. 41. Step / Criteria 3:Amount of data to be transferred from IFC model to GIS environment <ul><li>IFC vs IFC Subset Model </li></ul><ul><li>Fire response software needs a lot of attribute information from IFC model (e.g. door opening directions) . </li></ul><ul><li>Creating a new subset object model (in other words a subset of IFC) is not found feasable. </li></ul>
  41. 42. Step / Criteria 4: Transfer of information over the internet <ul><li>Submission of IFC file vs Creating a Web Service </li></ul><ul><li>All IFC data will be handled and processed by the fire response software (in city council) </li></ul><ul><li>Creating a web service on the server side will not be efficient </li></ul><ul><li>Upload/submit the IFC file to the city council </li></ul>
  42. 43. Step / Criteria 5:Building Information Model Storage <ul><li>Physical file vs Database (as a data store) </li></ul><ul><li>The industry vision on this issue is on using a shared model database . </li></ul><ul><li>But using a physical file will quicken the file upload/submission process </li></ul>
  43. 44. Step / Criteria 6: Storage of building topology <ul><li>Transient vs Persistent storage of data in GIS </li></ul><ul><li>A new data model for the spatial database. </li></ul><ul><li>Import data by using IFC API. </li></ul><ul><li>The fire response software needs to reach the building information model in a quickest time. </li></ul><ul><li>Persistent storage: T he fire response software needs to hold every required attribute of the building information in its own geospatial database . </li></ul>
  44. 45. Step / Criteria 7: Visualisation <ul><li>Visualisation will be done by the fire response software . </li></ul><ul><li>V isualisation should be accomplished by using VR tools and languages </li></ul><ul><li>GIS visualisation components will not provide sufficient level of detail to seamlessly move from urban level to the building level. </li></ul>
  45. 47. Summary
  46. 49. Further Research <ul><li>Technical Implementation </li></ul><ul><li>Representation of 3D objects in spatial environments (i.e studies in Delft University in spatial databases , and works showing the use of GML3 on this issue) </li></ul><ul><li>Visualisation of 3D buildings in GIS </li></ul>