Outline

The following outlines the use of entities already within IFC that are of interest in IFG and identifies some of the new capability that has been added.

Buildings and Spaces

IFC uses a spatial structure arrangement for organizing information according to spatial arrangements. Both the idea of a building and a space are captured within this hierarchy (together with building storey and site). All of these ideas are relevant to geographic information capture either directly or by extension of the current IFC concept:

• Building (also building complex and building section) is used to identify buildings (and other structures within a mapped region. Buildings can be identified according to their:
  • type to indicate the purpose of the building (or other structure),
  • status including whether planning is proposed or approved or whether the building has been constructed (including a history of planning applications)
  • age through the provision of date/time information (also allowing negative dates for archaeological artifacts).
  • footprint of the building onto the ground

• Space (also partial space) which, not only identifies internal space within a building, but can also be extended to identify external spaces required for planning purposes. The space entity can be identified as:
  • a planning zone for community/municipal purposes,
  • an area having special protection, or presenting certain hazards, or having particular properties (e.g. soil properties, geological interest),
  • an identifiable property with legal boundaries (cadastre) and title
  • a space within a property within which building is allowed
  • a space for a prescribed purpose (e.g. parking)

In addition to buildings and spaces, and of interest in a geographic context, the IFC spatial hierarchy also contains:

• Site (also site complex and part of site) as a place where work is carried out
• Building story (also partial building story) for planning purposes and also for more complex city maps

Each type of spatial structure element in IFC has

• a name
• a description
• an object type

The Name attribute is used to store the name of the building, and building story. The ObjectType attribute should be used to specify the type of spatial structure from a dictionary or classified list of acceptable names. It is probable that such names will be defined in a standard feature catalog appropriate to the locality in which the model is used. For instance, in Norway, the type would be taken from the SOSI standard catalog (and eventually from its planned replacement).

To assist with naming, the IFG project in Norway worked with the development of the BARBi dictionary which uses a standard dictionary framework defined in ISO 12006 part 3 and which is designed to be able to work with IFC and similar information models in related industries.

Distribution Systems

Building services are a significant feature of buildings and consequently, pipes and cables are already well covered by IFC. Existing concepts were extended to handle the provision of utility services that need to be identified in GIS. The identification of particular systems is handled by an IfcSystem entity and this is used to group occurrences of distribution elements.

A particular issue with distribution systems however is the extent to which the components of a system are identified by a GIS system. Whilst IFC can break a system down to all of its individual parts (and go right down to the screw in a wall attaching a support bracket), such detail is not typically required in GIS. In this case, the aggregation capability of the IFC model can be used to create less rich component breakdowns with the higher orders of aggregation having separate shape representations that are more suitable to the typical requirements of GIS.

Coordinate Systems

IFC provides a set of entities that enable positioning in the Cartesian coordinate space typically used by AEC/FM systems to be related to known geodetic coordinate systems.

A general coordinate operation (IfcCoordinateOperation) handles any operation (transformation or conversion) between two coordinate reference systems. Presently, only the conversion of a local engineering coordinate system into a map coordinate reference system is dealt with. It is anticipated that future versions will expand upon this provision.

A map conversion (IfcMapConversion) deals with transforming the local engineering coordinate system, often called world coordinate system, into the coordinate reference system of the underlying map. It also allows conversion of the local origin of the local engineering coordinate system to its place within a map (using easting, northing, orthogonal height as the coordinates) and rotation of the x-axis of the local engineering coordinate system within the horizontal (easting/westing) plane of the map. A scale factor is provided for future usage.

Definition of a coordinate reference system (IfcCoordinateReferenceSystem) is by means of qualified identifiers (name of the coordinate system, geodetic datum, vertical datum) only. Interpretation of the identifier is expected to be well-known to the receiving software according to well defined authorities e.g. the European Petroleum Survey Group (EPSG)

Software used to transport IFC models into GIS applications (and vice versa) is expected to have knowledge about the implementation specifications of the Open GIS Consortium.

A projected coordinate system (IfcProjectedCRS) is a coordinate reference system of the map to which the map translation of the local engineering coordinate system of an AEC/FM project relates. The MapProjection and MapZone attributes uniquely identify the projection to the underlying geographic coordinate reference system, provided that they are well-known in the receiving application.

Features

The key new entity added to the IFC model for geographic information is the IfcGeographicalElement. This allows for an occurrence of any type of feature that may be declared in a feature catalog to be used. IfcGeographicalElement is a subtype of IfcProduct and therefore inherits all of its attributes. Thus it can have several concurrent shape (geometric) representations, be classified according to whatever classification system is used, be constructed of identified materials, be grouped into larger geographic elements or decomposed into smaller elements. Most importantly, it can be defined as an type object (called IfcGeographicalElementType) which means that it can have externally specified property sets attached.

Type objects in IFC allow a definition of something to be defined once and then reused many times. Each occurrence of a type object has a unique identifier, location and orientation. Property sets that define type information are defined for the IfcGeographicalElementType. An initial property set (Pset_GeographicElementTypeFeatureCatalog) that captures principle concepts of the feature catalog is published with the IFC 2x3 and is shown below, :

 Table 1 Principle concepts of the geographic feature catalog

Qualified Geometry

Generally, geometry entities in IFC do not have their own globally unique identifier. They rely on the object to whose shape representation they contribute to provide unique identification. However, it has been recognised that, for geographic information and for planning support, there is a class of geometric entities that can be used to show a common idea. An example of this is a contour line on a map. Although theoretically, a line of constant elevation should be able to be interpreted from 3D data, GIS experts associated with the IFG project insisted that the provision of such lines as a distinct entity was a requirement.

Resulting from this, the concept of qualified geometry has been added to IFC. Qualified geometry provides a geometric entity with its own unique identifier. Entities for this are curves, surfaces and vilumes specialised from IfcAnnotation. Thus, qualified geometry with 0D, 1D, 2D and 3D representation can be used.

Although originally developed for contours on maps, the idea of qualified geometry was quickly identified as having more general purpose possibilities. These included the identification of other equipotential lines (e.g. isolux lines for lighting, isobars for pressure etc.), survey areas and survey points, building façade outlines, ground control points, points for location of GPS recording stations and more.

Qualified geometry is identified as a type of annotation within the IFC model as it effectively represents information that would be annotated on a map. Each geometry entity is qualified as to its purpose using the Name attribute inherited from the root entity in IFC (IfcRoot).

Terrain Modelling

IFC already contained all the facilities required to model the shape of a terrain including its representation either by a grid or as a triangulated irregular networkl (TIN). To date, these have been applied to the IfcSite entity.

Proximity

Again a requirement of GIS experts and particularly needed for planning purposes is the proximity of one object to another. Previously, IFC had sufficient information to enable proximity to be determined geometrically (using a geometric query or a specialized geometry engine) but this was considered to be insufficient. As a result, a new proximity relationship was added to IFC that enables not only the capture of actual distances between objects but also the required distance (minimum or maximum) as a constraint. Essentially, this provides a rule directly within the IFC model.

Beyond IFG

In the above, discussion has centred entirely on the requirements for information expressed through the IFG project. However, there are also existing concepts within the IFC model that can be applied to geographical elements that extend the range of possibilities into new application areas. Because entities are being reused, this means that IFC support comes ‘for free’. Maybe not exactly free since guidance has to be given to implementers and the necessary view definitions specified but at least the model does not need further extension. Two key areas are given below. They are not the only possibilities; remember that the IFC model is large, competent and mature so much more may be feasible.

Permits

The concept of a permit to allow work to be done is captured through the IfcPermit entity. This has the specific attribute of a permit identity and also points to a document within which more specific information concerning the permit can be elaborated. Permits are occurrences of the general IfcControl capability that allows constraints or control measures to be applied to specific objects and can therefore be assigned by relationship (IfcRelAssigns) to any product or process. This could be to a building (as a building permit) or to a work order (to allow maintenance work in a sensitive or secure area).

Lifecycle Information

Lifecycle information about objects within a building is as relevant as such information about buildings and other external structures. To support maintenance and facilities management requirements, IFC added information about the service life of objects and the service life factors contributing to the service life determination as part of the IFC 2x2 release. Service life data capture is based on the specification set out in the relevant ISO standard.

As well as to individual objects, IFC also allows lifecycle information about assets (since an asset is considered to be a group of objects treated as a single entity for a given purpose; usually financial or operational).

Further supporting the lifecycle concept is the capture of the condition of objects and the ability to record condition in an event based log. Constraints can also be applied to objects to define trigger conditions at which point some specified action should be taken on the object.

IFC also contains a set of entities that enable cost models to be developed and these can be applied to enable lifecycle cost to be determined (or even the anticipated cost at any point in time given the effect of various influencing factors).

Environmental Impact Information Capture

The cost model in IFC proved to be particularly interesting when the idea of developing environmental impact information arose. It rapidly became clear that environmental impact could be treated in the same way as financial cost (only the units needing to be changed). This led to the development of a general idea known as an IfcAppliedValue. For environmental impact assessment, it can be used to determine things like CO2 emission, sulphur effects and much more.

Sensors

As part of the building controls capability of the IFC model, there is an IfcSensorType entity (whose equivalent occurrence is IfcDistributionControlElement). Various sensor types are predefined including CO2, fire, flow, gas, heat, humidity, light, moisture, movement, pressure, smoke, sound and temperature. Other types can be user defined. Most sensor types also have predefined property sets that handle ranges, set points and other relevant attributes. Sensors can be applied externally as well as internally and identified as sensing various types of external conditions. In conjunction with the new geographical capabilities of the model, this offers the potential to include pollution monitoring as a supported use case (even though it is not yet included on such a support list).