Publication Date: 2021-03-23

Approval Date: 2020-01-03

Posted Date: 2019-02-01

Reference number of this document: OGC 19-081

Reference URL for this document:

Category: Public Engineering Report

Editor: Josh Lieberman

Title: MUDDI v1.1 (Model for Underground Data Definition and Integration) Engineering Report

OGC Engineering Report


Copyright © 2021 Open Geospatial Consortium. To obtain additional rights of use, visit


This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.


Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.


This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.

This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

1. Summary

The Underground Infrastructure Concept Development Study (UICDS) Engineering Report [1] examined the present state of underground infrastructure information (UGII), costs and benefits of that state, as well as future opportunities for an improved state. That report describes a number of candidate models for UGII and recommends a number of follow-on activities, including development of a prototype UGII integration model to support subsequent UGII integration and exchange initiatives. A follow-up workshop and model development effort resulted in another engineering report describing an initial (1.0) version of the conceptual UGII integration model MUDDI (Model for Underground Data Definition and Interchange) [2]. The present updated report describes MUDDI version 1.1. The goal of MUDDI is to serve as the basis for integration of datasets from different models, at the levels of detail required to address application use cases described in [1]. MUDDI as described here is a conceptual model which will serve as the basis for one or more conformant and interchangeable logical and physical implementations such as GML (Geographic Markup Language) or SFS (Simple Features SQL). The current version 1.1 of MUDDI has been updated and refined from the initial version 1.0, but is still intended to serve as an input to the proposed OGC Underground Infrastructure Pilot as well as similar implementations and deployments in realistic application scenarios. The present model is also suitable as input to begin development of a formal conceptual model standard.

1.1. Requirements & Research Motivation

The development of MUDDI has been motivated by a number of specific design requirements described in the Overview but the principal motivation has been to achieve compatibility and minimal information loss with regard to data represented by several significant existing models and model standards, in order to support both data interchange and data integration across a variety of underground infrastructure components, functions, and associated environmental properties.

1.2. Prior-After Comparison

Findings presented in [1] describe the present generally inadequate state of UGII in many cities and suburban regions. The model presented here, and subsequent pilot activities based on it, along with needed policy, financial, and cultural advances, have the potential to improve UGII quality, reduce incurred costs, and provide numerous opportunities to improve how cities function.

1.3. Future Recommendations

Naturally, publication of a prototype MUDDI is intended to support both the proposed Pilot initiative, as well as development and approval of complete conceptual and implementation specifications.

1.4. Document contributor contact points

All questions regarding this document should be directed to the editor or the contributors:

Table 1. Contacts
Name Organization

Josh Lieberman, editor

Tumbling Walls

George Percivall


Alan Leidner


Carsten Roensdorf

Ordnance Survey

1.5. Foreword

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

2. References

The following normative documents are referenced in this document.

3. Terms and definitions

For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard OGC 06-121r9 shall apply. In addition, the following terms and definitions apply.


This term has a precise definition as the primary component of the Earth’s pedosphere. It is used here in a more general sense to refer to all overburden earth materials in the underground environment, including soils, sediments, and construction fill, that might surround and support underground infrastructure components.

Subsurface Infrastructure

See Underground Infrastructure

Underground Environment

Material forming the ground in which underground infrastructure is embedded, and its aspects such as geology, hydrology, chemistry, and engineering properties. This term also covers dynamic subsurface processes such as physical deformation, fluid flow, and chemical / biological alteration.

Underground Infrastructure

The totality of built components or structures embedded below ground surface that are part of services such as utility networks and/or that support ground surface structures.

Underground Infrastructure Information

Information collected about or pertaining to Underground Infrastructure

Underground Infrastructure Information System

Computing system or platform that manages information pertaining to Underground Infrastructure

4. Overview

The Underground Infrastructure Concept Development Study (UICDS) Engineering Report [1] examined the present state of underground infrastructure information (UGII), costs and benefits of that state, as well as future opportunities for an improved state. That report describes a number of candidate models for UGII and recommends a number of follow-on activities, including development of a prototype UGII integration model to support subsequent UGII integration and exchange initiatives. A follow-up workshop and model development effort resulted in another engineering report describing an initial (1.0) version of the conceptual UGII integration model MUDDI (Model for Underground Data Definition and Interchange) [2]. The present updated report describes MUDDI version 1.1. The goal of MUDDI is to serve as the basis for integration of datasets from different models, at the levels of detail required to address application use cases described in [1]. MUDDI as described here is a conceptual model which will serve as the basis for one or more conformant and interchangeable logical and physical implementations such as GML (Geographic Markup Language) or SFS (Simple Features SQL). The current version 1.1 of MUDDI has been updated and refined from the initial version 1.0, but is still intended to serve as an input to the proposed OGC Underground Infrastructure Pilot as well as similar implementations and deployments in realistic application scenarios. The present model is also suitable as input to begin development of a formal conceptual model standard.

4.1. Design Requirements

The development of MUDDI has been motivated by a number of specific design requirements:

1) Functionality

The model should specifically address three priority application use cases (Excavation, Large-scale Construction Design, Disaster Planning)

2) Compatibility

The model should derive from or map to/from existing candidate models such as INSPIRE [IUN] (Infrastructure for Spatial Information in the European Community), CityGML UN ADE [CUA] (Utility Networks Application Domain Extension), GeoSciML [GSML], or IMKL [IMKL] (Informatie Model Kabels en Leidingen).

3) Modularity

The model should have a modular structure with a simple mandatory core and additional elements in the form of optional extensions or interfaces, in order to minimize the quantity and detail of data required for specific use cases.

4) Traceability

The model should provide for UGII to be linked directly with the survey measurements, sensor observations, and supporting evidence from which it was derived and from which its quality can be determined.

5) Flexibility

The model should support implementations that include the geometric and topological representations needed for specific applications, such as 2D geometries for excavation planning, 3D geometries for construction design, or functional graph topologies for disaster vulnerability assessments.

4.2. Design Patterns

There are a number of common model design patterns which might satisfy MUDDI requirements, particularly modularity and flexibility:


the pattern of fixed tables connected by foreign key relations. Clearly an established implementation pattern, but tends to result in duplication of data to support specialization and rather brittle relationships between model elements.


an extremely flexible pattern of data elements connected by diverse relation predicates tends to represent knowledge webs and physical networks very well, but is still hard to implement for spatial data.


inheritance patterns are particularly well suited to UML modeling, but specialization hierarchies themselves can lack flexibility in terms of being able to choose different configurations of specialized attributes for specific applications.


a variant of the object model in which specializations can also be supported by the addition of interface elements (consisting of attributes and/or operations) to primary objects. Interfaces can be mixed and matched as well as reused for different primary objects, but the variety of ways in which they can be implemented may present a risk of non-interoperability between implementations.

4.3. Report Structure

  1. Description of application use cases, priorities, and derived model requirements

  2. Description of candidate model scopes, characteristics, goals, strengths, and weaknesses

  3. Overview and narrative of the MUDDI Unified Modeling Language (UML) model

  4. Details of individual MUDDI modules / interfaces and the use cases they address

  5. Mappings between MUDDI and elements of significant existing models

  6. Guidelines for MUDDI implementations

5. Use Cases and Derived Requirements

The following 6 UGII application use cases are detailed in [1] and the first 3 use cases are considered a priority for the OGC Underground Pilot.

5.1. Use cases

  1. Routine street excavations (EX)

    There are on average between 30 and 40 excavations annually per mile of roadway in many developed areas. Since urban and even suburban underground space is typically crowded with many different utility lines, most jurisdictions require that utilities share their data at the location of a proposed excavation in order to avoid utility strikes, which can cause extensive damage and result in significant costs and delays. In many cases, mark-up crews must locate records for the street in question and bring them out into the field in their vehicles. Information sharing and collaboration consists of "graffiti-style" sketches made on the street with spray paint or chalk. Getting all the utilities to respond routinely takes several days to a couple of weeks – if essential records can be located at all. The effectiveness of the street markup process depends upon the often questionable, rarely documented, and even more rarely tested accuracy and completeness of the records being referenced.

    With utilities records in standards-based digital formats, information requests can be answered with digital submissions from each utility. Because the utility data is in a common format, it can be seamlessly integrated by excavators and used to guide underground work. Modern methods of data exchange, including wireless communications to mobile devices in the field, then make it possible to rapidly assemble utility information directly in the field, potentially lowering the strike risk and also reducing the time to mitigate strike hazards from days or weeks to minutes.

  2. Planning, design and construction of large scale projects (AE)

    Cities and other large jurisdictions undergo constant change. At any one moment there may be a dozen or more new projects on the drawing boards and in construction. It is in the interests of these jurisdictions that new development be as economical as possible: that costs are held to a minimum and that projects are completed on schedule and in budget. To meet these objectives, project planners, engineers and architects need access to the best possible information to guide their plans and designs. They need to know if the capacity of utilities and characteristics of the underground environment can support the scale of the project envisioned. They will also need to know precisely where those utilities are located in order to properly plan building foundations and new building service connections. Answers to these questions require access to high quality information in a form that is straightforward to integrate and analyze.

    Comprehensive and interoperable information about existing infrastructure networks is a pre-requisite for efficient planning and design for major new development. Information about existing and potential natural conditions is also essential for assessing both impacts to the environment and vulnerabilities to events such as flooding, hurricanes, and earthquakes. All of these need to be appropriately accounted for in good designs. When data are incomplete, incompatible, and difficult to find, this can lead to unduly large contract contingencies as well as significant delays in moving forward. Once construction does commence, unexpected discoveries of serious underlying conditions too often require very expensive change orders and long time delays. Major projects that cover a large area and extend over many years need continuing access to good underground data. If this access is not maintained, it adds additional cost and risk to the project.

  3. Disaster planning and response (DP)

    Large scale disasters do not happen very often, but when they do, the failure to anticipate effects on major infrastructure features as well as on other components of the built environment that depend upon that infrastructure, can add billions to costs and result in the displacement, injury and death of large numbers of people. Disasters that are particularly associated with infrastructure failures include power blackouts, floods, tsunamis and storm surges; earthquakes, tornados, hurricanes and other high wind events; high heat events, fuel explosions, and terrorist attacks. A disaster event, at its most disabling, can lead to the failure of major utility generating, storage, control or transmission facilities, cutting off utility resources to large areas. Power failures caused by storm, flood or heat can black out an entire region and cause the shutdown of many critical facilities. A storm surge can flood transit and vehicular tunnels, short circuit electric substations and knock out basement utilities. Interdependencies between infrastructure networks can mean that the failure of one system disables others in a cascading effect. Although not all the damage caused by a disaster event can be anticipated or prevented, any capacity to do so is utterly dependent on the rapid availability of high-quality, interoperable, geospatially enabled data for analyzing vulnerabilities to disaster consequences.

    Interoperable underground utility data that depict large-scale and/or critical transmission, generation, or storage features with their physical and functional interconnections are particularly important. They enable analysis and simulation of the effects of a disaster event, development of protective strategies, and quick reaction to outages and damage. Such data are also important for identifying single points of failure, interdependencies, and triggers for cascading effects. Data about corresponding above-surface features along with underground environment characteristics such as permeability and saturation are also needed to examine the effects of disaster scenarios such as storm surge levels. Major utility features comprise only a small percentage of the overall utility infrastructure, which is dominated by street-level distribution branches; and concerns for their security often mitigate against data standardization and sharing. Nevertheless, without proper integration and analysis of data for both strategic and street-level infrastructure components, jurisdictions will remain hopelessly vulnerable and reactive to disaster events rather than properly prepared.

  4. Utility related emergency response (ER)

    Bringing together utility information for routine excavations may take a significant amount of time, but there is far more urgency when dealing with a potential emergency. Not only must on-scene responders know about all the utility lines they may encounter, and their capacity, before excavation, but they also need to know about the location of utility control features that can rapidly shut off service in the event of a significant break. For example, when a water main leak is strongly suspected, a series of control valves must be located and shut off in sequence to stop the flow since a water supply system is a looped rather than a radial network. Soil and sediment data is also helpful in understanding whether flow and scour from a major water main break may undermine adjacent utility lines and nearby building foundations. Slow or incomplete delivery of this information can lead to a dangerous and costly event. Stories abound of utility workers at the scene of an incident huddling over paper plans on the hood of a truck, trying to figure out what might be happening.

    Complete, accurate and interoperable underground infrastructure data available via wireless communications to the field can enable emergency field responders to rapidly understand the nature of a utility problem and to take informed action. Shut off valves can be quickly located and closed. Digging to expose the damaged pipe or conduit can be commenced immediately with confidence that all other utilities locations in the vicinity are known and can be avoided.

  5. Private and public utility operations, maintenance, repair and replacement programs (OM)

    All utilities have maintenance programs to ensure that their networks are functioning optimally with a minimum of complaints and outages. An important part of such maintenance operations is the replacement of old and obsolete infrastructure elements with new, safer and higher-capacity components. The ability to comprehensively analyze the performance of individual utility features as well as entire networks, on the basis of complete and accurate utility feature information including age, material, capacity and location, is essential for making economically responsible decisions. While installing new gas lines or electric conduit may be expensive, analysis can show it to be less expensive than dealing with major service outages when utility components fail or no longer meet demand.

    Utility maintenance and repair processes depend upon data that relates complaints and problems to specific utility element locations and characteristics. Information about the underground environment, including earth materials and structures, moisture, vibration and the effects of adjacent utility lines, can also help utility analysts understand where segments of their networks are at greatest risk of corrosion, damage and breakage. As the use of utility-monitoring sensors becomes more widespread, additional layers of information and intelligence can be made available to support decision making processes.

  6. Smart Cities, Future Cities (SC) New generations of sensors and smart control valves that can be attached to underground infrastructure components are transforming the way in which infrastructure networks are monitored, and are revolutionizing the way infrastructure product delivery is managed. In turn, these sensors and controls will likely require new supportive power and telecommunications infrastructure, increasing the interdependencies between utilities. Furthermore, innovative technologies coming into use will require new types of utility services such as curb outlets for recharging electric vehicles and navigation infrastructure to guide autonomous vehicles. As underground networks adapt to such new developments, comprehensive knowledge of infrastructure locations and characteristics will be essential for modernization.

    To keep up with the pace of technological transformation it will be necessary for jurisdictions to be prepared for major overhauls of their underground infrastructure environment. There is likely to be increased need to access buried networks and install new services as efficiently as possible. An important step in preparing for these changes will be to fully document the infrastructure that is currently in place, and to evolve standard data models for the new services and devices that are on the way. Losing track of what is underground will be a substantial barrier to realizing the benefits of future city innovations.

5.2. Derived model requirements

The following model requirements are drawn from the foregoing use cases and reference back to them.

Table 2. Use case derived model requirements
ID Requirement Capability Example


Horizontal cross-section of all UGI (Underground Information) entities with high horizontal, medium vertical accuracy

2.5D feature geometries


Detailed 3D UGI geometry

3D feature geometries


Detailed 3D underground environment information

Voxel indexing


Survey, sample, and measurement information

Linked survey measurements


Physical and operational dependency relationships

Topological, structural, functional dependencies


Vulnerabilities - inundation, fire, frost, environmental hazards, terrorism / vandalism

Vulnerability assessments


Simulations and predictions (thencast / nowcast / forecast)

Simulation model parameters


Spatial and functional relationships between all UGI elements

Network topology


Within-network topology and functional relationships above-below ground

Network roles


UGI asset status and lifecycle information for cross-utility planning

Feature-as-asset lifecycle


Instrumentation, property, and feature-of-interest relationships

Related sensor observations and inspections


Sensing data streams

Time-series properties


Contributed observations

Data quality / provenance indicators

6. Candidate Underground Information Models

6.1. Overview

The UICDS contribution from Sisi Zlatanova and Ben Gorte (Delft University of Technology, Netherlands) listed a number of design criteria for UGII models which help explain the diversity of existing models which are presently in development or use.

UGII model design criteria
  1. Different applications and user roles require different information. For example, some stakeholders need the location of the utilities, while others need the details like the type of transported material.

  2. Types of objects and their properties to be represented.

  3. Object naming conventions to be observed.

  4. Complexity of object representation, e.g. 2D point or 3D solid geometry.

  5. Aggregation and generalization of objects and object details. For example, a collector with multiple cables can be modeled by many objects or by one object with a property of number of cables.

  6. Relations represented between distinct networks.

  7. Relations represented to other underground or above-ground features.

  8. Operations and other processing to be performed on the data.

  9. System architecture of implementing systems, e.g. distributed storage or a centralized system.

  10. Visualisation requirements (2D/3D, web, specialized software)

  11. Size, scope, and update frequency of the represented infrastructure area.

  12. Granularity and flexibility of data query and access.

Existing models identified in the UICDS can be divided into those covering generic utility infrastructure, specific utility networks, underground geology / hydrology, land infrastructure, and practices of surveying and measuring underground features.

Significant utility network types
  • Electricity network

  • Oil, Gas & Chemicals network

  • Sewer network

  • Telecommunications network

  • Thermal network

  • Water network

  • Transport network

Common feature attributes
  • Location – e.g., XY coordinate and/or Z-depth

  • Shape – e.g., a rectangle or round pipe

  • Color

  • Diameter – e.g., exterior/interior diameter

  • Material – e.g., rubber, steel, iron, etc.

  • Ownership

  • Date (Installation and Last update)

6.2. Candidate infrastructure models and characteristics

  1. CityGML Utility Network ADE (Application Domain Extension) [CUA] leverages CityGML by representing supply and disposal networks in 3D city models. CityGML is an OGC data model and XML-based format for the storage and exchange of virtual 3D city models. As a CityGML extension, the Utility Network (UN) ADE directly supports 3D topographic, topological and functional modeling of hierarchies; it can thus provide homogenized and integrated views of multi-utility networks together with other CityObjects. It would likely require specialized CityGML software systems, however, to leverage more advanced UN ADE characteristics such as network vs feature graphs or functional network roles.

    6 citygml
    Figure 1. CityGML Utility Network ADE Data Model
  2. INSPIRE Utility Networks [IUN] is one of the 34 INSPIRE spatial data themes. INSPIRE is a European Union initiative to establish an infrastructure for spatial information that is geared to help to make spatial or geographical information more accessible and interoperable for a wide range of purposes supporting sustainable development. The theme Utility and Government Services provides basic information (e.g. the location, basic technical characteristics or involved parties) on a wide range of administrative and social services of public interest.

    Subtheme(INSPIRE, 2013)

    • Utility Networks: Node-link-node structured networks for collection, transmission and distribution, including electricity, oil/gas and chemicals, sewer, thermal, water or (not mandatory) telecommunications networks;

    General service information

    • Feature location;

    • Party involved in the service (Administration or organization on behalf of an administrative mandate);

    • Basic technical characteristics, such as capacity or details on the type of service provided.

    Utilities considered

    • Electricity network,

    • Oil, Gas & Chemicals network,

    • Sewer network,

    • Thermal network,

    • Water network,

    • Telecommunications network (only proposed in the technical guidance, not in legislation).

      6 inspire utilities
      Figure 2. INSPIRE utilities network common types model
  3. IMKL (Information model for cable and pipes) [IMKL] is an INSPIRE-based specification for the exchange of cable and pipe information. As mentioned in UICDS contribution from Sisi Zlatanova and Ben Gorte of Delft University of Technology, Netherlands, IMKL has been developed by the Dutch Cadastre and further refined by Informatie Vlaanderen. It extends the INSPIRE Utility Services model as illustrated in Figure 3.

    6 imkl
    Figure 3. Flanders refinement of IMKL data model

    The UICDS contribution from Jef Daems of Informatie Vlaanderen highlights the adoption of IMKL in the KLIP system which facilitates the sharing of underground information from network operators in the Flanders region of Belgium in order to service excavation requests. The version of IMKL used in KLIP is based on the initial Dutch model and has evolved to meet the practical needs of excavators and the utility sector in Flanders. Essentially IMKL further specializes the specific utility network types defined in the INSPIRE theme model by inheriting additional properties from IMKL types such as Depth or ExtraTopography (Figure 4). This multiple inheritance pattern adding the IMKL Kabelenleiding (CableConduit) properties to the INSPIRE SewerPipe object is shown in Figure 5.

    6 imkl model
    Figure 4. IMKL data model