Chapter 2 Discussion Questions
3.2 DIFFERENT KINDS OF EXCHANGE FORMATS
an architect’s building model to one used for energy analysis. In that conver- sion, the meaning of all space boundaries dramatically changes. All building projects, by the time they are built, involve both these kinds of translations.
These meanings are defi ned by the fi elds that use the data. Methods for defi n- ing these exchanges are the focus of the fi rst part of this chapter. The second part focuses on the issues and methods for synchronizing and managing the multiple representations of a building project and the management of these heterogeneous representations.
schema defi nition language for databases in the world. There are thousands of SQL schemas, mostly proprietary. The ISO-STEP-developed data modeling language, EXPRESS (Schenck and Wilson 1994) is the basis for a range of product modeling technologies and schemas, including Industry Foundation Classes (IFC) (IAI 2010) and CIMsteel Integration Standard, version 2 (CIS/2) (CIS/2 2007), as well as over 20 exchange schemas in manufacturing, ship- building, and electronics.
Another large set of exchanges are supported by XML (eXtensible Markup Language). XML is an extension to HTML, the base language of the Web.
XML supports multiple handling of schemas. Some are embedded within the exchanged data and others rely on an external schema. Some XML schemas are published and public, while others are proprietary. The different XML schemas support exchange of many types of data between applications. XML is especially good in exchanging small amounts of business data between two applications set up for such exchanges. XML schemas for AEC include BACnet (Building Automation and Control networks) (BACnet 2010), a standard protocol for building mechanical controls; AEX (Automating Equipment Information Exchange) (AEX 2010) for identifying mechanical equipment;
AECxml, an XML version of the IFC schema (IAI 2010a); and cityGML (City Geography Markup Language) (CityGML 2010), an exchange for representing buildings within a GIS (Geographical Information System) format for urban planning, emergency services, and infrastructure planning.
With the advent of the World Wide Web, several different alternative schema languages were developed. These took advantage of streaming of infor- mation packets that could be processed as they were received, in contrast to fi le transfers that require the complete transfer of data before they can be proc- essed. While fi le-based data transport is still common, XML provides stream- ing data packaging that is attractive for many uses. With cell phones and other devices, other transport media, such as GSM (Groupe Spécial Mobile), GPRS
Schema Schema Languge IGES
SQL EXPRESS XML Schema XML–DTD XML–RDF – many schemas
IFC CIS/2 STEP – Parts BACnet AEX AECXML cityGML FIGURE 3–2
All modern exchange for- mats are based on a sche- ma defi ned in a schema language. There are many XML schemas with different schema languages.
ch003.indd Sec2:106
ch003.indd Sec2:106 3/8/11 6:09:13 PM3/8/11 6:09:13 PM
www.EngineeringBooksPdf.com
(General Packet Radio Service), and WAP (Wireless Application Protocol) can be expected to be applied to building data.
Given the schema and schema language dimensions, exchanges can be classifi ed in one of the three main ways listed below:
Direct links use the Application Programming Interface (API) of one system to extract data from that application and write the data using the receiving application’s API. Some may write a temporary fi le in the exchange between two independent applications, others may rely on real- time exchanges calling one application from the other. Some applications provide proprietary interfaces, such as ArchiCad’s GDL, Revit’s Open API, or Bentley’s MDL. Direct links are implemented as programming level interfaces, typically relying on C⫹⫹ or C# languages. The interfaces make some portion of the application’s building model accessible for creation, export, modifi cation, checking, or deletion and the other programming interface provides capabilities for import and adaptation for the receiv- ing application’s data. Many such interfaces exist, often within a compa- ny’s own product family and sometimes through a business arrangement between two or more companies.
Software companies often prefer to provide direct link or proprietary exchanges to specifi c software; they can support them better. The inter- faces can be tightly coupled with, for example, an analysis tool directly embedded in the design application. These interfaces allow capabilities not easily supported through current public exchanges. The functionality of exchanges that are supported is determined by the two companies (or divisions within the same company) that identify certain use cases, defi n- ing where it lies in the design-build lifecycle and the assumed purpose(s).
Sometimes the use cases that motivated the exchange capabilities are docu- mented, but often they are not and thus are diffi cult to evaluate. Public defi - nitions of BIM standards for use cases, outlined in Section 3.3.5, are driving the recognition that all building model exchanges need to have a use case specifi cation, if they are to be relied upon. Because direct exchanges have been developed, debugged, and maintained by the two companies involved, they are typically robust for the versions of the software for which they were designed, and the use case functionality intended. Many exchanges fail because the translators were developed with different use cases in mind.
The interfaces are maintained as long as their business relationship holds.
A proprietary exchange format is a fi le or streaming interface developed by a commercial organization for interfacing with that company’s applica- tion. The specifi cation for the schema may be published or confi dential.
ch003.indd Sec2:107
ch003.indd Sec2:107 3/8/11 6:09:13 PM3/8/11 6:09:13 PM
www.EngineeringBooksPdf.com
A well-known proprietary exchange format in the AEC area is DXF (Data eXchange Format) defi ned by Autodesk. Other proprietary exchange for- mats include SAT (defi ned by Spatial Technology, the implementer of the ACIS geometric modeling software kernel), STL for stereo-lithography, and 3DS for 3D-Studio. Each of these has their own purpose, dealing with different kinds of geometry.
The public product data model exchange formats involve using an open and publicly managed schema and language, such as XML or text fi le. Some product models support both XML and text fi le exchange (IAI 2010a).
IFC, CIS/2, and ISO 151296 are all example public domain interfaces that will be described in more detail shortly.
A summary of the most common exchange formats in the AEC area is listed in Table 3–1. Table 3–1 groups fi le exchange formats with regard to their main usage. These include 2D raster image formats for pixel-based images, 2D vector formats for line drawings, 3D surface and solid shape formats for 3D forms. Three-dimensional object-based formats are especially important for BIM uses and have been grouped according to their fi eld of application.
These include the ISO-STEP-based formats that include 3D-shape information along with connectivity relations and attributes, of which the IFC building data model is of highest importance. Also listed are various gaming formats, which support fi xed geometry, lighting, textures along with actors, and dynamic, moving geometry, and GIS public exchange formats for 3D terrain, land uses, and infrastructure.
As the computer-aided design fi eld has progressed from 2D to 3D and more complex shapes and assemblies, the number of data types represented has grown tremendously. An ordinal charting of this phenomenon is shown in Figure 3–3. While 3D geometry of assemblies is complex, the additions of properties, object types, and relations has led to a large increase in the types of information represented. It is not surprising, then, that the purpose of data exchange has taken on increasing attention and importance, listing it as the most important issue for advanced BIM users (McGraw-Hill 2009). As the richness of data about a building grows, the issues of data exchange shifts from accurate translation to fi ltering just the information needed, and the quality of the information (e.g., is the data an estimated or nominal shape or property or those of a specifi c product?).
A natural desire is to “mix and match” software tools to provide func- tionality beyond what can be offered by any single software platform. This is especially true when diverse organizations are collaborating on a project as a team. Gaining interoperability of different systems used by the team is much
ch003.indd Sec2:108
ch003.indd Sec2:108 3/8/11 6:09:13 PM3/8/11 6:09:13 PM
www.EngineeringBooksPdf.com
easier than forcing all team fi rms onto a single platform. The public sector also wishes to avoid a proprietary solution that gives any one software platform a monopoly. IFC and CIS/2 (for steel) are public and internationally recognized standards. Thus they are likely to become the international standard for data exchange and integration within the building construction industries.
Table 3–1 Common Exchange Formats in AEC Applications
Image (Raster) Formats
JPG, GIF, TIF, BMP, PNG, RAW, RLE Raster formats vary in terms of compactness, number of possible colors per pixel, transparency, compression with or without data loss
2D Vector Formats
DXF, DWG, AI, CGM, EMF, IGS, WMF, DGN, PDF, ODF, SVG, SWF
Vector formats vary regarding compactness, line formatting, color, layering and types of curves supported; some are fi le-based and others use XML.
3D Surface and Shape Formats 3DS, WRL, STL, IGS, SAT, DXF, DWG, OBJ, DGN, U3D PDF(3D), PTS, DWF
3D surface and shape formats vary according to the types of surfaces and edges represented, whether they represent surfaces and/or solids, material properties of the shape (color, image bitmap, and texture map), or viewpoint information. Some have both ASCII and binary encodings. Some include lighting, camera, and other viewing controls; some are fi le formats and others XML.
3D Object Exchange Formats
STP, EXP, CIS/2, IFC Product data model formats represent geometry according to the 2D or 3D types represented; they also carry object type data and relevant properties and relations between objects. They are the richest in information content.
AecXML, Obix, AEX, bcXML, AGCxml
XML schemas developed for the exchange of build- ing data; they vary according to the information exchanged and the workfl ows supported.
V3D, X, U, GOF, FACT, COLLADA A wide variety of game fi le formats vary accord- ing to the types of surfaces, whether they carry hierarchical structure, types of material properties, texture and bump map parameters, animation, and skinning.
SHP, SHX, DBF, TIGER, JSON, GML Geographical information system formats vary in terms of 2D or 3D, data links supported, fi le formats and XML.
ch003.indd Sec2:109
ch003.indd Sec2:109 3/8/11 6:09:14 PM3/8/11 6:09:14 PM