I. Keywords
The following are keywords to be used by search engines and document catalogues.
ogcdoc, MUDDI, underground
II. Preface
Our dear friend and colleague Geoff Zeiss contributed greatly to the community and to the work which led to the MUDDI model, but sadly passed away before we reached the milestone of publication. The OGC MUDDI Standards Working Group wishes to recognise and commemorate Geoff’s contribution to this work.
III. Security considerations
No security considerations have been made for this document.
IV. Submitting Organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
- Ordance Survey
- GISMO
- BGS
V. Contributors
Contributors to this document include:
Alan Leidner, New York City Geospatial Information System and Mapping Organization (GISMO)
Neil Brammall, Geospatial Commission, UK Government
Liesbeth Rombouts, Athumi
H.C. Gruler, Leica Geosystems/Hexagon
Carsten Roensdorf, Ordnance Survey
1. Summary
Data about sub-surface infrastructure is very relevant for the safe and efficient operation of our towns and cities, yet often difficult to access and therefore invisible. This guide explains how underground data can be structured so it can be easily accessed and understood not only by the producer of this data, but by all relevant parties in the Urban Environment including community members who want to understand what goes on beneath their neighborhoods.
MUDDI, the Model for Underground Data Definition and Integration is published by the Open Geospatial Consortium, an industry forum and standardization organization. We believe in making data Findable, Accessible, Interoperable and Re-usable. The MUDDI Conceptual Model is an open international standard and defines a data structure or data model for sub-surface information. It is free to use by everyone and empowers communities who want to benefit from better managing their hidden underground infrastructure.
This guide describes what a data model is, how it is applied and what benefits can be expected.
2. The Basics of A Data Model — Your Family Tree
The best way of approaching an understanding of data models for underground infrastructure is to examine an instance of organized data that everyone is familiar with: The Family Tree contains many of the elements we find in data models whose purpose is to identify and organize objects and processes in the physical world. The key features of a family tree are the names of relatives arranged by links within and across generations including the connections between parents, children, aunts, uncles, cousins, nephews and nieces. It can also detail other characteristics (or attributes) such as dates of birth and death, and may additionally show where family members came from. If all this information were not arranged in a tree-like format, but instead was put into a long listing, it would be very difficult to understand all the different family branches and their relationships to each other.
The key thing is that, like a Family Tree, a Data Model represents concepts, objects and relationships that exist in the real world. Examples might include representations of things like planning zones and streets or buildings, and how these concepts and objects relate to each other — spatially or otherwise. In this way, when data is structured in a way that is defined by that Data Model, we can be more confident that data more accurately describes the real world features it is meant to represent.
If the family trees of several families are drawn in the same way, we can more easily work with data from different sources, compare and perhaps integrate them into an overarching tree covering different branches of a family.
Figure 1 — A family tree © Sketched Images/Shutterstock.com
3. Why Data Models Are Important
Just as a Family Tree organizes members of an extended family in a standardized way so that they are more easily understood, a data model organizes information pertaining to the real world in a way that makes it more easily grasped, enabling the information to be incorporated into computer applications that allow the data to be collected, stored, updated, expanded, combined, visualized and analyzed in useful ways. When a data model pertaining to parts of the real world (domains) are “standardized” and used in the same form across a jurisdiction, state, or nation it then becomes possible to easily combine the data across borders for larger scale and more economical operational and analytic tasks. Data stored in these systems becomes interoperable and creates additional value for the community.
Data models exist for buildings, roadway systems, manufacturing processes, medical services, logistics, and are used for many other purposes, all of which can be described by a logical assembly of features and their characteristics (attributes) to be organized in hierarchies and by function.
4. A Data Model for Underground Infrastructure
Starting in 2017, the Open Geospatial Consortium identified underground utilities and other underground features as a domain (subject area) where existing data was largely disorganized, unknown, or held in many different formats, that it was impossible to make sense about what was there.
This situation is exemplified by the mapping response to the attack on the World Trade Center (WTC) on September 11, 2001. It took responders more than ten days to collect and piece together utility, structural, and geological information for the acres of collapsed area beneath the World Trade Center to support rescue and recovery operations.
Of course, the biggest obstacle to assembling underground data is that almost all features are buried and therefore invisible: we really don’t know where they really are after they are installed and covered up, and this creates a myriad of problems. Below you will find an image of a road network in the Inwood neighborhood of Manhattan which pictures a variety of roadway types including: highways, main avenues, two-way streets, one-way side streets, and walkways. There will be a significant amount of underground infrastructure in the areas shown on the map–it is just not included in the data model of this map and is therefore invisible.