Available via license: CC BY 4.0
Content may be subject to copyright.
ROADMAP FOR INTEROPERABLE 3D DATA MODELS IN OGC APIS AND OTHER
DATA EXCHANGE APPROACHES
R. A. Atkinson1,2,,∗A. Hunter4, N. J. Car1,3, M. B. J. Purss5, B. Cochrane6
1 SURROUND Australia Pty Ltd., New Acton, ACT 2601 Australia - (rob.atkinson, nicholas.car)@surroundaustralia.com
2 Open Geospatial Consortium Europe, Technologielaan 3, 3001 Leuven Belgium
3 Australian National University, New Acton, ACT 2601 Australia
4 SURROUND Consortium, PO Box 204276 Auckland 2161 New Zealand
5 Pangaea Innovations Pty. Ltd., Spence, ACT 2615 Australia
6 OpenWork Ltd. 243 Trafalgar Street, Nelson 7010 New Zealand
Commission IV, WG IV/9
KEY WORDS: Smart Data, 3D Data, Topology, 3D Data Integration, Information Fusion, 3D Standards, CityGML, IFC, 3D
Cadastre
ABSTRACT:
Many data exchange standards for 3D spatial data applications exist, ranging from the general Geography Markup Language (GML)
underpinning CityGML to specific models for business application domains, such as BuildingSMART Industry Foundation Classes
(BIM/IFC). There are a number of different approaches to modelling 3D objects, and in general the geometry aspects of these can
be readily understood in the context of the visualisation needs of different applications. The topology, or relationships between
elements of these objects, on the other hand is either not directly supported by such geometry models or implemented in different
ways by different standards. We discuss limitations of existing standards for describing topological relationships in particular. In
some cases topology information is embedded in geometry objects using identifiers for vertices, edges and faces, but in general
there is scope to develop a standardised model for describing alternatives for topology and 3D geometry representations. A limited
set of such models allows for interoperability via transformations between different representations. The ISO 19107 Spatial Schema
provides an adequate conceptual model for these concerns, so we present the argument that a profile of this comprehensive model
be defined for the limited set of such representation options required for Smart Cities and other similar applications.
1. INTRODUCTION
Interoperability of typical 2D GIS data has been supported
through a range of data exchange standards, usually explicitly
underpinned by the conceptual framework of the ISO 19107 -
Spatial Schema standard (ISO, 2019b). Whilst this model is
a comprehensive model for multi-dimensional geometry and
topology it is rarely, if ever, implemented in full, and many
different possible partial representations for 3D geometry and
topology are possible. Geography Markup Language (GML)
(OGC, 2007, ISO, 2020) is a powerful XML encoding standard
used for ISO 19107 data which can encode most of it, how-
ever, in practice, applications and software rarely support the
full range of its possibilities and XML is increasingly being re-
placed or supplemented by JSON, YAML and ”cloud native”
binary formats.
For typical 2D spatial applications, the Simple Features Access
(SFA) (ISO, 2004) profile of ISO 19107 has been created which
restricts geometries to “simple features, such as points, lines,
and polygons”, and is designed to “lower the implementation
bar of time and resources required for an organization to com-
mit for developing software that supports GML”. This profile
is supported by nearly all spatial software, though the extent to
which some underlying mechanisms, such as the use of refer-
ences to reusable geometry elements using XML’s xlink (W3C,
2001) and the orientation of geometry elements is implemen-
∗Corresponding author
ted, varies. Software libraries such as GDAL1and Val3dity
(Ledoux, 2018) represent a means for applications to cope
with these complexities. SFA geometries may use 3D points,
but SFA doesn’t provide explicit support for solid geometries,
shells, nor 3D topology.
Recent trends toward use of JSON (IETF, 2017) as an encoding
technology have seen SFA implemented in GeoJSON (Butler et
al., 2016), which is content to merely specify “Points Lines and
Polygons” without formally referencing an underlying defini-
tion for them. The OGC FG-JSON (OGC, 2021) is looking at
extended or complementary schemas to support a wider range
of capabilities, such as choice of spatial reference system and
solid geometries.
We propose a 3D spatial data profile of ISO 19107 (ISO, 2019b)
and the specification of functions for 3D data operations. These
functions can be implemented in software packages and valid-
ated using a test suite. Implementations can be tested against
multiple options for encoding, such as JSON & XML. Geo-
SPARQL (Car et al., 2021) in particular provides the opportun-
ity for the use of JSON-LD (Kellogg et al., 2020) as a bridge
between the many emerging JSON schemas and validatable ca-
nonical forms with transparent semantics.
1“a translator library for raster and vector geospatial data formats”:
https://gdal.org/
The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLVIII-4/W4-2022
17th 3D GeoInfo Conference, 19–21 October 2022, Sydney, Australia
This contribution has been peer-reviewed.
https://doi.org/10.5194/isprs-archives-XLVIII-4-W4-2022-13-2022 | © Author(s) 2022. CC BY 4.0 License.
13
2. METHODOLOGY
An application domain requiring 3D data exchange standard-
isation, in this case cadastral parcel definition and survey data
exchange, was analysed to identify informational content re-
quirements. These requirements were then compared to various
3D data and exchange models to quantify potential for software
support as a key enabler for uptake of any data exchange model.
3D cadastral data includes range of 3D geometries typically
found in many 3D spatial domains. Curves (boundary edges)
and surfaces (boundary faces) may be planar or parametric,
solids (cadastral parcels, easements, etc.) may contain voids
where specific property rights are excluded. Survey observa-
tions and cadastral parcel boundaries may be described by vec-
tors, or by reference to other spatial objects. Cadastral parcels
may also be unlimited in the Z axis. As such, we consider 3D
cadastral data geometries and their topological requirements to
be representative of a broad range of object-oriented (Worboys,
1995) 3D application domains.
Scenarios were encoded in various candidate spatial data encod-
ing technologies to determine the potential overhead involved
and then compared to existing software capabilities. These can-
didates were drawn from standardisation bodies such as the
Open Geospatial Consortium (OGC)2, buildingSMART3, the
World Wide Web Consortium (W3C)4, IETF5and included
both general purpose models (GML (ISO, 2020), GeoJSON6,
GeoSPARQL (Perry and Herring, 2012), etc.) and application
domain specific models such as CityGML (Kolbe et al., 2021),
IFC7, etc.
2.1 Review of existing approaches
From a standards and interoperability perspective specification
of a 3D data model must be designed to be encoding agnostic
- and conceivably may be implemented in whole or part with
a range of different encoding technologies. Ideally, the con-
ceptual model would be modular with the canonical logical
model based on patterns favouring well-known encoding stand-
ards that can be reused. For this work, key patterns expected
to influence encoding choices include 3D Solid Geometry and
Topology of 3D Solids.
A topology pattern, particularly for cadastral data, is expected
to strongly influence encoding choices for 3D solids, as cadas-
tral parcels are often required to form a continuous partition of
a jurisdictions territory to define exclusive property rights. A
frequent requirement of cadastral systems is that there should
be no gaps nor overlaps between uniquely owned cadastral par-
cels; that observation vectors do connect to survey marks found
in the field (survey vectors, observations and boundaries, must
stop and start at survey points), etc. Additionally, partial rights
to property such as easements should be located within one or
more cadastral parcels. These relationships are required to en-
sure data consistency and limit confusion with respect to prop-
erty rights. More specifically, solid geometry requires an as-
sessment of topology to ensure closure (Stroud, 2006).
Within the geospatial information space topology is recog-
nised as being important particularly for analytical applications
(Theobald, 2001). ISO 19107 (ISO, 2019b) and application
2https://www.ogc.org
3https://www.buildingsmart.org
4https://www.w3.org/
5https://www.ietf.org
6https://geojson.org/
7https://technical.buildingsmart.org/standards/ifc/
schema adopting the standard assume a topological primitive
approach where objects are deconstructed into their primitive
components (nodes, edges, faces,...). Objects are then defined
topologically by their bounding primitives (their outer surface).
Topological relationships between objects can then be iden-
tified by searching for primitives that are shared by the ob-
jects (Zlatanova et al., 2004, Zlatanova, 2017). Topology also
enables topological primitives boundary,interior and exter-
ior (Egenhofer and Herring, 1990) for describing relationships
between spatial objects. This approach has been adopted by the
OGC as a basic implementation framework (OGC, 2011).
There are many reasons why a standard encoding of the con-
cepts required to implement a 3D cadastre is not available.
Complex and comprehensive standards such as ISO 19107
(ISO, 2019b) may support faithful abstract representations of
the underlying theory but are not easy to implement as data ex-
change standards. Standardised encoding approaches, where
available, may also be challenging to use due to the complexity
and scope of the standard. It is relatively easy to implement
an ad-hoc solution for a narrow application scope, however,
these will not be readily interoperable with each other. Many
software systems also pre-date suitable encoding standards and
may therefore require significant effort to incorporate current
standards.
Considering the requirements for topology representation
needed for cadastral surveys led us to focus on GIS feature-
centric encodings and exclude CAD formats such as DXF
and DWG that are object and project centric. However, BIM
formats, particularly IFC, can play important roles in sharing
3D cadastre datasets. Existing and potential encoding stand-
ards for exchange were reviewed to determine the current state
of play. We note that most of the current software used by Ca-
dastral Surveyors fit more naturally in the BIM and CAD world
than GIS. However, most land records offices store the cadastral
fabric in GIS formats.
2.2 Geometry encodings
Various geometry encodings including Geography Markup
Language (GML) (ISO, 2020), Well-known Text (WKT) (ISO,
2016b), GeoSPARQL (Perry and Herring, 2012), FG-JSON8
and Discrete Global Grid Systems9(DGGS) were assessed to
determine their ability to describe 3D geometries and topolo-
gical relationsips. These encodings are frequently adopted for
the transport of spatial information.
At a recent OGC workshop focusing on encoding issues and
opportunities for LADM (ISO, 2012) data the top five data en-
codings (most common to least) were DXF (geometry only),
GML (ISO, 2020), GeoJSON6, CityGML(Kolbe et al., 2021)
and LandXML12.
GML is an XML grammar expressing geographical features
defined in ISO 19107 (ISO, 2019b). GML serves as a model-
ling language for geographic systems and an open interchange
format for geographic transactions on the Internet. Best prac-
tice when developing GML encodings (e.g., CityGML(Kolbe
et al., 2021), InfraGML (Scarponcini et al., 2016)) is to create
an XML schema (XSD) using the GML schema derived from a
UML model based on ISO 19107 (ISO, 2019b). GML covers
both geometries and tolopogy. Implementing a ”model driven
architecture” (MDA) approach to generating GML is well es-
tablished within the OGC. It does however require consider-
8https://www.ogc.org/projects/groups/featgeojsonswg
9https://docs.ogc.org/as/20-040r3/20- 040r3.html
The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLVIII-4/W4-2022
17th 3D GeoInfo Conference, 19–21 October 2022, Sydney, Australia
This contribution has been peer-reviewed.
https://doi.org/10.5194/isprs-archives-XLVIII-4-W4-2022-13-2022 | © Author(s) 2022. CC BY 4.0 License.
14
able expertise and tooling support. Regardless of its complex-
ity, GML has been broadly adopted by technology partners,
with the caveat that developers have found numerous alternative
ways to implement feature geometries resulting in interoperab-
ility difficulties. For example, software application A may use
a point list to define the exterior of a polygon, whereas software
application B requires a LinearRing.
WKT (ISO, 2016b) is a text markup language representing
vector geometry objects. WKT overlaps and extends the ISO
SFA standard (ISO, 2004). A binary equivalent, Well-Known
Binary (WKB), transfers and stores the same information in a
more compact form convenient for computer processing but is
not human-readable. The formats were initially defined by the
OGC and described in their Simple Feature Access.
GeoSPARQL (Perry and Herring, 2012) is an OGC standard
that defines a vocabulary for representing geospatial data in
RDF and describes an extension to the SPARQL10 query lan-
guage for processing geospatial data. It incorporates a topolo-
gical ontology in RDFS/OWL for representation of GML and
WKT geometries, and includes RCC8 (Randell et al., 1992) for
spatial reasoning and DE-9IM (Clementini et al., 1993) for as-
sessment of topological relations.
New to the domain of geometry encodings is the OGC Features
and Geometries JSON Standards Working Group8(JSON-FG
SWG). The JSON-FG SWG is building upon the GeoJSON6
standard to extend essential concepts to the broader geospatial
community and the OGC API standard11. Initial features in-
clude access to a broader range of Coordinate Reference Sys-
tems (CRSs), support for ellipsoidal metrics, 3D geometries,
and provision of guidance on the representation of feature prop-
erties in JSON that are consistent with the General Feature
Model (ISO, 2015).
2.3 Application schema encodings
A range of application encodings have been developed
for consumption by software applications. Encodings re-
viewed included Industry Foundation Classes (IFC) (ISO,
2018), LandXML12 (including regional adaptations ePlan13
and LandonLine14), IETF GeoJSON 15, LADM (ISO, 2012),
CityGML (Kolbe et al., 2021), InfraGML (Scarponcini et al.,
2016), TopoJSON16, CityJSON17, and GeoPackage18.
LandXML12 is a specialised XML application encoding used
to describe property boundaries, infrastructure features such as
roads and underground services, and survey and engineering
surveying measurements. The encoding is commonly used in
the surveying, land development, and transportation industries.
Originally developed to enable data transfer and archiving of
data, it is now a standard industry encoding built into many
common CAD software packages including 12D, CivilCAD,
AutoCAD and Trimble Business Centre. Regarding previous
works, we note that various parties have investigated the pro-
spect of basing a 3D cadastre on LandXML based encodings.
However, the use of LandXML for 3D is hindered because sup-
port for 3D Solid Geometry and Topology is limited. While
10 https://www.w3.org/TR/sparql11-query/
11 https://ogcapi.ogc.org/
12 http://landxml.org
13 https://www.icsm.gov.au/publications/eplan-model- v10
14 https://www.linz.govt.nz/land/landonline
15 https://datatracker.ietf.org/doc/html/rfc7946
16 https://github.com/topojson/topojson
17 https://www.cityjson.org
18 https://www.ogc.org/standards/geopackage
Z coordinate values are supported, Solids are not, nor is topo-
logy. The proliferation of incompatible profiles of LandXML
reflect the challenges of emergence of technical standards via
non-formal governance processes. LandXML also lacks a con-
ceptual model which was why OGC decided to progress Land-
Infra rather than adopt LandXML as an OGC endorsed com-
munity standard.
Industry Foundation Classes (IFC) (ISO, 2018) is a standard
developed for Building Information Model (BIM) data that are
a standardised, digital description of the built asset industry.
Typically these are implemented using STEP encoding (ISO,
2016a). IFC (ISO, 2018) is an open standard, intended to be
vendor-neutral / agnostic, and usable across a wide range of
hardware devices, software platforms, and interfaces for many
different use cases. IFC geometries and topologies are sim-
ilar to those defined in ISO 19107 (ISO, 2019b) insofar as ISO
10303-42 (ISO, 2019a) allows for both boundary representa-
tions of solids and general sweeping using 2D shapes extruded
along curves. ISO 10303-42 (ISO, 2019a) also includes a to-
pological schema that has its basis in boundary representation
solid modelling. While not specifically designed for cadastral
use cases, IFC does include a number of appropriate classes to
describe both cadastral parcels and building occupations. In
addition, IFC can provide a useful transfer encoding for 3D
geometries that can integrate with existing BIM software used
in the Architectural, Engineering and Construction (AEC) in-
dustry.
GeoJSON6encodes data about geographic features using
JavaScript Object Notation (JSON)19. GeoJSON provides a
means of representing both the properties and spatial extent of
features. The central focus of GeoJSON is to simply share
spatial data for display in web maps. Much of GeoJSON’s
popularity derives from its simplicity, making it easy to im-
plement, read, and share. However, it has limits. GeoJSON
has no support for 3D geometries, only SFA geometry types.
GeoJSON has no construct for topology although TopoJSON16
can be used to extend GeoJSON to include topology constructs.
GeoJSON features have properties encoded using JSON. Prop-
erties can use any JSON datatype: numbers, strings, booleans,
null, arrays, and objects. However, JSON doesn’t support every
data type commonly used with spatial data: for instance, date
values. GeoJSON doesn’t support curves. If you have a LineS-
tring representation of a route that you have run, and your GPS
watch logged 1,000 different points along that route, including
your heart rate, timestamp,etc., there’s no clear answer for how
to represent that data using GeoJSON. SFA, which directly in-
spired GeoJSON and most GIS formats, doesn’t support linear
referenced locations20. GeoJSON currently supports a single
coordinate reference system, WGS84, except by prior arrange-
ment (with the end user), making it difficult to share data in
other coordinates systems.
ISO 19152:2012 Land Administration Domain Model (LADM)
(ISO, 2012), originally an initiative of FIG21, is a conceptual
model that defines an ontology for land administration. LADM
has been implemented in many countries, at least 40 (Kalogi-
anni et al., 2021). LADM depends on ISO 19107 (ISO, 2019b)
for geometries such as point, curve (line), surface (area), and
solid (volume) and topology when required. The main dif-
19 https://www.ecma-international.org/
publications-and- standards/standards/ecma-404/
20 Note that GML 3.3 adopts ISO 19148:2021 Geographic information —
Linear referencing.
21 https://www.fig.net/
The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLVIII-4/W4-2022
17th 3D GeoInfo Conference, 19–21 October 2022, Sydney, Australia
This contribution has been peer-reviewed.
https://doi.org/10.5194/isprs-archives-XLVIII-4-W4-2022-13-2022 | © Author(s) 2022. CC BY 4.0 License.
15
ference is the terminology that is customary to each applica-
tion domain is adopted and the grouping of geometries to form
more complex features. LADM also includes spatial unit exten-
sions for LocationByText, non-2-manifold and/or unbounded
volumes (conventional 2D parcels unbounded in the Z direc-
tion). LocationByText allows a spatial unit to be described by a
text string, e.g., ”that part of Lot 2 south of river”, or, ”the west-
ern 20 m of Lot 5”. LADM v2 is currently under development
(Lemmen et al., 2020).
The CityGML (Kolbe et al., 2021) standard utilises GML en-
coding to define a conceptual model and exchange format for
the representation, storage and exchange of virtual 3D city
models. It facilitates the integration of urban geodata for a
variety of applications including Smart Cities and Urban Di-
gital Twins; urban and landscape planning; Building Inform-
ation Modeling (BIM); mobile telecommunication; disaster
management; tourism; vehicle and pedestrian navigation; etc.
CityGML 3.0 standardized the underlying information model,
and aligned it with ISO so that it can be implemented in a range
of technologies. It allows data to be encoded in GML/XML and
JSON, or database schemas. Geometries of all CityGML fea-
ture types are represented using the geometry classes defined in
ISO 19107 (ISO, 2019b). In addition to primitive geometries
(points, curves, surfaces, and solids), CityGML makes use of
both geometry aggregates (MultiPoint, MultiCurve, MultiSur-
face, MultiSolid) and composites (CompositeCurve, Compos-
iteSurface, CompositeSolid). The CityGML Conceptual Model
does not employ the topology classes from ISO 19107. To-
pological relations between geometries can be established by
sharing geometries (typically parts of the boundary) between
different geometric objects via the use of XML’s xlink (W3C,
2001), hence traversing the topology graph is not bi-directional.
InfraGML (Scarponcini et al., 2016) is an OGC standard with
an XML encoding of the OGC Land and Infrastructure Concep-
tual Model Standard (LandInfra). InfraGML adopts GML 3.3
(ISO, 2020) for geometries and topology. The InfraGML en-
coding is an implementation-dependent GML encoding of con-
cepts supporting land and civil engineering infrastructure facil-
ities. It is a multi-part standard.
TopoJSON16 is an extension of GeoJSON that encodes topo-
logy. Rather than representing geometries discretely, geomet-
ries are stitched together from shared edges. This approach
eliminates redundancy, allowing related geometries to be stored
efficiently in the same file. However, as with GeoJSON, 3D
geometries are not supported and coordinate reference systems
are limited to WGS84, except by prior arrangement.
CityJSON17 is a new standard that encodes a subset of version
3.0.0 of OGC’s CityGML conceptual data model (Kolbe et al.,
2021). All standard geometries required for solid modelling
using boundary representation are included. As is the ability
to specify a coordinate reference system, although CityJSON
only allows one as opposed to CityGML which allows many in
a single dataset. Topological relationships are not supported,
nor is there an equivalent to XML’s xlink (W3C, 2001). There-
fore, geometries common to multiple objects must be duplic-
ated. The few CityGML features not currently supported are
either because they are seldom used or would over-complicate
the JSON encoding. Despite this, bidirectional conversion
between CityJSON and CityGML is possible. Like CityGML,
CityJSON provides storage of 3D city models built on JSON
rather than XML. Limitations inherent in CityJSON are similar
to those of JSON and CityGML—a lack of topology and linked
data support.
OGC’s GeoPackage18 data encoding provides an SQLite data-
base implementation of the OGC SF SQL specification (ISO,
2004). GeoPackage is an open, standards-based, platform-
independent, portable, self-describing, compact format for
transferring geospatial information. A GeoPackage, in essence,
is an SQLite container using OGC encoding standards for stor-
ing vector features, tile matrix (raster data), non-spatial attrib-
ute data, etc. Because GeoPackages are a database implement-
ation and can be normalised basic topology is able to be in-
cluded. Currently, 3D support is limited. 3D extensions may
emerge but are not yet visible at https://www.geopackage.
org/extensions.html.
2.4 3D solid geometry
Without the capacity to describe cadastral information as solids,
the ability to submit 3D cadastral information is limited as it is
difficult to test whether the solids are watertight (closed), or
validate spatial relationships between cadastral parcels. 2D ca-
dastre parcels (polygon) only require definition in two direc-
tions, East (X) and North (Y). Whereas in the 3D space, spatial
units (solid) defining the extent of a cadastral parcel requires
definition in all directions, X, Y and height (Z). Within the com-
puter modelling domain, the main representations used for the
description of solids, spatial units constrained in all directions,
include (Stroud, 2006):
•Cell decomposition - division of space, or a cadastral fea-
ture, into a set of elements, typically voxels;
•General sweeping - the representation of objects in terms
of 2D shapes extruded along general curves, i.e., con-
structive solid geometry (CSG);
•Set theoretic - a set of primitive shapes or (parametric) sur-
faces (more correctly half planes) that when combined us-
ing Boolean operators form a solid; and
•Boundary Representation - a collection of surface ele-
ments that form the skin of a solid.
ISO 19107:2019 (ISO, 2019b) adopted the Boundary Repres-
entation (B-Rep) to describe 3D geometries. The skin is com-
posed of a set of adjacent bounded elements called faces; ca-
dastral boundary faces in this context, which define the object’s
shell. Faces are bounded by a set of edges, or boundary lines,
which are curves lying on the surfaces of the faces intersecting
the edges. The points where several faces meet are called ver-
tices and, from the perspective of cadastral surveying, represent
survey points generally. The data structure can be divided into
two primary groups: one responsible for defining the object’s
structure (the topology) and the form or shape of the object (the
geometry).
2.5 Topology of 3D solids
From a cadastral system perspective, topology provides two
main functions. First is validating the data according to spe-
cific rules, e.g., no overlaps or gaps between primary parcels22.
Second is the ability to identify and manage shared boundaries
and other geometric relationships, e.g., in New Zealand, a Unit
Title represents a stratum estate that lies within the base land
(subdivided parcel) and is disjoint from the Common Property
held by the Body Corporate. Satisfaction of this second require-
ment assists the implementation of the first because topological
models allow geometries to be captured once and referenced
many times, significantly reducing data volumes and enhancing
22 A parcel that may not overlap with other parcels of the same type - they
represent exclusive rights.
The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLVIII-4/W4-2022
17th 3D GeoInfo Conference, 19–21 October 2022, Sydney, Australia
This contribution has been peer-reviewed.
https://doi.org/10.5194/isprs-archives-XLVIII-4-W4-2022-13-2022 | © Author(s) 2022. CC BY 4.0 License.
16
data set integrity. Adopting the principles of topology also en-
ables rapid spatial data retrieval, enhanced spatial analysis (El-
lul and Haklay, 2006), and enforcement of data integrity rules
(Theobald, 2001, Burrough et al., 2015).
Delegation of the enforcement of some topological rules to the
application domain may be necessary. Indeed, it is possible, and
even common, to delegate all topological concerns to the ap-
plication. However, embedding topology in the data increases
the interoperability of the data by reducing the reliance on par-
ticular software components, and also preserves the benefits of
data set integrity and reduced file size. Pre-calculation of topo-
logical relationships is more efficient, as the relationships are
identified once during data creation (typically by domain ex-
perts) and then are able to be queried many times (Ellul and
Haklay, 2006).
It is long understood that topological relationships are the
foundation of spatial reasoning (Dube, 2017). The theory of 2D
topological relations has been well studied with Egenhofer and
Herring’s (Egenhofer and Herring, 1990) 9-intersection model
(9IM) and its extension DE-9IM (Clementini et al., 1993) im-
plemented in various software applications. However, neither
9IM or DE-9IM are able to resolve all topological relations
between two simple geometries in 3D space.
As noted, topological relations between geometries can be es-
tablished by sharing geometries (typically parts of the bound-
ary) between different geometric objects. For example, the face
between two adjacent 3D cadastral parcels should only be rep-
resented by a single geometry (a face) and referenced by all
features or more complex geometries defined or bounded by the
face. Thus, redundancy can be avoided, and explicit topological
relations between parts maintained.
Ideally, the topological graph should be bidirectional, i.e., cap-
able of being navigated up and down the graph. It is common
to construct higher dimension geometries from sets of lower
geometries, a boundary line is defined by a set of two or more
survey points. Construction of geometries in this manner impli-
citly informs the topology of a spatial unit. However, topology
in this sense only allows one-way navigation of the topology
graph. Therefore, functions may be required to generate the ne-
cessary topology to address specific spatial queries, i.e., which
survey points define the solid(s) describing this/these cadastral
parcel(s).
This approach reflects the general approach taken by cadas-
tral surveyors when defining cadastral parcel boundaries. Ori-
ginal, reliable monumentation (survey points) defines a cadas-
tral boundary’s location. A closed set of cadastral boundary
lines defines the cadastral parcel, or a cadastral parcel face in
the 3D space.
3D spatial objects may consist of points or vertices, Lines being
an edge defined by two vertices, Faces described by a closed
set of three or more lines, and Solids consisting of a closed
set of four or more faces. Given these spatial objects, the 9IM
model has been extended to a 25 Intersection Model (25IM) by
subdividing a boundary into face, edge and vertex components
(Zhou and Guan, 2019). Hence the five topological compon-
ents are the exterior (3D), interior (3D), face (2D), edge (1D),
and vertex (0D). This results in ten groups of topological re-
lations, solid/solid, solid/face, solid line, solid/point, face/face,
face/line, face/point, line/line, line/point and point/point. 25IM
adopts the same spatial relationships as 9IM, being disjoint,
contain, equal, meet, cover, and overlap. While 9IM has 512
(29) possible relations to account for 25IM has 33.5M in theory
(225). However, in the real world these reduce to 2,651 topo-
logical relations (Zhou and Guan, 2019). This is still a large
number that will take some computational effort to assess, par-
ticularly if data sets are large.
The following figures (1and 2) depict two possible relation-
ships, Solid/Solid Overlap and Cover.
Figure 1. Solid/Solid Overlap: a) A’s edges are disjoint from B’s
and a vertex of B is covered by A; b) A and B have faces that
touch and a vertex of B is covered by A ; c) A and B have faces
that touch and B has a face covered by A.
Figure 2. Solid/Solid cover at face: B is covered by A and a) has
a common vertex and edges; b) has a common edge; c) and has a
common face.
An ideal representation keeps geometry and topology separate,
allowing greater flexibility but at the risk of ambiguity when
created with conflicting information. This approach is imple-
mented in GML (OGC, 2007) where the <gml:Solid> element
describes the geometry, and the <gml:topoSolid> element de-
scribes the topology.
<gml:Solid gml:id="s1">
<gml:name>Blue box above ground</gml:name>
<gml:exterior>
<gml:Shell>
...
</gml:Shell>
</gml:exterior>
</gml:Solid>
<gml:topoSolid gml:id="ts1">
...
</gml:topoSolid>
</gml:solidMember>
When a cadastral spatial units geometric representation is im-
plemented using a strict B-Rep approach, then in instances
where two or more spatial units intersect, e.g., an easement
passing through a cadastral parcel, each spatial unit is split into
discrete solids at parcel boundaries. The cadastral parcel would
be split into the portion of the cadastral parcel outside the ease-
ment, volume Ain Figure 3, and the portion inside the ease-
ment, volume Bin Figure 3. The easement would also be split
at the cadastral parcel boundaries, volumes Band Cin Figure
The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLVIII-4/W4-2022
17th 3D GeoInfo Conference, 19–21 October 2022, Sydney, Australia
This contribution has been peer-reviewed.
https://doi.org/10.5194/isprs-archives-XLVIII-4-W4-2022-13-2022 | © Author(s) 2022. CC BY 4.0 License.
17
3. These would then be aggregated to form each specific spatial
unit. The easement portion inside the cadastral parcel, com-
mon to the cadastral parcel and the easement, is only created
once but referenced in the definition of each spatial unit. All
intersections between the cadastral unit and the easement are
explicitly defined in this approach.
Figure 3. 3D geometry depicting two overlapping geometries
A simplified approach might model the cadastral parcel and
the easement independently of each other. There is no expli-
cit definition of the relationship between the two spatial units
in this instance. If such an approach is adopted, from a cadas-
tral surveying perspective, it is recommended that an intersec-
tion curve, similar to CityGML’s terrain intersection curve, be
defined to describe explicitly where the two solids meet.
3. RESULTS
Analysis of requirements identified that the topology of features
in 3D was not easily addressed with pure geometry elements. A
case in point is where a boundary between adjacent 3D objects
may have a complex geometry and require explicit information
pertaining to its state - such as its area, or its “occupation”. In
other words: observations about real world phenomena are loc-
ated on or near such a boundary.
In a 2D world it is not particularly challenging to either duplic-
ate sections of geometry for shared boundaries or to calculate
the shared boundary extents as required. In 3D this is made sig-
nificantly more complex for multiple reasons, including com-
putational overhead but also the potential for different forms
of representations including “extruded geometries”, triangular
irregular networks (TINs) and other polyhedral surfaces, etc.
Simply put: the number of combinations of geometry type and
element re-use by reference in a 3D world is much greater than
for 2D and the complexity of operations is higher, so the support
of convenient software libraries is vital. The challenge is that
many required elements, such as extrusion parameters, the re-
lationships between features and boundaries and even topology
and re-use of geometry elements, are not standardised. Making
software work for the many possible ad hoc solutions that lack
of standardisation leads to is not feasible.
It was ascertained that many of the available encoding options
simply provided no support for encoding of 3D geometries and
topology, and the most powerful candidate, GML, was com-
plex and verbose. The current state of implementations of ISO
19107 across a range of different profiles and encoding options
illustrates the gap between advanced 3D support in ISO 19107
and existing encodings.
Examining the various encodings of the spatial standards has
lead to the conclusion that the implementations tend to adopt
subsets of more general conceptual models. They are some-
times identified explicitly as profiles and sometimes implicitly
via commentary in documents. Our experience has also shown
that the existing encodings provide poor support for the man-
agement of 3D information.
We note that OGCs SWG for FG-JSON (OGC, 2021) is ex-
pecting to extend GeoJSON to support 3D geometries through
polyhedron geometry objects or other encodings (base surface
plus height, support for circles, more compact coordinate en-
codings). Of particular interest is the the GeoSPARQL spe-
cification which defines a semantic model for feature and geo-
metry expressed in RDF23. GeoSPARQL defines not only data
elements (properties) for relationships based on topological and
spatial relationships, but also functions that can be invoked to
calculate these. It allows use of a number of geometry encod-
ings, as of GeoSPARQL 1.1, WKT, GML, KML, GeoJSON and
DGGS.
GeoSPARQL is currently under active development and 1.1 is
close to finalised. GeoSPARL 1.2 is planned following 1.1 re-
lease and the scoping for that version is underway with a num-
ber of proposed extensions, including 3D geometries described
here, see the GeoSPARQL Standards Working Group’s Issue
Tracker24.
4. DISCUSSION
In the same way that SFA forms the basis of most 2D geospatial
data software libraries, a 3D profile of ISO 19107 (ISO, 2019b)
could be used to provide a convenient scope for key capabilities
needed for a wide range of 3D applications, crucially for inter-
operability & transformations between geometry and topology
representations, which is critical for robust validation strategies.
Given the current state of implementations of ISO 19107 (ISO,
2019b) across a range of different profiles and encodings illus-
trates the gap between advanced 3D support in ISO 19107 (ISO,
2019b) and existing encodings. We recommend development of
a 3D spatial data profile of ISO 19107 (ISO, 2019b) similar in
nature to GDAL. To minimise long-term risks it is proposed
to develop an implementation strategy predicated on alignment
with wider community trends towards JSON (developers) and
IFC (Digital Twins), emerging developments coming out of the
OGC SWGs driving FG-JSON and OGC APIS, and develop-
ment of GeoSPARQL 1.2.
Figure 4illustrates the potential for providing 3D support in
both geometry and topological relationships between features,
anchored by GeoSPARQL (Perry and Herring, 2012) as a func-
tional standard that allows for multiple geometry encodings.
The specification of cadastral survey data using a 3D profile
of ISO 19107 provides an opportunity to test a mechanism to
take advantage of additional ISO and OGC standards for both
23 Resource Description Framework: https://www.w3.org/RDF/
24 GeoSPARQL Standards Working group correspondence is pub-
lic: https://github.com/opengeospatial/ogc-geosparql/
projects/4
The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLVIII-4/W4-2022
17th 3D GeoInfo Conference, 19–21 October 2022, Sydney, Australia
This contribution has been peer-reviewed.
https://doi.org/10.5194/isprs-archives-XLVIII-4-W4-2022-13-2022 | © Author(s) 2022. CC BY 4.0 License.
18
Figure 4. Proposed support for 3D within existing spatial standards
spatial encoding and data sharing. Thus, reducing the require-
ment to implement ad hoc spatial encoding and querying func-
tions in order to deal with the increased complexity of 3D ob-
jects. One example is the ability to leverage DGGS technolo-
gies via ISO 19170-1 (ISO, 2021)/OGC Abstract Specification
Topic 21 (Gibb(Ed.), 2021). DGGS infrastructures (particularly
volumetric [3D/4D] DGGS) provide a way to reduce the com-
plexity of spatial queries on objects because both the topology
and geometry of DGGS infrastructures are simplified, common
throughout the entire infrastructure and consistent with both
9IM and 25IM. While a conventional 25IM spatial query of
two, or more, 3D objects is standardised (at the algorithm level),
its implementation usually results in a significant computation
burden every time that particular query operation is run. By
’mapping’ or ’tagging’ these objects to the zones of a DGGS in-
frastructure this same 25IM query can be performed repeatedly
with much more simplicity and very minimal computation over-
head. This is because a 9IM/25IM query (and all 9IM/25IM
queries for that matter) can be reduced to a simple database in-
dex lookup operation rather than a spatial query operation.
5. CONCLUSION
As we have shown there are many alternative implementations
of 3D data models consistent with a common underlying the-
ory, but varying in how topology in particular is captured rel-
ative to geometry primitives. In the interests of interoperability
between these and minimisation of proliferation of still more
data exchange patterns here exists a case to define a formal 3D
profile of ISO 19107 for the subset of 3D operations needed
to handle existing uses of 3D data in standardised application
models. This profile would form the basis of a series of func-
tional capabilities that are implemented in reusable software
libraries, simplifying declaration of interoperability and allow-
ing transformations between different data representations, for
different needs.
REFERENCES
Burrough, P. A., McDonnell, R. A., Lloyd, C. D., 2015. Prin-
ciples of Geographical Information Systems. 3rd edn, Oxford
University Press, Oxford; New York.
Butler, H., Daly, M., Doyle, A., Gillies, S., Schaub, T., Hagen,
S., 2016. The GeoJSON Format. RFC 7946. https://www.rfc-
editor.org/info/rfc7946.
Car, N. J., Homburg, T., Perry, M., Herring, J., Knibbe, F.,
Cox, S. J., Abhayaratna, J., Bonduel, M., 2021. OGC Geo-
SPARQL - A geographic query language for RDF data: 1.1.
Opengis® implementation standard, Open Geospatial Consor-
tium. https://opengeospatial.github.io/ogc-geosparql/.
Clementini, E., Di Felice, P., Oosterom, P., 1993. A small set
of formal topological relationships suitable for end-user inter-
action. Advances in Spatial Databases, 692, 277–295.
Dube, M., 2017. Topological augmentation: A step forward for
qualitative partition reasoning. Journal of Spatial Information
Science, 14, 1–29.
Egenhofer, M., Herring, J., 1990. Categorizing binary topolo-
gical relations between regions, lines and points in geographic
databases, the 9-intersection: Formalism and its Use for Natur-
allanguage Spatial Predicates. Santa Barbara CA National Cen-
ter for Geographic Information and Analysis Technical Report,
94, 1–28.
Ellul, C., Haklay, M., 2006. Requirements for Topology in 3D
GIS. Transactions in GIS, 10(2), 157–175.
Gibb(Ed.), R., 2021. Topic 21 - Discrete Global Grid
Systems - Part 1 Core Reference system and Opera-
tions and Equal Area Earth Reference System. Ogc ab-
stract specification topic, Open Geospatial Consortium.
http://www.opengis.net/doc/AS/dggs/2.0.
IETF, 2017. The JavaScript Object Notation (JSON)
Data Interchange Format. Technical report, Internet En-
gineering Taskforce, California, USA. https://www.rfc-
editor.org/rfc/rfc8259.
The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLVIII-4/W4-2022
17th 3D GeoInfo Conference, 19–21 October 2022, Sydney, Australia
This contribution has been peer-reviewed.
https://doi.org/10.5194/isprs-archives-XLVIII-4-W4-2022-13-2022 | © Author(s) 2022. CC BY 4.0 License.
19
ISO, 2004. ISO 19125-1:2004 Geographic Informa-
tion — Simple Feature Access — Part 1: Common
Architecture. Technical report, International Organ-
ization for Standardization, Geneva, Switzerland. ht-
tps://www.iso.org/standard/40114.html.
ISO, 2012. ISO 19152:2012 Geographic Information — Land
Administration Domain Model (LADM). Technical report, In-
ternational Organization for Standardization, Geneva, Switzer-
land. https://www.iso.org/standard/51206.html.
ISO, 2015. SO 19109:2015 Geographic information — Rules
for application schema. Technical report, International Or-
ganization for Standardization, Geneva, Switzerland. ht-
tps://www.iso.org/standard/59193.html.
ISO, 2016a. ISO 10303-21:2016 Industrial automation sys-
tems and integration — Product data representation and ex-
change — Part 21: Implementation methods: Clear text en-
coding of the exchange structure. Technical report, Interna-
tional Organization for Standardization, Geneva, Switzerland.
https://www.iso.org/standard/63141.html.
ISO, 2016b. ISO/IEC 13249-3:2016 Information technology
— Database languages — SQL multimedia and application
packages — Part 3: Spatial. Technical report, International
Organization for Standardization, Geneva, Switzerland. ht-
tps://www.iso.org/standard/60343.html.
ISO, 2018. ISO 16739-1:2018 Industry Foundation Classes
(IFC) for data sharing in the construction and facility manage-
ment industries — Part 1: Data schema. Technical report, In-
ternational Organization for Standardization, Geneva, Switzer-
land. https://www.iso.org/standard/70303.html.
ISO, 2019a. ISO 10303-42:2019 Industrial automation sys-
tems and integration — Product data representation and ex-
change — Part 42: Integrated generic resource: Geomet-
ric and topological representation. Technical report, Interna-
tional Organization for Standardization, Geneva, Switzerland.
https://www.iso.org/standard/78579.html.
ISO, 2019b. ISO 19107:2019 Geographic Information
— Spatial Schema. Technical report, International Or-
ganization for Standardization, Geneva, Switzerland. ht-
tps://www.iso.org/standard/66175.html.
ISO, 2020. ISO 19136:2020 Geographic Information — Geo-
graphy Markup Language (GML). Technical report, Interna-
tional Organization for Standardization, Geneva, Switzerland.
https://www.iso.org/standard/75676.html.
ISO, 2021. ISO 19170-1:2021 Geographic information —
Discrete Global Grid Systems Specifications — Part 1:
Core Reference System and Operations, and Equal Area
Earth Reference System. Technical report, International Or-
ganization for Standardization, Geneva, Switzerland. ht-
tps://www.iso.org/standard/32588.html.
Kalogianni, E., Janeˇ
cka, K., Kalantari, M., Dimopoulou, E.,
Bydłosz, J., Radulovi´
c, A., Vuˇ
ci´
c, N., Sladi´
c, D., Govedarica,
M., Lemmen, C., van Oosterom, P., 2021. Methodology for the
development of LADM country profiles. Land Use Policy, 105,
105380.
Kellogg, G., Champin, P.-A., Longley, D., 2020. JSON-
LD 1.1 A JSON-based Serialization for Linked Data.
W3C recommendation, World Wide Web Consortium.
https://www.w3.org/TR/json-ld/.
Kolbe, T. H., Kutzner, T., Smyth, C. S., Nagel, C., Roens-
dorf, C., Heaze, C., 2021. OGC® City Geography Markup
Language (CityGML). Opengis® conceptual model stand-
ard, Open Geospatial Consortium. https://docs.ogc.org/is/20-
010/20-010.html.
Ledoux, H., 2018. val3dity: validation of 3D GIS prim-
itives according to the international standards. Open
Geospatial Data, Software and Standards, 3(1), 1.
https://doi.org/10.1186/s40965-018-0043-x.
Lemmen, C. H. J., Oosterom, P. J. M. v., Unger, E.-M., Kalo-
gianni, E., Shnaidman, A., Kara, A., Alattas, A., Indrajit, A.,
Smyth, K., Milledrogues, A., Bennett, R. M., Oukes, P. R.,
Gruler, H.-C., Casalprim, D., Alvarez, G., Aditya, T., Su-
caya, K. G. A., Guarin, J. M. M., Balas, M., Zulkifli, N. A.,
Zeeuw, C. J. d., 2020. The land administration domain model:
advancement and implementation. (Cancelled) Annual World
Bank Conference on Land and Poverty 2020: Institutions for
Equity and Resilience.
OGC, 2007. GML - the Geography Markup Language. Tech-
nical report, Open Geospatial Consortium, Arlington, VA,
USA. http://www.opengis.net/gml/.
OGC, 2011. OGC Reference Model. Open Geospatial Consor-
tium Inc., Wayland, MA.
OGC, 2021. OGC Testbed-17: OGC Features and Geo-
metries JSON Engineering Report. Technical report,
Open Geospatial Consortium, Arlington, VA, USA.
http://www.opengis.net/doc/PER/t17-D008.
Perry, M., Herring, J., 2012. OGC GeoSPARQL - A
geographic query language for RDF data. Opengis® im-
plementation standard, Open Geospatial Consortium. ht-
tps://www.ogc.org/standards/geosparql.
Randell, D., Cui, Z., Cohn, A., 1992. A spatial logic based on
regions and connection. Principles of Knowledge Representa-
tion and Reasoning: Proceedings of the 1st International Con-
ference, 165–176.
Scarponcini, P., Gruler, H.-C., Stubkjær, E., Axelsson, P., Gran-
holm, L., Jensen, J., Liebich, T., Halustchak, O., 2016. OGC®
Land and Infrastructure Conceptual Model Standard (Land-
Infra). Opengis® implementation standard, Open Geospatial
Consortium. http://www.opengis.net/doc/is/landinfra/1.0.
Stroud, I., 2006. Boundary Representation Modelling Tech-
niques. Springer, London.
Theobald, D. M., 2001. Topology revisited: representing spa-
tial relations. International Journal of Geographical Informa-
tion Science, 15(8), 689–705.
W3C, 2001. XML Linking Language (XLink) Version
1.0. W3C recommendation, World Wide Web Consortium.
https://www.w3.org/TR/2001/REC-xlink-20010627/.
Worboys, M., 1995. GIS: A computing perspective. Taylor &
Francis, London.
Zhou, M., Guan, Q., 2019. A 25-Intersection Model for repres-
enting Topological Relations between Simple Spatial Objects
in 3-D Space. International Journal of Geo-Information, 182.
Zlatanova, S., 2017. Topological Relationships and Their Use.
Springer International Publishing, Cham, 2275–2295.
Zlatanova, S., Rahman, A. A., Shi, W., 2004. Topological
models and frameworks for 3D spatial objects. Computers &
Geosciences, 30(4), 419–428.
The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLVIII-4/W4-2022
17th 3D GeoInfo Conference, 19–21 October 2022, Sydney, Australia
This contribution has been peer-reviewed.
https://doi.org/10.5194/isprs-archives-XLVIII-4-W4-2022-13-2022 | © Author(s) 2022. CC BY 4.0 License.
20
