Data model and import process

When the project was first created, import modules directly fiddled with the internal data structures of OSRD. This had a number of issues:

• the result of the import process was hard the visualize, which in turn made difficult differentiating between broken import code and broken core OSRD code
• many input formats use XML, which is very slow to parse
• RailML has many ways to express a location, which is good for inter exchange and avoiding data loss, but isn't needed for the purpose of simulation: only the actual position of objects on tracks matter. In general, most input formats have much more information than what's needed for the bare simulation needs, which makes parsing slower
• adding new features which require data input to the OSRD core requires directly importing from an external file format, which might not support said needed data: developers have to come up with both the feature, and import hacks for at least one file format, all at once

To address these concerns, we decided to introduce RailJSON, an internal intermediary representation. This file format very closely matches what's internally needed by the simulation engine. It has a number of advantages:

• it is much faster to parse than RailML or RSL, as JSON is much simpler and faster to parse than XML
• creating an import module for a new file format doesn't require understanding internal OSRD infrastructure implementation details, as the interface for importing infrastructure is already defined in a rigid way by RailJSON
• when a new feature which requires new data is added to the OSRD core, support can first be added and tested with RailJSON, and then support for importing the new data can be added into external file formats to RailJSON converters. Having two subproblems makes things much more manageable from a software engineering standpoint

This is not meant as a public inter exchange format, please don't use it outside of OSRD