OpenStreetMap infrastructures

Generate an infrastructure using open data from OSM with our osm-to-railjson tool

1: How to generate infrastructure from OSM
2: Working with OSM data

As detailed here, in order to benefit from all OSRD functionalities, the following objects are required:

Track sections
Switches
Curves and slopes
Signals and detectors
Routes
Electrifications
Operational points
Loading gauges
Speed sections

For SNCF Réseau production environments, this data is sourced from internal private databases and is then transformed into the railjson format using closed-source code. For another railway infrastructure manager owning this data for its own area of operation, this can be done as well. However, to let anyone (including people outside of the railway infrastructure industry) try and improve OSRD, we have developed an algorithm that generates a realistic infrastructure using OpenStreetMap tracks as only input. It is important to note that this infrastructure is realistic and not real. This allows to easily generate a real-looking infrastructure for any place in the world!

As a demonstration, such generated infrastructures (France, Belgium and Morocco) are available in the public demo website.

1 - How to generate infrastructure from OSM

Describe the steps to generate an infrastructure from OSM data

On geofabrik, download the .osm.pbf file corresponding to the area you want. Here we take Germany as an example.
This is not mandatory, but using osmium is strongly recommended to filter the .osm.pbf file with only the railway-related data needed by osm_to_railjson. The tag railway is used on nodes, ways and relations, and the tag public_transport=stop_area is used on relations. This can divide by 3 the time taken by the osm_to_railjson generation.
```
osmium tags-filter <path/to/germany.osm.pbf> nwr/railway r/public_transport=stop_area -o <path/to/germany.osm.pbf>
```
Launch conversion (release build of editoast and conversion can be long):
```
cd ../../editoast
cargo run --release -p osm_to_railjson -- <path/to/germany.osm.pbf> <path/to/germany_railjson.json>
```
Depending on the area, signals data can be missing. If so, the --generate-signals option overrides the potential existing signals with automatically generated realistics ones.

Load the generated railjson, either using load-railjson-script.sh or OSRD’s web interface:

cargo run --release -- infra import-railjson --generate "Germany_OSM" <path/to/germany_railjson.json>

2 - Working with OSM data

Describe the problems and solutions related to working with OSM data using OSRD

Problems

Some data is not available from OpenStreetMap (OSM), either because it’s not public (like signals in France) or because it has not been collected in OSM yet (like slopes).

OSM data in OSRD

The following list resumes the different objects used in OSRD, roughly sorted by their importance in the application.
This gives an idea about their role in OSRD and how they are extracted (or not) from OSM.

Data	Importance	Source
Track sections	Required. This one’s pretty obvious why.	Extracted from OSM ways with the tag `railway=rail`.
Switches	Required. Tracks should be explicitly linked by switches to be connected.	Generated from the angle between the track sections that cross each other. A specific switch object exist in OSM but is not used because its quality is uneven.
Signals	Required. Signals are used by the pathfinding and the conflict detection to determine where and how the trains can move on the infrastructure.	Either extracted from OSM nodes with the tag `railway=signal`, or generated using track sections data.
Detectors	Required. Detectors are used in alongside of the signals for the pathfinding.	Generated from the signals data.
Operational points	Almost required. Without it, most of the application feature will not work.	Extracted from OSM relations with the tag `public_transport=stop_area`.
Speed sections	Nice to have. If not defined, a track section has a speed limit of 80 km/h, which will impact the realism of the simulation.	Extracted from OSM tag `maxspeed`.
Electrifications	Nice to have. Electric rolling stocks are not be able to travel on non-electrified tracks.	Extracted from OSM tag `voltage`.
Loading gauges	Nice to have. If not defined, the least restrictive one is used, allowing the trains to run everywhere.	Not extracted, but the data exist (see OSM tag `loading_gauge`).
Slopes	Nice to have. If not defined, tracks are considered flat, which will impact the realism of the simulation.	This data doesn’t exist in OSM.
Curves	Nice to have. If not defined, tracks are considered straight, which will impact the realism of the simulation.	Not extracted. The data exist under another format that would be hard to extract.
Level crossings	Nice to have. Level crossings do not affect the simulation or pathfinding, but their closing information can be analyzed.	Not extracted, but the data exist (see the OSM tag `level_crossing`).
Neutral zones	Nice to have.	We did not explored that yet.

Solutions

If track sections are missing from your data, there’s not much we can do. However, this information is usually in very high quality in OSM because it can be traced using aerial imagery (track geometry can be sketchy in tunnels). But for signals, a option in the infrastructure generation can be used for replacing the existing ones with realisticaly generated signals.

For the operational points, there are a few optional fields (name, uic and local_track_name) that we generate if they are missing to make them easier to use.