Tracking Tracks

_{(4 min read)}

We often write about road-related topics and especially about how to gather, store and transform data into different formats. For every enterprise there is a different data format out there trying to solve the representation of reality better than the previous ones. But we are also rail fanatics and used the biggest rail technology fair to get an update about geodata in the rail domain (besides trainspotting): The InnoTrans in Berlin came back from pandemic break and GEONATIVES visited InnoTrans for the eleventh time.

The usage of inspection trains has been common business for decades. Such inspection is focusing on track inspection, catenary examination, dynamics performance monitoring and signal inspection during speeds of up to 350 km/h. Nevertheless, mobile mapping reached the railway domain some years ago in order to digitalize the rail network and all related infrastructure assets alongside the tracks. Usually, large rail networks are maintained only by one (state) company and such companies manage their data to their proprietary needs. Often, data management evolved over decades serving specific requisites. In the beginning, self-developed formats were used to store data in a simplified format (e.g. database schema based on Microsoft access database files, as Deutsche Bahn uses them for rail network and signaling database). The data didn’t have to represent reality in an exact way and abstraction was part of the modeling concept:

• To operate the rail network, on the one hand you don’t need knowledge about exact curvatures and positions of signals as long as the logical signaling block is represented correctly.
• On the other hand, the exact geometries and cable layouts can be stored in geographically unreferenced CAD files without the need to use them in real-time simulation/operation applications.

That’s why also open data formats are not modeling the rail network in an accurate way:

• railML provides the description of radius change at given positions with different mathematical definitions. But often LineStrings are used instead of mathematical representation for modeling the tracks (read: measured data is converted directly into LineStrings instead of interpolating LineStrings based on radiusChange information) for ease of use in additional applications. Additionally, the infrastructure is modeled in an abstract way by referring to relative information nodes (in one of our expert interviews you can read more about railML and it’s relation to digital twins).
• Another format that is widely used in the railway domain is landXML (even if their website looks like stranded in the 90s). It can model tracks as curves and spirals and can better describe different layers of superstructure.

But how can these data be utilized?

One major trend is the building information modeling (BIM) that is exhausted in the railway domain to the max: BIM is not only used to plan buildings and their infrastructure, but, additionally, all the rail-related assets such as signaling, communication, wiring, etc. are incorporated as well. A lot of specialized construction trades will deploy their planning into the overall data model. Sub-work items (e.g., cable ducts, noise barriers, etc.) from detailed design have to be antedated to an overall preliminary planning in one BIM representation. These work items are modeled separately and interchanged using Industry Foundation Classes (IFC) for BIM.

As mentioned in the beginning, big rail network infrastructure operators still have their own data formats and continue to collect (or let collect) data in these formats. Sometimes these operators allow only specific design software (e.g., ProVI or AutoCAD or Bentley OpenRail) and, therefore, data providers need to stick to the present data formats. Internally, they are often using their own, OGC-Simple-Features-driven format to be able to convert into the customer’s format. Therefore, often CAD and GIS formats are still used to convert the point clouds from mobile mapping into a processed representation. The result is that no mathematically exact representation is used and, again, attributed LineStrings take over from the beginning instead of interpolating them from the measured data to keep reality’s truth. The usage of CAD plans is also often the golden mean because (public) approval bodies often continue to require 2d paper plans only.

Public authorities suffer from limited resources and the development of a new standard can cost a lot of time and therefore money. Additionally, if a new standard is available, modeling and storage software has to be updated and, again, adoption will cost effort and time. If you have limited resources (esp. tax money should be spent wisely), you focus on daily business instead of inventing something new. The daily business is focusing on getting the construction done and not contributing to an overall digital twin for, for example, mobility simulation. Currently, the most promising cross-domain application is visualization for decision-making and public participation. More and more citizens would like to know and understand what happens in their backyard and a rendering or video is worth a thousand words.

But with the possibility to show how new infrastructure fits into the environment new interests for impact analysis (e.g. on traffic flow, noise emission, etc.) rises, especially when different stakeholders want to understand the impact of the change in infrastructure (you can read more about the synergies of digital twin usage in one of our features). In the end, this constant public request of information and participation can be the driver for a slow but steady change in data representation. It still has a long way to go but we are on the right track.