IRW 2004

  • 618 views
Uploaded on

The presentation in Salford International Research Week 2004

The presentation in Salford International Research Week 2004

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
618
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Integrating Building Information Models with Geographic Information Systems The Technology Review Umit Isikdag, Prof.Ghassan Aouad Dr. Jason Underwood, Dr. Nigel Trodd
  • 2. The Problem Exchange of information in an effective way between different types of software that’s used throughout the construction life cycle and in the domain of urban management
  • 3. Software used through the construction life cycle
    • The construction industry is composed of many disciplines.
    • The fragmented nature of the industry has caused many problems relating to information exchange.
    • Software in used in various phases of construction life cycle needs to interact with other software in use.
  • 4. Interoperability in Construction Industry: STEP & IFC
    • To overcome these difficulties;
    • Generally: In the mid 1980’s a new initiative set up by International Standards Organisation has developed a standard, called STEP -ISO10303 (Standard for the Exchange of Product Model Data) to standardise the efforts of exchanging information throughout the product/process life cycle.
    • In 1994 a group of software vendors founded the International Alliance for Interoperability to develop a commonly agreed STEP compliant model for the construction industry.
    • The agreed model is called the Industry Foundation Classes and is now maturing
  • 5. Software used in the urban management
    • The urban management domain receive many inputs from and provides outputs to its related domains.
    • The amount of information is high so it difficult to store exchange and manage the information.
    • Urban management systems should work collaboratively with many other information systems
  • 6. GIS is the common denominator of urban management systems
    • GI Systems are systems which link the geographical information with descriptive information, or in other words systems which link the geo-geometry with the associated data.
    GISs are used in many areas and also in, various stages in construction life cycle.
  • 7. Interoperability in GIS
    • As the number and type of applications that processes geographic data increases the concept of interoperability is also becoming important for geographic information
    • GI Interoperability standards include STEP compliant TC211 and XML based GML
  • 8. The background for the research (AEC Scope)
    • AEC Domain (the need for geographic information):
    • 1)Design Phase of building life cycle data about
    • • Location (Map)
    • • Demographics
    • • Zoning
    • • Risk factors
    • is taken from central property registry
    • 2)Design Phase: Simulation (Noise, Thermal, Lighting)
    • 3)Registrering as built info into central property registry
    • 4)Geo relational construction activities
  • 9. The background for the research (Urban Management Scope)
    • We need building related data:
    • Effective Disaster Damage Analysis
    • Urban Demolition Projects
    • VR in Urban Environments 3D,4D (also for landscape architecture)
    • Planning of Services (Pipeline, Gas, Electric)
    • Effective Maintenance Management in Urban Scale
    • Delivery of goods
    • The integration will provide an infrastructure for integration of
    • local information with global information
  • 10. Aim of the research
    • The general research aim is:
    • To find out the needs for integration and to investigate the ways and methods of integration between them.
    This presentation is focused on the technology review stage of the research.
  • 11. THE TECHNOLGY REVIEW PART 1 GIS
  • 12. Raster & Vector Data Models
    • Raster data is usually stored as an array of grid values , with metadata about the array held in a file header.
    • In the vector data representation each object in the real world is first classified into a geometric type: point, line, or polygon.
    • a) Geometries in a binary file and attributes in a DBMS table ( vector )
    • b) Geometries in a binary file and attributes and topology in a DBMS table ( vector topologic,3d TIN )
    • c) Geometries ,topology and attributes in a DBMS table with a special field for geometric shape ( vector in database )
  • 13. Spatial Databases
    • Spatial Databases are databases that are capable of holding vector and raster geographic information models
    I am a spatial database I can store vector and raster files and also other relational data models I am a raster file (an air photo) I am a vector file (Building Geometries) I am a RDBMS Table
  • 14. The architecture of Geographical Information Systems Spatial DBMS Raster and Vector Data Files GIS GATEWAY GIS Web Server Web Services GIS Software Data Conversion Tools GIS APIs Client Applications Client Applications Web Browsers Data Layer
  • 15. THE TECHNOLGY REVIEW PART 2 IFC
  • 16. Information Models for AEC
    • Previous work include CIMSteel,COMBINE,RATAS,BCCM
    • Industry Foundation Classes (IFCs) are a collection of classes, that form an information model for building construction domain.
    • The IFCs are defined using STEP EXPRESS conceptual modelling language.
  • 17. The Structure of the STEP and IFC
  • 18. 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
  • 19. 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;
  • 20. 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);
  • 21. IFC Information Exchange Architectures
  • 22. Information Exchange with IFCs IFC file (STEP-P21) XCAD YCAD Level1:Data sharing between applications using building information models as physical files
  • 23. 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
  • 24. Information Exchange with IFCs
    • Level 3 :Database Level
    • Storing the IFC data in a standard
    • object or relational database
    OCCURENCE OBJECT DATA(.P21) IFC PHYSICAL FILE PROPERTY ATTRIBUTE RELATIONSHIP ASSOCIATION ENTITY CLASS METADATA(.EXP) IFC SCHEMA RELATIONAL DATA MODEL OBJECT DATA MODEL FORMS EXPRESS DATA MODEL LOGICAL LEVEL CONCEPTUAL LEVEL
  • 25. Express Databases I am an Express Database I can interpret STEP meta models I can store STEP compliant models IFC Meta Model (Schema) (ISO10303) IFC File (ISO10303-P21)
  • 26. Information Exchange with IFCs
    • Level 3:Database Level
    • Storing the IFC data in ISO10303 compliant databases
    EXPRESS DBMS IFC SCHEMA IFC FILE SDAI DB API Database API Clients XCAD YCAD
  • 27. 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
  • 28. Conclusion Several Possible System Architectures Physical File Level Database Level Application Level
  • 29. Physical File Level: File Conversion IFC Physical File GIS Vector Data Files GML
  • 30. Database Level :Database Integration Spatial DBMS EXPRESS DBMS API GML to IFC(XSLT) IFC to GML(API) RDBMS API API or GML ODBMS
  • 31. Application Level Integration 1 Scope: Model Based Construction Focus: Building Information Model EXPRESS DBMS IFC/IFG SCHEMA IFC/IFG File (STEP-P21) SDAI API Database API Clients using IFC and GIS Data Spatial DBMS Raster and Vector Data Files GIS GATEWAY Web Services GIS Client Applications (APIs ,Data Conversion Tools ,GIS Software) GML GML WMS/WFS IFC API Web Services Data Conversion and Transfer Tier GIS Data Conversion API XSLT
  • 32. Application Level Integration 2 Scope: Urban Management Focus: Geographic Information System EXPRESS DBMS IFC SCHEMA IFC/IFG File (STEP-P21) SDAI API Database API Clients using GIS and IFC Data IFC API Web Services Translation APIs Spatial DBMS Raster and Vector Data Files GIS GATEWAY Web Services GIS Client Applications (APIs ,Data Conversion Tools ,GIS Software) GML GML WMS/WFS
  • 33. Finally, IFC is a project driven approach for information management IFC enable interoperability through the project life cycle GISs have an infrastructure driven approach GISs enable interoperability in urban modelling and management Urban Planning & Management (GIS) IFC IFC IFC Construction Project Life Cycle (IFC Based Information Systems) Geo-info. Geo-info
  • 34. Finally,
    • 4 integration approaches are presented Modern Data Conversion Database Level Integration
    • GIS Dominant IFC Dominant
    • Next step will be choosing an implementation solution according to our
    • business need surveys
    • Critical Analysis of technologies in terms of practicality and elegance
    • Implementing a solution and development of a prototype
  • 35. Thanks for listening…
  • 36. NEW APPROACHES
  • 37. New Approaches: Mapping the IFCs to XML Ifc MetaModel (IFC2x.exp) Ifc Model (Building.ifc) Ifc MetaModel XML Schema (IFC2x.xsd) Ifc Model XML (Building.xml)
  • 38. New Approaches: Mapping the IFCs to XML Ifc MetaModel XML Schema (IFC2x2.xsd) Ifc Model XML (Building.xml) XML Database
  • 39. Alternative types of architectures Yes/No Building.xml Ifc.xsd New Approach: Storing IfcXML in XMLDB Ifc.xsd Ifc.exp Ifc.exp, Database Schema Ifc.exp Ifc.exp Schema No RDBMS/ ODBMS Storing IFCs in ODBMS / RDBMS Yes Building.ifc Accessing IFC with APIs Building.xml EDBMS Building.ifc Data stored in form of.. Yes (DOM.SAX) New Approach:IfcXML Yes (DB API) Storing IFCs in EDBMS No IFC Physical File Exchange Need for an API to get information Architecture Type
  • 40. Physical File Level: Conversion Mirror IFC Physical File IfcXML Physical File GIS Vector Data Files GML
  • 41. Database Level :Database Integration Spatial DBMS EXPRESS DBMS XML Database GML IFC XML API GML to IFC(XSLT) IFC to GML(API) RDBMS API or IFCXML API or GML ODBMS
  • 42. Interoperable data
    • Is a type of data;
    • Reached/edited with multiple applications
    • Can be exchanged among multiple applications
    • without the need for changing its physical format