Visit our dedicated RINF roadmap site: roadmap2rinf.eu

The European railway infrastructure register is getting a major update. Here’s what’s changing and how to prepare.

The March 2026 deadline for RINF compliance is approaching, and it brings significant changes to what Infrastructure Managers must deliver to the European Union Agency for Railways. This isn’t just a technical update—the scope of required data is expanding substantially.

The Fundamental Challenge

Delivering consistent, high-quality data to RINF requires more than updating an export routine. Infrastructure Managers face a set of interconnected challenges:

Bringing data together from multiple sources. The information RINF requires—track parameters, signalling systems, electrification, topology—typically lives in different systems across your organisation. Asset management, operations, signalling configuration, and GIS each hold pieces of the picture. RINF compliance means integrating these sources in a reliable, automated way.

Defining what’s true. When the same track appears in multiple systems with different attribute values, which one is correct? You need clear rules—often called survivorship rules—that determine which source is authoritative for which data elements. This is fundamentally a governance question, not a technical one.

Understanding the ERA ontology. RINF 2026 uses a formal semantic model—the ERA ontology—to describe railway infrastructure. Your internal data concepts must map to this shared vocabulary. “What we call X” must align with “what ERA means by Y.” This requires domain experts and data architects working together to understand both your data and the ERA model.

Building a sustainable delivery system. RINF isn’t a one-time export. Infrastructure changes continuously, and your data must stay current. You need processes and systems that can deliver validated, consistent data to ERA on an ongoing basis.

This guide covers the specific changes in RINF 2026—but keep these fundamental challenges in mind. The technical requirements make more sense when you understand them as serving these underlying goals.

Expanding Use Cases: Beyond Route Compatibility

Understanding why RINF is changing helps explain what is changing. The scope of how this data will be used is growing significantly.

The Original Purpose: Route Compatibility Checks

RINF was created to answer a fundamental question: can vehicle X travel route Y? The Route Compatibility Check (RCC) compares vehicle characteristics against infrastructure parameters along a proposed route—checking gauging, axle loads, electrification, signalling systems, and dozens of other parameters.

This use case drove the original RINF design: a register of infrastructure parameters that could be matched against vehicle authorisations.

The Regulatory Vision: A Broader Data Platform

The Commission Implementing Regulation (EU) 2019/777 (as amended by 2023/1694) explicitly defines RINF’s expanding scope. Article 1 states that RINF shall:

• Provide parameters for route compatibility checks
• Support compilation of the Route Book (per TSI OPE Appendix D2)
• Align locations with telematics applications for information exchange
• Serve as reference database for Network Statements
• Enable verification of technical compatibility between fixed subsystems and the network
• Monitor the progress of interoperability of railway fixed installations

The regulation further notes that “further developments of the RINF application may create a data system feeding into all electronic information flows in respect of the Union rail network.”

What This Means in Practice

Route Book Compilation The Route Book—operational documentation for train drivers—will increasingly be generated from RINF data. This requires infrastructure element positioning along routes and parameter applicability for specific journey segments.

Telematics Integration RINF locations must align with those used in TAF/TAP telematics applications. The TSI OPE Application Guide already references RINF as a communication means for operational information, including temporary speed restrictions.

Statistical Analysis ERA has established cooperation with Eurostat to make RINF data available for pan-European infrastructure statistics—supporting policy development, benchmarking, and investment planning.

What This Means for Data Quality

When RINF was primarily for RCC, incomplete data meant some compatibility checks couldn’t be performed. As the data feeds more applications—telematics, statistics, route books—the impact of data gaps and inconsistencies multiplies.

The 2026 requirements reflect this expanded ambition: richer data (topology, spatial), stricter quality standards (SHACL validation), and a flexible architecture (linked data) that can support use cases not yet defined.

The Topology Layer: Modelling How Your Network Connects

The most significant new requirement is the micro-level topology layer. This builds on the connectivity model that RINF already had—and extends it significantly.

What RINF Already Had: Macro-Level Connectivity

The original RINF wasn’t without topology. Sections of Line (SoL) explicitly connected Operational Points through SOLOPStart and SOLOPEnd parameters. A route across the network could be traced as a chain: OP → SoL → OP → SoL → OP.

This macro-level connectivity was sufficient for the original Route Compatibility Check. RCC could traverse from station to station, checking infrastructure parameters along each Section of Line. The question “can vehicle X travel from Brussels to Amsterdam?” could be answered by checking the SoL chain between those operational points.

What’s New: Micro-Level Topology Inside Operational Points

The 2026 requirements add a new layer: explicit modelling of how tracks connect inside operational points.

In a complex station, a train doesn’t just “arrive” and “depart”—it follows a specific path through platforms, switches, and crossings. Different paths through the same station may have different characteristics. The new topology layer captures this internal structure using NetElement and NetRelation classes.

This enables more precise Route Compatibility Checks. Instead of just knowing that a vehicle can travel to a station, RCC can determine which internal routes through that station are compatible—which platforms, which connections, which paths.

What You’ll Need to Provide

Abstraction layer (how things connect):

• NetElement — nodes in the network graph (representing track segments)
• NetRelation — connections between elements, with navigability properties
• NodePort — connection points on each element

Implementation layer (what exists):

• OperationalPoint — stations, junctions, border points
• SectionOfLine — line segments between operational points (as before)
• Track — running tracks and sidings

Both layers must be present and consistent with each other.

Practical Considerations

For many organisations, internal station topology has never been formally documented in structured data. The macro-level model—which stations connect to which lines—was well understood. But the micro-level detail—how tracks connect through switches and crossings inside a station—often exists only in signalling plans and operational experience.

Capturing this systematically requires coordination across departments: signalling, operations, and asset management all hold relevant knowledge.

ERA’s validation will flag disconnected elements and “sinking points” (elements with no outgoing connections). Your network must form a coherent, traversable graph at both macro and micro levels.

Spatial Data: Full GeoSPARQL Support

RINF 2026 requires proper geographic representation of infrastructure elements using the OGC GeoSPARQL standard.

What This Means

Operational points must include geographic coordinates in Well-Known Text (WKT) format:

turtle

era:BE_Brussels_South
    geo:hasGeometry [
        geo:asWKT "POINT(4.3365 50.8356)"^^geo:wktLiteral
    ] .

This enables spatial queries directly within the RINF knowledge graph—finding infrastructure within a geographic area, calculating distances, and validating spatial consistency.

Alignment with Topology

Your spatial data and topology data must be consistent. If your GIS places a track endpoint at specific coordinates, and your topology says that endpoint connects to a particular operational point, those must align.

For organisations where GIS and asset management have operated as separate systems, this integration work is an important preparation step.

Persistent Identifiers: From Local IDs to URIs

Every infrastructure element in RINF 2026 needs a globally unique, persistent URI (Uniform Resource Identifier) rather than a local document ID.

What This Means

Instead of internal identifiers like id="OP_001", you’ll provide URIs following ERA’s namespace structure:

http://data.europa.eu/949/functionalInfrastructure/operationalPoints/BE_OP_001

These URIs are:

• Globally unique across all Infrastructure Managers
• Persistent over time, even as assets change
• Dereferenceable — they can be looked up to retrieve data

Why This Matters

URIs enable linked data across the European railway network. When your Belgian infrastructure references a German border point, those connections become queryable across the entire knowledge graph.

Identity Management Considerations

Most organisations have the same infrastructure elements represented in multiple source systems—asset management, operations, signalling configuration—each with different internal identifiers.

You’ll need to establish:

• Which source system provides the canonical identifier for each element type
• Rules for handling conflicts when sources disagree
• Processes for maintaining URI stability as assets are renamed, split, or decommissioned

ERA supports both hash-based URIs (for content traceability) and canonical URIs (for stability). Your approach should align with your data governance requirements.

ERA Namespace Structure

The Shift to Linked Data

RINF 2026 moves from XML document exchange to RDF (Resource Description Framework) linked data. This is a significant architectural change in how infrastructure data is represented.

From Documents to Knowledge Graph

Previously, RINF submissions were XML documents with hierarchical structure—tracks nested inside operational points, parameters nested inside tracks. Relationships were implied by document structure.

In the linked data model, everything is expressed as explicit statements (triples): subject-predicate-object. A track doesn’t “belong to” an operational point by being nested inside it; there’s an explicit era:track relationship connecting them.

turtle

era:BE_Brussels_South
    rdf:type era:OperationalPoint ;
    era:opName "Brussels-South" ;
    era:track era:BE_Track_T1 .

What This Enables

The European RINF becomes a queryable knowledge graph with over 30 million statements. Cross-border queries, route compatibility checks, and data integration across Infrastructure Managers become possible in ways that document-based exchange couldn’t support.

Validation with SHACL

Document validation moves from XML Schema (XSD) to SHACL (Shapes Constraint Language). SHACL can express constraints that span multiple resources—for example, ensuring that every track references a valid operational point that actually exists in the graph.

ERA publishes the SHACL shapes your data must conform to. Running validation locally before submission helps catch issues early.

Preparing for RINF 3.1

The specific requirements—topology, spatial data, URIs, linked data—are detailed in the sections above. But step back to the fundamental challenges outlined at the start:

Getting Organised

Data integration: Which systems hold the data RINF requires? How will you bring them together? Manual processes don’t scale; you need automated pipelines that can run reliably as your infrastructure changes.

Truth and governance: When sources conflict, what’s authoritative? These decisions need to be made explicitly, documented, and implemented consistently. This is organisational work as much as technical work.

Ontology alignment: Your teams need to understand the ERA ontology—not just the data format, but the semantic meaning. What does ERA mean by a “Track”? A “NetElement”? How do your internal concepts map to theirs? This requires time and expertise.

Sustainable delivery: RINF compliance isn’t a project with an end date. Your infrastructure changes; your data must follow. Build systems and processes that can deliver validated data continuously, not just once.

Timeline

With the March 2026 deadline for topology layer compliance, the preparation window is limited. Organisations that start early have more time to address data gaps, build integration pipelines, and develop the necessary expertise.

Summary

RINF 3.1 reflects an expanded ambition: from a register for macro-level route compatibility checks to a knowledge graph supporting micro-level routing, telematics, statistics, route books, and applications yet to come.

The technical requirements serve a broader goal: consistent, high-quality infrastructure data that can support the evolving needs of European rail interoperability. Meeting those requirements means addressing the fundamentals—data integration, governance, ontology alignment, and sustainable delivery processes.

Kapernikov builds Master Data Management systems for railway infrastructure. Our platform supports linked data, configurable data models, full GIS integration, and the temporal dimensions that railway asset data requires. If you’re preparing for RINF 2026, we’d welcome a conversation about your specific situation.

Learn more at roadmap2rinf.eu