Data model

Nexus organizes data into worlds. Each world in itself contains vector features, timeseries, rasters and files.

Worlds¶

Nexus World

A world is an up-to-date and consistent digital representation of a geographic area, generated from a set of data sources. Each organization with a Nexus license typically owns its own world, containing all spatial objects that together form a digital twin of (a piece of) the real world relevant to that organization. This world is generated out of a selection of data sources and calculations chosen by that organization. Notice that different organizations operating in the same geographical area may have a different representation of reality through their own worlds. For example, if one organization chooses to have all roads in the area generated from a data source like OpenStreetMaps, while another organization generates the same area from official governmental data sources. A third organization may choose to combine such data sources, and enrich them with their own data.

Each world in Nexus consists of the following data:

vector features - digital representations of real world objects. Features are in Nexus are automatically categorized by type. Common feature types are for example buildings, roads, trees, schools, monitoring stations etcetera. See vector feature types for an overview of feature types supported by Nexus.
timeseries - collections of measurements or observations over time. For example daily temperature measurements at weather stations or simulated flow rates in a drinking water distribution network
rasters - spatial grids with a unique value for each grid cell.
files - raw binary files, such as images, documents, spreadsheets etcetera.

Vector features¶

If a vector feature has a geometry, it will be stored by Nexus. A feature may have multiple geometries, such as a polygon, centroid or centerline. These properties are not mutually exclusive. For example, a feature can have both a circumference (polygon) and a centroid. Geometric properties are stored in separate table columns.

Note

Feature types in Nexus are always written in singular form and lowercase. For example road, weather_station, building_unit.

Feature identification¶

Features can change in time. A street might at some point get a different name, its geometry may be updated when more accurate measurements become available and at multiple times in its life cycle its asphalt layer may be renovated. Yet if the street's properties can change over time, how can we identify it consistently? And how can we find this feature back in its original data source? Nexus uses 3 unique identifiers for each individual feature to identify it and to see where it came from. These three identifiers are present on each table:

id - the primary key of the feature. This ID is generated by Nexus and uniquely identifies the feature. It is always of data type integer and guaranteed unique for each feature type.
dc_id - the Data Connection ID. Each object available through Nexus originates from a particular data source or calculation, and the Data Connection ID identifies the source. Note that generally multiple features of the same type originate from the same source.
id_src - the original identifier for the feature within the original data source. This identifier has datatype text and is always guaranteed to be unique in combination with the dc_id.

Relationships¶

Sometimes features are related to other features. For example, a single building consists of many different apartments (called 'building units' in Nexus) that are linked to that building, monitoring stations often contain multiple sensors and instruments and a neighbourhood belongs to a municipality. In Nexus, such relationships are encoded through so-called foreign keys. The table of a related feature contains a column referring to the primary key (id column) of another table. This allows you to follow the relationship and retrieve related features.

Timeseries¶

In normal language, the concept timeseries actually refers to two different things: the set of measurements as a whole and the actual measurements itself. Nexus explicitly considers both aspects separately, with timeseries referring to the set, and event to each individual value withing that set. Timeseries have a parameter and always relate to a feature. As an example: a timeseries with daily average temperatures as parameter contains one event per day (the actual observation for that day, with a specific timestamp and an observed value). The timeseries relates to a feature, which is the specific weather station, at which the observations are done.

Distinguishing between timeseries, events and their related feature allows Nexus to store and retrieve data efficiently. For example, when retrieving data, we could first make a selection in the timeseries that we want based on some criteria (fast data lookup), and then as a second step retrieve the events of any timeseries we're interested in (more data, retrieval needs more time). Likewise, we could first select the feature, then check which timeseries are registered for that feature, and finally obtain the events.

Like with feature types, timeseries relate to events and to features through foreign key relationships. Each timeseries has a an id, dc_id, a feature_type and feature_id. Events relate back to timeseries as each event has a timeseries_id that corresponds to the timeseries' id property. When selecting the feature type to which a timeseries belongs, the feature_type and feature_id jointly identify which feature that is.

Rasters¶

Rasters can be thought of as matrices with a spatial orientation. Like with timeseries, we can think of rasters as a set of values and the actual values (each pixel or matrix element being an individual value). Nexus stores metadata about each raster separately from the raster values themselves, allowing for quick filtering and selection prior to retrieving all data. Like feature types and timeseries, each raster in Nexus has its own id and dc_id. In addition, the raster also contains a timestamp and parameter.

Files¶

Files are always linked to a vector feature. Like with rasters and timeseries, Nexus stores the file metadata separately from the actual files themselves.