With the ultimate goal of enabling the provision of multimodal transportation services, the EU Regulation 2017/1926 is requiring transport stakeholders to allow access to their data in specific data formats (i.e., NeTEx, SIRI). Currently, the requested data formats are rarely used, thus a data conversion is needed.
This regulation is based in the EU Directive 2010/40/EU for the deploymen of Intelligent Transport Systems in the field of road transport and for interfaces with other modes of transport.
The SNAP solution supports data conversion, decreasing the time required to perform it and hiding its complexity. With SNAP transportation data will be compliant with the EU Regulation in a snap 🤞
Transport authorities, operators and infrastructure managers can render their legacy data interoperable and compliant with standards using a solution fit to their needs
Below is the list of vocabularies that are being created within the SNAP Project specially for use by transit organisations or authorities but also for any other organisation which wants to make their transit data compliant with Transmodel model of the European ITS Directive.
This is the catalog of the SKOS list generated as part of the development of the Transmodel Ontology.
Below is a list of vocabularies that are reused within the Transmodel Ontology. It is important to mention that for the development of these vocabularies, the methodology being used for this project has not been explicitly followed. Therefore, there is no documentation available related to Use Cases, User Stories, etc.
It is important to note that, according to the used existing ontology engineering methodology, and as recorded commonly in other ontology engineering methodologies as well, these non-ontological resources have gone through an extensive process of reengineering so as to avoid the biases that may have a negative impact on the resulting ontologies.
This is due to the fact that the choice of implementation (UML, XML and CSV, respectively) usually generates modelling biases, especially when it comes to representing the names of properties (local vs global names), n-ary relations, enumerations that can be converted into thesauri or controlled lists of codes, etc. Therefore, the process of reengineering has focused on eliminating as many of these biases as possible so as to generate a model that is sufficiently rich in terms of expressiveness and makes a natural usage of the ontology modelling language OWL, which is the one commonly used for ontology implementation nowadays.
Three are the resources which have helped into the implementation of the Transmodel Ontology: the Transmodel model (UML), the NeTEx standard (XML Schema) and de GTFS model (CSV).
The Transmodel model is the CEN (European Committee for Standardization) European Reference Data Model for Public Transport Information. As discussed in the corresponding website, it provides "an abstract model of common public transport concepts and data structures that can be used to build many different kinds of public transport information system, including timetabling, fares, operational management, real time data, journey planning etc".
The Transmodel (version 6, 2017) is made available in UML and browsable and downloadable from its downloads section.
The NeTEx (public transport Network Timetable Exchange) is another CEN standard for the interoperable exchange of public transport passenger information between systems. It is implemented in XML schema, with its latest version (v1.09) being available at Github. The functional scope of NeTEx is divided into three parts, each covering a functional subset of Transmodel: Part 1 describes the fixed Network (stops, routes, lines, etc.); Part 2 is mainly focused on Timetables; and Part 3 covers Fare data.
The GTFS (General Transit Feed Specification) model is a format proposed by Google for the representation of public transportation schedules and associated geographic information, which has become a de facto standard for the publication of the information on public transport that can be used to provide trip planning functionality.
The last version of the GTFS feed (revised January 17, 2019) consists of a collection of at least 5, 2 conditionally required and up to 15 CSV files contained within a .zip file, which describe together a transit system's scheduled operations as visible to riders. It is focused on scheduled information and does not include real-time information, for which there is the GTFS-realtime specification.