Ontology and geospatial resources in Urban Digital Twins

One of the most common mistakes when designing the semantic layer of an Urban Digital Twin is treating the ontology as if it were the place where all the city’s information “lives”. It is not, and it should not be. The ontology is the nexus, not the warehouse. And understanding that distinction completely changes the way you design the data architecture.

In this post I share the pattern that works best when you use SAREF4CITY (ETSI TS 103 410-4) as the semantic layer and need to connect it with the heavyweight geospatial assets typical of a Digital Twin: orthoimagery, LiDAR point clouds, 3D meshes, elevation models, vector tilesets.

Open Table of contents

The principle: separate semantics from geospatial resources
Linking pattern: three pieces you combine
Concrete example
How it fits with STAC and NGSI-LD
In summary

The principle: separate semantics from geospatial resources

Figure 1. General overview of the top levels of the SAREF4CITY extension.

SAREF4CITY, like any serious semantic ontology, exists to describe three things: what an urban entity is, where it is, and how it relates to other entities. A building is an s4city:CityObject, belongs to an s4city:AdministrativeArea, provides public services modelled with CPSV, has associated KPIs modelled with s4city:KeyPerformanceIndicator, and is located at a point in space.

What the ontology must not do is store the gigabytes of pixels of the orthophoto covering that building, nor the millions of LiDAR points describing its real geometry, nor the 3D tileset rendered in CesiumJS. Those resources live in their natural place: cloud-native storage, in formats designed for partial and efficient access (COG for rasters, COPC for LiDAR, 3D Tiles for meshes, PMTiles for tiled vectors, GeoParquet for geospatial tables), served through standard OGC APIs (Tiles, Coverages, Features, EDR).

The semantic graph only holds metadata and URIs pointing to those resources. Three immediate benefits:

Scalability. The triplestore stays at a reasonable size and SPARQL queries remain fast.
Separation of concerns. The semantic layer reasons over entities; the serving layer delivers bytes. Each one optimises its own workload.
Independent evolution. You can reprocess the orthophoto without touching the graph, or reorganise the ontology without migrating terabytes.

This principle fits naturally into a layered architecture where the semantic layer lives in a triplestore (Apache Jena Fuseki, GraphDB, Stardog), the catalogue layer in STAC or equivalent, and the storage layer in GCS/S3 buckets behind an OGC API Gateway.

Linking pattern: three pieces you combine

The pattern relies on three standard building blocks, all of them well-established vocabularies.

1. SAREF4CITY for the urban entity

Here you model the city object itself: a building, a street segment, a streetlight, a park, an administrative district, a FeatureOfInterest on which observations are made. You use the native classes of the s4city: namespace and the spatial topology the ontology already brings, including containment within administrative areas, relationships between urban objects, and linkage to public services via CPSV.

This layer is what gives meaning to everything else. Without it, the geospatial resources are orphan files in a bucket.

2. GeoSPARQL (OGC) for the geometry

SAREF4CITY already reuses geosp (GeoSPARQL) and geo (W3C Basic Geo) as imported ontologies. GeoSPARQL is the standard bridge between RDF and the GIS world: it gives you the geosparql:Feature and geosparql:Geometry classes, the geosparql:hasGeometry property to link entities with their geometry, and serialisations in WKT and GML via geosparql:asWKT and geosparql:asGML.

The important part: any serious triplestore understands GeoSPARQL natively (GraphDB, Stardog, Jena with the jena-geosparql module), which means you can execute spatial queries like geof:within, geof:intersects, or geof:distance directly in SPARQL without leaving the graph. For small geometries (centroid, footprint, administrative polygon) this is perfectly efficient.

What you are not going to put here is the detailed geometry of millions of objects. That is what the next piece is for.

3. DCAT and PROV for the heavyweight geospatial resource

Each heavyweight resource (the district orthophoto COG, the LiDAR flight COPC, the neighbourhood 3D tileset, the road network PMTiles) is described as a dcat:Dataset with one or more dcat:Distribution entries. Each distribution has its own stable URI and the essential metadata:

dcat:accessURL pointing to the OGC API endpoint where it is served.
dct:format with the media type (image/tiff; application=geotiff; profile=cloud-optimized for COG, application/vnd.laszlo.copc+octet-stream for COPC, etc.).
dct:conformsTo with the OGC standard the endpoint conforms to.
dcat:byteSize, dct:spatial, dct:temporal for descriptive metadata.
prov:wasDerivedFrom for processing traceability, telling you which flight the point cloud came from, which algorithm generated the DSM, which pipeline version produced the tileset.

PROV-O brings something critical for an operational Digital Twin here: lineage. When someone asks “where does this data come from?”, the graph answers without ambiguity.

Concrete example

Let’s see how it all ties together in a real case. A building in the city centre with three associated geospatial representations: its cadastral footprint, a LiDAR point cloud, and the coverage of the most recent orthophoto.

@prefix s4city: <https://saref.etsi.org/saref4city/> .
@prefix geosparql: <http://www.opengeospatial.org/ont/geosparql#> .
@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix ex: <https://digitaltwin.city.example/> .

ex:Building_1234 a s4city:CityObject ;
    s4city:locatedIn ex:District_Centre ;
    geosparql:hasGeometry ex:geom_1234 ;
    ex:hasPointCloudRepresentation ex:cloud_1234 ;
    ex:hasOrthoimageCoverage ex:ortho_2024_centre ;
    ex:has3DTilesRepresentation ex:tileset_centre_lod2 .

ex:geom_1234 a geosparql:Geometry ;
    geosparql:asWKT "POLYGON((-3.7038 40.4168, ...))"^^geosparql:wktLiteral .

ex:cloud_1234 a dcat:Dataset ;
    dct:title "LiDAR Building 1234, 2024 acquisition" ;
    dcat:distribution [
        a dcat:Distribution ;
        dct:format "application/vnd.laszlo.copc+octet-stream" ;
        dcat:accessURL <https://api.city.example/copc/bldg_1234.copc.laz> ;
        dct:conformsTo <https://www.ogc.org/standards/ogcapi-coverages>
    ] ;
    prov:wasDerivedFrom ex:lidar_flight_2024_madrid .

ex:ortho_2024_centre a dcat:Dataset ;
    dcat:distribution [
        a dcat:Distribution ;
        dct:format "image/tiff; application=geotiff; profile=cloud-optimized" ;
        dcat:accessURL <https://api.city.example/cog/ortho_2024_centre.tif>
    ] .

With this structure, a SPARQL query can retrieve all the geospatial representations of a building in a single shot, and the frontend (CesiumJS, deck.gl, MapLibre) knows exactly which endpoint to call for each type of resource. The lightweight geometry lives in the graph and can be queried spatially with GeoSPARQL; the heavyweight assets live in their optimal storage and are served on demand through OGC APIs.

The properties ex:hasPointCloudRepresentation, ex:hasOrthoimageCoverage and ex:has3DTilesRepresentation do not exist in SAREF4CITY. This is where you need a small in-house extension module that defines them formally: classes such as PointCloudRepresentation, OrthoimageCoverage, Tileset3D as subclasses of dcat:Dataset, and the object properties that link them to s4city:CityObject. It is a couple of days of work and it stays as a reusable asset.

How it fits with STAC and NGSI-LD

Two integrations that matter in practice.

STAC for the operational catalogue. STAC (SpatioTemporal Asset Catalog) is the de-facto standard for cataloguing geospatial assets in the cloud (COG, COPC, remote sensing products). It is the catalogue consumed by the frontend at runtime. The rule is simple: each stac:Item is also exposed as a dcat:Dataset in the graph, linked to the corresponding s4city:CityObject. The graph gives you semantics and reasoning; STAC gives you fast spatiotemporal discovery for visualisation.

NGSI-LD for operational entities. If the Digital Twin platform uses Orion-LD, NGSI-LD entities carry primary geometry as GeoProperty with native GeoJSON, and the heavyweight resources as Property whose value is the resource URI. By configuring the @context correctly, those attributes align with the same RDF properties in the graph, and you get consistency between the operational view (NGSI-LD) and the semantic view (SPARQL).

In summary

The ontology is not a warehouse. It is the nexus that gives meaning and lets you navigate between urban entities, their lightweight geometries, and their heavyweight geospatial representations, without any of the three layers having to carry the load of the others. SAREF4CITY brings the urban vocabulary, GeoSPARQL the geometry and spatial queries, and DCAT and PROV the standard descriptor for cloud-native resources served through OGC APIs.

Designed this way, the Digital Twin scales horizontally: adding a new type of geospatial resource (SAR radar, thermography, mobile mapping, federated BIM twin) means extending the in-house DCAT module, not rebuilding the semantic layer. And the city gains something that is rarely achieved from the outset: a knowledge graph that can be queried, reasoned over and federated, aligned with European standards (SAREF, INSPIRE, MIMs) and open to integration with external platforms.