Call for LOD – Linking Scales and Providers Through Digital Spatial Representations

Abstract

This article provides insight into linkages of data within a common spatial ontology over different scales, that are not obvious from the perspective of software interoperability. The aim of text is to stress the importance of the data usage and potentials that open up when large amounts of digital representations comes available. The focus is on industry standards of three scales of spatial design and the potential added value of their data as a by-product of ordinary usage. Samples are chosen to promote the idea that the intelligent usage of standards is far more important and far reaching than the original aim of the standardising.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

This article provides insight into linkages of data within a common spatial ontology over different scales, that are not obvious from the perspective of software interoperability. The aim of text is to stress the importance of the data usage and potentials that open up when large amounts of digital representations comes available. The focus is on industry standards of three scales of spatial design and the potential added value of their data as a by-product of ordinary usage. Samples are chosen to promote the idea that the intelligent usage of standards is far more important and far reaching than the original aim of the standardising.

2 Industry Standards of Various Scales

The most general form of standardising can be found in standards of X3D.¹ Like its precursor, VRML (Virtual Reality Modelling Language), its main usage is to simulate the real-time 3-dimensional computer graphics especially through the World Wide Web. Due to its open XML syntax and ability to encode various dialectics of VRML, NURB geometry, H-anim and various external events, X3D has sometimes been used as an interchange format between other software. The difficulty of adopting a single standard or a single future scenario, either in urban development or in computer systems, stems from the absence of players to manage, maintain or finance the imagined big picture. Examples are chosen to show how these intermediate steps are converging from the strategies of multiple players.

For convenience we define three scales, or levels of detail (LOD), which also divide software into families according to their usage (i.e. GIS, CAD, CAM) and their common data formats. The largest, roughly above the unit size of 10² m is called urban scale. The smallest, roughly within extents of 10⁰ m is in turn called product scale. Finally the intermediate scale sizing on average 10¹ m is called building scale. A brief, and hardly comprehensive, introductory selection of currently available standards in this scale framework could be as follow.

2.1 Urban Scale

• GML (Geography Markup Language ) is a rich XML based language schema defined by the Open Geospatial Consortium (OGC, OGCE in Europe) for geographic modelling and data interchange. There are several OGC approved GML application schemas whose idea is to implement GML in specific areas of interest. For instance one of these, CityGML, is intended to represent a working semantic information model for cities and landscapes.

• KML (Keyhole Markup Language ) (OGC 2008) is a lightweight XML based language schema used primarily by Google Earth and Google Maps. KML specifies only the very basic set of features commonly used in 3D GIS with the possibility to call data from network resources or to point to network resources. In addition it can call geometry described by a COLLADA (.dae) file and offers ways to specify custom schema features. Among other things, these features enable placing other information models inside a KML file (e.g. a full GML model), which provides for one to one data exchange with agreed standards, while others may still use the 3d and geographical information provided by the standard KML.

2.2 Building Scale

• IFC (Industry Foundation Classes ) is a comprehensive schema for building industry information model defined by the International Alliance for Interoperability (IAI). IFC aims to ease and standardize data exchange and management at all stages of a building project. That is to say from early planning via building management all the way to eventual demolition. Currently the ready to use IFC-schema struggles with lacking implementations of data exchange use cases. IAI seems not to encourage separate implementations with smaller scope of data exchange such as what we see on the geographic side by OGC.

• IFG – (IFC for GIS) extended IFC schema. IFC format only supports one ­geographically correct location (IFCsite) point. The purpose of IFG is to address this issue by introducing entities that provide for Cartesian – Geodetic coordinate transformations. Furthermore it enhances IFCs’ geographic data capabilities, with the aim to enable IFC – GML transfers.

2.3 Product Scale

• Geometric Description Language (GDL)² is a trademark of Graphisoft R&D zrt. It is the programming language used to control their main product ArchiCAD. GDL is widely utilized by ArchiCAD users and architecture related manufacturers to create parametric objects for use in ArchiCAD. Despite its proprietary nature GDL is well documented and third party use is encouraged. Graphisoft has a tradition of publishing interfaces to ease GDL data transfer to other formats and CAD systems.

• Design Web Format (DWF) is an open³ distribution and communication format by AutoDesk (AutoCAD provider). The purpose of this format is to transfer design information and design content to users in highly compressed form over the web. The characteristics of DWF focusing on page description and 3D models are in fact very similar to any ‘digital paper’ formats, say for example, Adobe’s Portable Document Format (PDF) developed from the early 1980s PostScript (PS) page description language.

When observing the data structures available for coding physical objects and their interaction into a formal representation, we see a clear pattern. The least common denominator of these chosen standards is that all of them are able to store data in the form of nested spatial descriptions and their alphanumeric properties. Ontologies, in the general sense of formal representation, are therefore found in two levels of interoperability in these standards: First in the specifications level, where the common geometrical characteristics of entities and their geographical reference system is defined (using a core reference ontology of geometrical object) and, second, in view definitions level. We shall take a closer look at these basic distinctions that open up some major issues of interoperability as a whole.

3 Interoperability

The organizations developing various standards have a tendency to work towards considerably broad, all-inclusive presentations of their subjects. In data management this paves a path for nearly universal all inclusive file formats. This approach of carefully detailed standardization process is commonly found in the old expert systems tradition. Intuitively this means breaking the unimaginable field of possibilities into atoms and classifying each piece of information that may potentially exist. At first sight this seems the best way to guarantee universal interoperability. But does the solution really lie in carefully designed file format schemas, where each piece of information and its relation to the processes in which it is generated or used? All this worked perfectly in an ideal, reductionist and somewhat closed universe.

Since the data stored in digital information systems and data warehouses has proven to be more and more valuable if properly collected, managed and made extensively exchangeable. Case is therefore an essential requirement of computer systems. In general it is an issue of how diverse systems and organizations achieve their skills for working in a common ground. More technically speaking we refer to the definition of the Institute of Electrical and Electronics Engineers, which defines interoperability as an “ability of two or more systems or components to exchange information and to use the information that has been exchanged.” (IEEE 1990) (Fig. 8.1)

Fig. 8.1

Interoperability pyramid (Adapted from Hietanen 2006). The size of a block indicates the required ontological skills necessary for development work. This can be seen as supply or opportunity side of ontology development

Hietanen (2006) stressed the importance of different levels of interoperability and ordered them in an Interoperability Pyramid. A characteristic of the pyramid is that the number of people involved increases (Fig. 8.2) while the level of interoperability skills decreases (Fig. 8.1), when moving from the Specifications level towards the Deployment layer of everyday business activity. Remarkably, the transferring intermediate layers of View definitions and Interoperability know-how levels are underestimated in traditional vendor led implementations development.

Fig. 8.2

The demand or need side of interoperability pyramid. The bottom-up approach indicating the number of potential users exploration/exploitation of ontologies

In ontological terms one could roughly state that:

• the specification layer corresponds to a core reference ontology (say IFC for example);

• the view definition layer refers to a domain ontology (a building in construction domain) or sub domain ontology (an electrical device object in the construction domain);

• the implementations layer matches up to an application ontology;

• the know-how level is based on knowledge which enables several application ontology to exchange data that is to say taking benefits of the same core reference ontology. This phase tests that the data exchange is possible and proposes some correction if necessary in the implementation layer.

The View definitions layer is commonly seen as a subset of the specifications schema (Hietanen 2006). But thinking carefully one suddenly realizes that the scope of these views is not limited into complete overlapping with specification layer. It is true that View definitions actually provide multiple perspectives into the same specifications, but, and to understand the big picture of interoperability this is crucial: it also allows a derivation of information that is not explicitly defined in layers below. In this scheme additional processes, transitions or specific paths of behaviour for derived entity based on lower level information may be acquired. For example some of the derived spatial information may naturally be included in the specification level, like the explicit degree value to define spline geometry, a convex hull of point set or  <  marquee  >  tag in HTML, but equally well these can be handled in view definition level as dynamic manipulations of specifications layer. Further examples of these are, the derivation of spatial enclosures, combinatory forces, or proximity based fluid of field descriptions, which are usually formalized for a software end. Therefore the end-usage is by definition richer than its ontological base: If a picture is worth 1000 words, following our examples it seems fair to state that 3D models of spatial representation are worth more than 1,000 pictures.

This leads to layers that are theoretically neatly organized in a pyramid shape. But in reality the pyramid is highly skewed and distorted, because of overlappings that are only partial (Fig. 8.3). This is the picture even with any commonly recognized standards and proprietary data formats, so from the usage point of view any data opens up far more potential usage possibilities than a specification definitions originally ever wished for. The same is in fact true in the Interoperability Know-how level, which is best seen in numerous examples when a software usage or data definitions are taken in extensive use beyond their intended purpose.⁴

Fig. 8.3

Skewed interoperability pyramid in reality, which is the result of the top-down ontological opportunities facing the bottom-up exploration/exploitation of user-end

It may be true that there is a high concentration of skilled professionals working at the ontological definition level, but this group is also sufficiently small if compared to numerous amounts of players when moving towards the implementations and deployment layers. This “wisdom of crowds” leads into different interpretations or implementations of the concepts described in the core reference ontology. Therefore we focus on the demand side effect of interoperability describing the demand side of software development that can be seen as the pulling force that eventually challenges the flexibility and therefore the adaptive capabilities of various ontological definitions.

In the following text we challenge the traditional top-down approach of business administration and software development and provide alternative examples to outline how the Interoperability Know-how layer serves as an active component in steering the Implementation layer and adding requirements down to the ontological bases of the Specification layer. Most strikingly the needs of the Deployment layer are an open-ended pool of user-driven activity, which shifts the interest from proper usages to creative misuse. Today the ownership of a format or even data content is simply not good enough for effective business, but setting them free might be.

4 BIM and Overwhelming Spatial Knowledge

In sharing information of the building and urban design activities level, two competing methods seem to be possible. In short they can be described as exhaustive (or detailed) and general (or loose), although in reality the classification is often quite indistinct and may greatly depend on the observer. Examples of these different approaches and their uses are the utilization scenarios of GML and KML. Neither can yet be called de facto standard for spatial data transfer while both have what it takes to become one; for profoundly different reasons however.

It is interesting to note that the richer professional level file formats mentioned earlier – GML and IFC – are indeed progressing on their way to wider use. The corresponding developing organizations however have different tactics. IAI (behind the IFC standard) works hard to achieve one universal implementation, while OGC has allowed for several co-existing application schemas (i.e. implementations) for GML. This also implies that their potential drawbacks should differ.

GML is already used all over in wildly varying application schemas. All these application schemas will not be supported indefinitely. This leads into backwards compatibility issues. As an example of backwards compatibility only think of all those text documents created before the WordPerfect (and later MS Word) breakthrough. Can you display them now as intended back then? Unfortunately you’re sometimes lucky to get even the plain text out.⁵ So currently, instead of just one GML, we have many still workable – application schema that are sometime fragmentary. IFC however does not even have a working implementation yet but at the end only one is expected – a complete and detailed one. The drawback of this scheme is that due to its aimed comprehensiveness and required level of knowledge, it also effectively inhibits reaching the critical mass necessary for large-scale implementations (Fig. 8.4).

Fig. 8.4

Smart aggregation of nearly identical ingredients

Fortunately the world is not completed. The inventor of blank paper didn’t rush forward to make rules to exploit the usage, but left the functional definition open. It is the same with data structures: You never know what can be baked from the same ingredients. The point to make here is that any given piece of information or data structure is defined according to an original application or software requirement. But several different applications (software) can reuse these data structures to achieve a different requirement. Naturally this is very context and user dependent. The growing computer literacy brings about more and more occasions where talented laymen may solve their intellectual need themselves if only a proper platform to build on is given.

5 Consumers’ Pull of Product Scale

To simplify things somewhat, let us assume that there really is a clear distinction between products, buildings and cities. A product is an instance, a building is an individual entity and a city is a world populated by individual entities. A first observation may be that in reality this shift form minor products to large scale urban agglomerations is more a slider than a three-stage switch, but it becomes clear that in fact each level may be defined as an entity with its constituent parts. This chosen definition of nested partitioning in part helps explaining why, for example the term building product model was such short lived and why more generic discussion of ontologies in building sector become appropriate. It also helps to put contemporary thinking in perspective.

Architects and designers have long ago entered into product oriented development scheme, where the design process is more a task of combining certified (or standardized, tested, quality approved, law suit minimized, and so forth) components into house aggregate than the traditional process based on availability of raw material. So to be honest, when setting the hard-core professional role a bit aside, actually one must admit that the so-called professional activity doesn’t considerably differ from ordinary laymen supermarket shopping activity. Therefore it is not surprising that companies, for example in furniture industry, have taken advantage of professional-feel computation tools to support their customers’ possibilities for making plans of their own.

Naturally at the bottom line the disagreements are found on style, or lack of it. We should realize that the provider wants to push the designer (or any client) towards buying the maximum amount of their products. Thus their design software looks more like a boring order form than an intelligent software agent able to combine adequately their product. We are certain that not only designer professionals need to have a capability to combine products of different providers, but also generally people feel slightly uncomfortable with the idea of adopting only one registered trademark lifestyle. Despite this small drawback the single provider’s point of view has already span-up a new kind of do-it-yourself activity, but something more is needed for enhanced creativity.⁶

To give a test for this, we thought of giving it a quick try. We will illustrate our opinion that the designer of any system cannot have a control over future usage of it. So we’ll assess the unused potential of freely downloadable Furnish software family (Pro & Lite versions). Furnish is a spin-off development of DesignTime (or RunTime)⁷ by Geac Computer Corporation Limited and both tested version of software are released as freeware. Especially the Lite version is distributed under several names, probably best known as IKEA home planner (Fig. 8.5).⁸

Fig. 8.5

Furnish snapshots of ordinary house with furniture of multiple suppliers: Kitchenware by KVIK & IKEA, sofa by Club 8, childrenware by Flexa and shelves by Montana. In these pictures only missing piece are the personal items

Despite the providers’ attempt to secure intellectual property of their designs the software contains the pieces of furniture installed in a single ‘library’ in program’s system folder. With a minor crack⁹ every layman can get the same professional-feel functionality out of this freely distributed software. In the Pro version of Furnish additional features are available and the users are able, for example, to import and export CAD files in DXF-format,¹⁰ to render¹¹ their homes in enhanced detail and eventually to get the up to date price of their dreams. It is important to stress that all these data are already downloadable from Internet and are available to anyone with sufficient skill about Interoperability know-how. Most surprising of all, a whole new market could open up with minor conversion from currently proprietary data format. These conversions permit easy and free access to digital copies of products for any virtual environment.

So where’s this all taking us in data specifications? On one hand the semantic web as described by W3C¹² has not yet kicked in and has even evoked some resistance in the Web community.¹³ But, on the other hand, behind the scene Google has built a little piece of “semantic” web of its own with its georeferencing based Google Earth and its KML content.¹⁴ Indeed many service providers are currently expanding the so-called Web 2.0, which the renowned W3C sweeps away as “a piece of jargon”.¹⁵ In any case, many content rich services do not comply with W3C standards, especially ones with user generated content, although most of them can be accessed through specific APIs. The simplistic, but extendable nature of KML complies well with something called ‘the useful minimum’ approach to sieve necessary and sufficient content for end use. Only once the feasibility is demonstrated is it time to gradually move towards full utilization. Since the core of KML semantics is spatial information it is inherently useful for sharing GIS based spatial content (Fig. 8.6).

Fig. 8.6

Snapshots of W3C Markup Validation Service results January 30th 2009: four out of six major web sites didn’t pass the most basic html-validation process. From left: W3C Semantic Web page [http://www.w3.org/2001/sw/], Wikipedia Main page [http://en.wikipedia.org/wiki/Main_Page], Wikipedia Semantic Web page [http://en.wikipedia.org/wiki/Semantic_Web], Google Search page [http://www.google.com/], SourceForge front-page [http://sourceforge.net/] and Facebook Login page [http://www.facebook.com/index.php] (Results with errors presented in inverse coloring for clarity)

The major benefit of Google’s KML file format is, that it allows embedding of user defined data in a KML-model. It is certainly not the only spatial data format with this ability, but it is the lightness of the initial schema that makes it an interesting target for user modifications and one to one interoperability agreements. Its flexibility makes KML not only a beautiful companion for GML, but also a good competitor. KML developers say that it is up to the users to decide on the necessary semantics.

There are already more than just weak signals that KML may soon be another OGC standard along with GML, because its role among popular applications like Google Earth will promote its use like web browsers promote the use of the HTML language. This suggests that KML is to GML like the envelope is to a letter. GML defines which data should be stored because it is an interchange format. KML is an implementation format using the data defined in GML and making these data interpretable by Google Earth application. The importance of KML will depend on the success of those applications. It may be worth noting that the idea of the so called semantic web largely depends on the popularity of the interchange formats based on XML (GML, KML, IFC, etc.).

6 Scale Leaps Through the Universe

This trend in shift from professional tools to penetrate everyday usage is analogous to vendors who want to increase their sales by proposing their products in TV-shopping. Remarkable work towards ubiquitous computing usage is done in CASA UCL to link up various key activities of urban design and analyses to Google’s SketchUp, Earth and Maps API (Hudson-Smith 2007; Hudson-Smith et al. 2007). At their best, these examples lead into free usage of urban analysis functionality (Gibin et al. 2008) or routing and geocoding (Gilmore 2008) for practically anybody; or at least without need for proprietary GIS. The current innovations are made in the level of intelligent usage and a combination of existing open geodatabases, which already at the moment are rich enough to produce a user-driven pull of interoperability.

Similarly building industry could benefit from the same approach. It often finds itself somewhere in the middle of scales and created some confusion trying to guide the unguidable. CAD-programs are the tools of choice for building industry since physically a building resembles more a chair than a city, not to mention a landscape. They evolved in mass production oriented industries, which were one of the first to utilize 3D product models intensively (to control manufacturing etc.). From that background the logical conclusion seemingly was to use product modelling tools for buildings too. However the findings were symptomatic: houses are so much more complicated than chairs that such a model is almost incomprehensible. Due to performance problems there simply wasn’t any software to display it either. Also there is usually more than one person designing a house and their plans always overlap. Hence the best practice has been to use partial models. IFC is an attempt to bring these partial models together by enabling data exchange across the field. The purpose is to eliminate the need for multiple inputs.¹⁶

Incorporation of 3D data in KML schema suggests it could also be used to share BIM content. The recent addition of user defined extended content especially in XML format makes it applicable for building large-scale urban models with access to dedicated BIM and GIS data. These models could be created in variety of custom designed information model formats (e.g. IFC, CityGML) and even their basic KML representation automatically generated from the original data. The publicly accessible models would carry unclassified information content and serve as link to detailed information to authorized users either by query or direct download. The big idea of course is that the data creation methods (application base, work paths etc.) need not be changed at all; rather the finalized entities would be transferred to appropriate representations.

Fortunately some patterns seem to be converging here. Taking freedom to imagine the necessary associations and linking the previous analogy of LOD in data formats to the scale jumps between physics, chemistry and biology; we realize that an implementation and further emergence of a large, universal file format is not too different. The actual problem caused by exponentially increasing number of entities and their innumerable arrangements can be sensed even in a modest sized stock of building blocks.

For more advanced usage of BIMs the key feature to overcome these multi-scalar view and specification difficulties is bound to a concept, which the gaming industry knows as Level of detail (LOD). At the specification level formats like KML have moved from implicit threshold definition to explicit LOD coding and IFG has taken first steps into that direction too. The need for explicit threshold definition is necessary to screen the system from a combinatory explosion and prevent it choking to incoming data. The specifications are largely missing scaling definitions that are commonly found in intelligent raster formats organized in pyramid manner (like MrSID etc.) It is more commonly handled at software end and requires heavy calculations of convex and concave hull, bounding boxes and envelopes or vertex splits and progressive meshes. (Slater et al. 2002) Taking this into the specification layer clearly leads into lighter or more efficient implementation layer as Google Earth has already proven. Additional resources would be ­welcome at the user-end.

7 Open Problems and Research Challenges

A major challenge of understanding the progressive nature of technological advancement is related to re-thinking the interoperability as addressed above. All above-mentioned interoperability issues, which by and large are led by advances in the Interoperability know-how layer, could make direct references to more a generic evolutionary base. The challenge for development is the commonly known Darwinian concept of pre-adaptation . Following the argumentation of theoretical biologist Stuart Kauffman, the idea of pre-adaptation simply means that a part of an organism might turn useful in an environment even though the development of that part was never a favoured characteristic itself. Kauffman (Brockman 2003) explains the idea of pre-adaptation with Gertrude, an incredibly ugly squirrel with flappy skins in armpits. Its evolution to flying squirrel happened only because this characteristic turned the jump into soar and enhanced its success in evolutionary selection. But importantly for us, in a strict sense it was never designed. The same can be found similarly from the evolution of a swim bladder or mammal ear that never was designed for the purpose we currently recognize them for. Following Kauffman’s argumentation the same is by and large the case in the evolution of the technosphere as well. To take an example of computer: The early machine for ballistic calculations and code breaking was never thought of as the Internet. We simply didn’t see that coming. Moreover in the Internet case, we realize exactly the same: It was never designed for Facebook or multi-player role gaming. We simply didn’t see those coming either. If there is anything to learn from these general examples, it is that the strongest or even the most intelligent are not the ones who survive, but the ones that are most efficiently breeding and adapting. To support even more complex pre-adaptation in an ultimately open universe the characteristics that really count are bound with overwhelming information, flexibility and diverse by-products.

Similarly also GML, IFC and GDL based objects all provide in their current state a digital representation that is potentially far more valuable than the objects themselves. When considering Internet repositories and data warehouses already being filled with different digital representations of everyday objects, it is easy to see that they actually provide undergrowth of large-scale virtual environments. A simple example of a multi-scale 3D repository is the 3D warehouse of SketchUp (Google 2011), which contains spatial models at all scales , from building products¹⁷ to hard core architecture competition entries¹⁸ and digital cities.¹⁹ Thinking only an additional implementation of registered EPC-type (Electronic Product Code²⁰) ID to provide a unique identity to objects and the linkage between virtual and real environments is ready for (Fig. 8.7).

Fig. 8.7

Emergence of second reality from digital representations

Implementation layers with advanced LOD are currently able to provide a ­simulation of real time physics and other modelled interaction. If we compare, say, the development of game engines, it is clear that major leap in technology was made, not in attempts of protecting gained knowledge, but setting it free. Games like Quake and Doom some 10 years ago changed the scene. Not only was the true 3D environment groundbreaking, but also its open ‘free to hack’ attitude unseen. The first opened up a possibility to replay parts of a game as recorded demo sessions, but the latter was an enabler of machinima. Film industry had been for a while able to use 3D animation in real time, but unless you happened to own 300,000 dollar Silicon Graphics environment, you should think other business. New game engines quickly filled the gap and created a new genre of movies based on 3D engine called machinima (contraction of machine and cinema) (Carless 2005). Actually the step towards the beneficial use of representations of real environment is so short that it is nearly taken.

Looking up all digital representations scattered around Internet in form of products, buildings and cities, it is easy to see that we are literally just one step away of the potential of uploading ones everyday life in massive quantities into Second Life-type environments to augment social interactions when needed. Chosen examples in this article are meant to outline potential emergent development paths of available standards of spatial representation that are far from being controlled by any specific level of interoperability, but lead from the open-ended user creativity. More generally speaking examples are chosen to appreciate the complex wisdom of Jean Baudrillard’s prophetic words outlining the true future prospective of IT development: “Information can tell us everything. It has all the answers. But they are answers to questions we have not asked, and which doubtless don’t even arise” (Baudrillard 1990, 219).