Data and Objects

For years, the main-contractors and internal suppliers at Amsterdam Airport Schiphol maintained their own sets of drawings that described the as-is situation of the airport. This meant that even a larger number of ‘truths’ were being maintained than was already the case within Schiphol. There are two possible reasons for these organizations to keep their own datasets:

The data at Schiphol did not match reality. As a result main-contractors and internal suppliers used their drawings to create their copy of reality.

A better vision on the ‘truth’ then your client creates a dependency, which will potentially lead to additional projects in the future.

With SGIS, Schiphol wants to show one truth for everybody, including the main-contractors and internal suppliers. Now these stakeholders must be convinced to start using SGIS as the one-and-only truth. It can be doubted whether the situation at Schiphol stands on its own. I think that it can be expected that there are many more asset management organizations having this same problem. This is not only a problem because of the multiple truths that are created (and which one is correct?), but mostly because of the wasted resources due to double work.

For large projects an increase can be seen in the application of the BIM methodology during the design and construct stages. In the majority of these cases this also means a transformation of geometry in the design models from 2D to 3D. It is obvious that this switch has a major impact on the exchange of data over the different life cycle phases. As long as the data stays within the same software environment when it passes on to the subsequent life cycle phase, I do not expect that there will be many problems with the data exchange.

A potential issue with 3D geometry in the exchange of data was already shown in figure 8 on page 12. Because of the geometrical differences in the current data models of IFC and SGIS, it is hard to convert the Figure 33. Software use within the asset life cycle

geometry in the right manner. This is because SGIS can only support multi-patch features at this moment, while IFC is supporting 3D solid objects. Each type of software uses a different technique to build and store 3D geometries. Different ways to build up and store a solid object can exist within a single software package. It can be expected that the differences between separate software packages are even bigger (Van Oosterom, Stoter, & Jansen, 2005). Examples of different solid types are SweptSolid, CSG and B-Rep (Wu & Hsieh, 2007, p. 1086). The differences can be found in the way these solid objects are described. An analysis of the different type of solid objects is outside the scope of this thesis research.

There are also examples of software packages that are not capable of handling solid objects. Some cannot handle 3D geometries at all and other packages use different techniques to represent 3D geometries, such as the earlier mentioned multi-patches. When solid objects are compared with multi-patch objects, some potential problematic issues come to front. Multi-patch objects are, for example, not necessarily closed, a constrain that is demanded for solid objects. Another issue with multi-patch objects is that it is not possible to calculate their volume, for example because some applications, like FME, do not accept a multi-patch object as being a 3D primitive.

In current GIS data models for asset management, objects are mostly stored in 2D. I think that for the purpose of asset management this is sufficient, as long as height differences are limited. When I look at SGIS for example, the data model is oriented on building levels. In most situations this will do, maybe a maintenance crew needs a ladder to reach for some assets, but it will provide a sufficient overview. However, a large hall, like the entrance of Schiphol, will benefit from a 3D view, because it gives a more realistic view for a certain situation.

If you want to use a 3D geometrical object, you also need to think about whether a top view offers the appropriate image. Often the footprint of such a project is wanted, which makes it necessary to store multiple representations of the same object, for example a 2(½)D and a 3D representation. It is needed to analyse the possibilities to store multiple representations of the same object. And if you want to store multiple representations, it is also important to look at the most appropriate way to extract them from your design model.

The last aspect for data and objects that can cause troubles during a data exchange involves the level of detail. Differences in the level of detail between two phases in the asset life cycle phase can be a cause for information loss, especially if an LoD in the first stage contains more detail than in the subsequent stage. It is than the question whether the details from the previous need to be preserved and if so, how they need to be preserved.