Nils Steyaert has been working in data governance and master data management since 2011. He has built data models for Elia, Infrabel, and Fluxys—covering railways, electricity grids, and gas transmission networks.
At Kapernikov, he leads our data modeling work for railway infrastructure managers.
What data models are we building for railway infrastructure today?
We're building a lot of models: for signals, tunnels, catenary, etc. But we started with topology—it's the foundation of everything. You can't describe infrastructure without first defining how tracks connect to each other and how they're subdivided. Only then can you relate other railways assets to the tracks. Included in the model are the levels of topology.
What do you mean by "levels" of topology?
There are generally three levels considered when modeling railway topology: micro, meso, and macro (nano also exists but it is less often used). The levels each serve different use cases.
Micro level is the logical detail. It's not just physical rails, but the logical connections between switches, buffer stops, and track segments. Every switch state and connection is explicit.
Meso level aggregates micro elements into "Operating Points" (OPs) like stations or yards. But crucially, keeps the individual tracks connecting them. If two stations are connected by four tracks, the Meso level shows four connections. It's about capacity.
Macro level simplifies further. The station is still a node, but the connection becomes a single logical "Line". Whether it's two tracks or four, at Macro level it's just one link. It's about network routing.
How the three levels of topology aggregate data.
Who decides what counts as an "operational point"?
The infrastructure manager. The ERA ontology gives examples, but it's ultimately your choice. Anywhere something can happen—loading, unloading, stopping, maintenance—can be defined as a point of interest. The ontology isn't prescriptive about all what qualifies, only that border should be agreed upon between the respective parties.
When do you use each level?
As said before, each levels serves different uses. It all depends on what you're trying to do.
For asset management, micro level matters. You need to know which specific piece of rail needs maintenance, which switch and which signal is used where and how often.
For train routing, you might only need macro level. You don't care about the internal track layout of a station—you just need to know which stations connect to which lines.
At all three levels you're answering the same question: from this track, which other tracks can a train reach? The granularity changes based on your use case.
Are all three levels defined in the ERA ontology?
No, not explicitly like e.g. the related RailTopoModel. The micro level is defined by the topology package, whereas meso and macro are aggregations done by abstract infrastructure elements called 'operational point' and 'sections of line'. Those two notions are usually enough to describe what you need, better to keep it simple. The challenge is just deciding how you use them for your specific purposes.
Do you model all three levels separately?
We focus on defining the micro level perfectly. The higher levels—meso and macro—are essentially aggregations of that base reality by projecting other railway concepts on top.
Think of it as zooming out. You don't redraw the map; you just group nodes in an orderly fashion. A collection of micro nodes (switches, tracks) becomes one meso node (Operational Point). Two meso nodes connected by a line become a macro relationship.
Same for point assets next to the track. A signal gets a position relative to the micro topology. Everything references that foundation.
Why use micro as the base?
Accuracy. The higher you go in level, the less precise your positioning becomes. If you need to know exactly where something is—and for asset management, you do—micro level is where that precision lives. It's also about correctness and simplicity: the micro level is the one where you can easily physically verify and it shows a physical reality shared by all.
The takeaway
Topology is the skeleton that everything else hangs on. Get it right at micro level, and the higher levels follow. Get it wrong, and your entire data model becomes unreliable.
Questions about topology modeling?
We can walk you through how this applies to your infrastructure data.
Book a call