{"id":2426,"date":"2026-09-28T19:50:00","date_gmt":"2026-09-28T18:50:00","guid":{"rendered":"https:\/\/www.geonatives.org\/?p=2426"},"modified":"2026-09-28T20:15:34","modified_gmt":"2026-09-28T19:15:34","slug":"maps-for-automated-driving-in-railway-domain","status":"publish","type":"post","link":"https:\/\/www.geonatives.org\/?p=2426","title":{"rendered":"Maps for Automated Driving in Railway Domain"},"content":{"rendered":"\n

(5 min read)<\/sub><\/p>\n\n\n

\n
\"\"
InnoTrans was celebrating 30 years in 2026. (Berlin, Image by Marius Dupuis)<\/em><\/figcaption><\/figure>\n<\/div>\n\n\n

This year at InnoTrans<\/a> we had a closer look at autonomous driving in the railway domain with focus on mainline and depot operations. In difference to closed-line services such as metro systems automation is more complicated because of mixed traffic, potential third-party influences, and different kinds of rail operation management. The cooperation project “AutomatedTrain<\/a>” presented their final results and we talked to some of the experts behind the project.<\/p>\n\n\n\n

The goal of the project is not to show that you can automate trains (because we all know about this), the focus is on providing a reference architecture to enable the industry to build upon a commonly agreed basis and make solutions interoperable for railway undertaking. Thus, the project is about to publish all the work they did including architecture description and technical specifications.<\/p>\n\n\n\n

\n
\n
\"\"
Sensor pod attached to a commuter train, similar to what we know from automotive domain. (Berlin, image by Andreas Richter)<\/em><\/figcaption><\/figure>\n<\/div>\n\n\n\n
\n

But let\u2019s start with the solution itself: making automated driving possible. A sensor set similar to what we know from the automotive domain (including camera, Radar and Lidar) was developed and mounted to two different trains. One attached externally to an already-in-use commuter train, the second one integrated into a new local train.<\/p>\n\n\n\n

The scope of the sensor set was to replicate what a human train driver is able to handle, for example having a visibility range of up to 500 meters under ideal conditions. The sensor should then identify if there were unusual objects in the driveway, and for that the map comes into play.<\/p>\n\n\n\n

Due to the fact that a train has limited possibilities to move, it is easy to narrow down the area of interest. The train follows a specific corridor encoded in the map. The interest is about the objects next to it: All objects we know such as catenary masts (with extensions), signals and signs, equipment cabinets, platforms, boom and noise barriers, etc. are part of the map, everything else (broken trees, blown away debris, vehicles, tools etc.) including the dynamic elements such as passengers, track workers and animals are not part.<\/p>\n<\/div>\n<\/div>\n\n\n\n

The map<\/strong><\/p>\n\n\n\n

The map<\/a> is an adapted GeoJSON format with an additional schema that encodes 40 object types with some hierarchical dependencies. Therefore, the format is not a true GeoJSON but close to it to maintain easy accessibility by machines as well as humans. The data itself is represented by line strings and polygons. <\/p>\n\n\n\n

\n
\n

The dependencies of the object types define for example, which extensions can be mounted to a mast and how they are attached. Also multiple classes of humans were implemented to differentiate between passengers at platforms and track workers at platforms and track field. The potential risk of collisions can be calculated differently: If track workers are close to the track moving parallel to it the situation can be understood as safe, because the staff seems to be aware of the approaching train. If the track workers are intersecting the corridor the train can start a minimal risk maneuver and blow the horn or start braking. If the persons are not classified as official staff, emergency braking could be applied. The same happens with objects in the corridor which are not part of the map and considered as being dangerous.<\/p>\n<\/div>\n\n\n\n

\n
\"\"
It’s about the track corridor. (Berlin, image by Marius Dupuis)<\/em><\/figcaption><\/figure>\n<\/div>\n<\/div>\n\n\n\n

The map is also used for highly precise localization independent from the fact that a train has the advantage of having additional equipment to determine its own location by using inertial measurement units (IMU) and measuring wheel encoders. The map and the included rail infrastructure that is measured precisely<\/a> enables landmark navigation. The European Train Control System (ETCS) balises are only used for the operational localization of the train in the block sections.<\/p>\n\n\n\n

The digital register<\/strong><\/p>\n\n\n\n

The map is part of the “Digital Register<\/a>” to create the single source of truth. We already learned about various data pools which can co-exist in parallel<\/a>, modeling the same content in different formats with different identifiers. The digital register creates the data frame to describe the relevant topological data and embed layered high-definition data (with respect to accuracy<\/a>) to support driving assistance systems and the localization of vehicles. And to unlock the potential of this there is the need of standardization to not run into vendor-lock-in issues. Thus, the Digital Register is also a central component of the so-called “Innovation Pillar” of Europe’s Rail Joint Undertaking (ERJU) funded project “R2DATO” (Rail to Digital automated up to Autonomous Train Operation), which is part of the EU research program “Horizon Europe” and aims to create the basis for pioneering future technologies for the rail sector. The rail industry shall provide interoperable solutions (as the AutomatedTrain project showed because the two participating rail OEM Siemens and Alstom have developed solution which build upon the same sensor setup, processing framework and map definition) so that different train classes can be used on different tracks using the same input.<\/p>\n\n\n\n

Based on the data silos we already have, there could be the idea of transforming already existing data into the new lightweight data format. But to be honest automated trains won\u2019t hit the rail overnight. The launch of such applications will start with depot operations, continue on branch lines and finally try to cover main lines, too. It will be easier to survey the track from scratch with the sensor sets of the deployed rolling stock. It would not only create the first version of the map also the update of this would be easier because the data source is always the same.<\/p>\n\n\n\n

The two use cases of object detection and classifying as well as localization lead to the situation that the map is safety critical. Therefore the accuracy and the correctness have to be guaranteed every time. Creating the map from scratch and keeping it up to date with the sensor set of the used rolling stock seems to be a suitable solution to meet this safety requirement.<\/p>\n\n\n\n

In contrast to the AutomatedTrain project the company FUTURAIL<\/a> is also working on autonomous driving solutions in the railway domain including perception, localization, and driving and providing these solutions as products. For localization purpose they use a map, too but it is currently a proprietary point cloud format and does not incorporate any external sources. It might meet the safety requirement perfectly but would not be interoperable.<\/p>\n\n\n\n

The project AutomatedTrain is about to release the documentation and the specification but also some datasets<\/a>. They will include images, radar and Lidar as well as GNSS and IMU data but also annotated object classes. This can help to develop new applications building upon the whole framework and let third-parties such as FUTURAIL utilize basics so that they can focus on building competing self-driving solutions instead of re-inventing the wheel set.<\/p>\n\n\n\n

One more thing<\/strong><\/p>\n\n\n\n

Also at InnoTrans the Italian joint rail infrastructure operating company Rete Ferroviaria Italiana\u00a0(RFI) presented TINO (Train INspection Of railway)<\/a>, an autonomous driving inspection vehicle for high-speed lines. It can operate with a speed of up to 200 km\/h with a total operation range of 400 km. It shall be used to check main lines regarding their train control infrastructure as well as regarding obstacles or unauthorizes persons. Such kind of clearance runs are done for automated operations in closed systems such as in the Copenhagen s-tog system. This is a perfect use case for utilizing a map representing the rail and rail-side objects to check integrity of the rail line.<\/p>\n\n\n

\n
\"\"
Unmanned railway vehicle TINO used as a platform for the advanced inspection and monitoring of the railway network. (Berlin, image by Andreas Richter)<\/em><\/figcaption><\/figure>\n<\/div>\n\n\n

<\/p>\n","protected":false},"excerpt":{"rendered":"

We visited the InnoTrans 2026 to get an update about the state of affairs regarding automated driving in railway domain<\/p>\n","protected":false},"author":2,"featured_media":2439,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,10],"tags":[21,79,43,46,64],"class_list":["post-2426","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-data-formats","category-in-the-news","tag-autonomous-driving","tag-innotrans","tag-maps","tag-railroad","tag-standardization"],"_links":{"self":[{"href":"https:\/\/www.geonatives.org\/index.php?rest_route=\/wp\/v2\/posts\/2426","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.geonatives.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.geonatives.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.geonatives.org\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.geonatives.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2426"}],"version-history":[{"count":9,"href":"https:\/\/www.geonatives.org\/index.php?rest_route=\/wp\/v2\/posts\/2426\/revisions"}],"predecessor-version":[{"id":2447,"href":"https:\/\/www.geonatives.org\/index.php?rest_route=\/wp\/v2\/posts\/2426\/revisions\/2447"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.geonatives.org\/index.php?rest_route=\/wp\/v2\/media\/2439"}],"wp:attachment":[{"href":"https:\/\/www.geonatives.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2426"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.geonatives.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2426"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.geonatives.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2426"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}