21 Apr 2008 - Spatial Infrastructures, IFC & Collaborative Engineering

A new generation of spatial information infrastructure is in the works, one that promises to move us beyond the ideas of map portals and small scale information sharing, to collaborative planning, design, engineering and development of the built environment.  We touched on these ideas in a previous blog related to BIM/CAD/GIS integration.

Conventional ideas of Spatial Information Infrastructures (SDI) have been driven by national mapping agencies and have been largely focused on the resources to catalogue and provide access (portals) to small scale maps and related data sets.

Some organizations, including Galdos have been trying to move the concept of SDI more toward real time integration of distributed spatial or spatially related databases, an approach which is more consistent with multiple interacting players, and with real time or near real time information sharing.  Our approach is one that naturally extends to embrace to notion of BIM, and IFC, and in particular the role of SDI (based on BIM and IFC) in a collaborative planning, design, engineering and development of the built environment.  The concept is illustrated in Figure 1.

Figure 1.  Spatial Infrastructure Supporting Collaborative Engineering

Note that this approach to spatial infrastructure, emphasizing spatial database integration is equally applicable to the national mapping scenario as it is to supporting the management of built infrastructure.  The role of the spatial infrastructure is to enable database synchronization by enabling the user specified creation/maintenance of publication subscription relationships between the participating databases.  This allows for efficient movement of data, and is relatively non-intrusive with respect to the use of existing design, engineering analysis, engineering and architectural visualization, and mapping tools.
Note further that while we show a set of data suppliers in the bottom part of the diagram, any data consumer (the engineering, architectural etc. tools in the top half) can also be a data supplier.  The data suppliers in the bottom half are distinguished only in that there are typically government and private sector data collection activities (e.g. aerial, land survey, property management) which are not directly part of the engineering and planning process.

One can also view Figure 1. in even simpler terms as shown in Figure 2.

 
Figure 2.  Simplified Version of Figure 1.

As one thinks through the role of the Spatial Information Infrastructure in support of the management of the built environment, several things become clear.  One is the increased importance that we must attach to time.  Participants will not only want to know the present state of what is being built, but also what is to be built next month,  and what is planned for next year.  As time horizons are extended it is important also to be able to distinguish between what is proposed (there may be conflicting proposals) and what has been approved.  Moreover, what has been approved today may be cancelled in the future.  All of this adds an additional level of dynamism to our concept of SDI, so much so that we need to think in terms of spatial-temporal information infrastructure.

The built environment also demands support for more elaborate notions of the management of space.  Structures are inherently 3D and the range of geometric scales is necessarily large.  It is essential that we take a feature-based view of such infrastructure as now being elaborated in standards like Industry Foundation Classes (IFC) of the IAI and cityGML from the OGC.  

Our notion of a Spatial Information Infrastructure must also take into account the process(es) by which the built environment is developed.  This means that the notion of engineering projects must also be supported, so that through the infrastructure disparate teams of engineers, architects and developers can co-operate with one another.  This implies the sharing of project milestones and their associated engineering and architectural deliverables, and possibly deeper aspects of the project architecture (tasks, dependencies) and associated deliverable artifacts.

This is not your father’s notion of SDI.

Comments

No comments yet.