Draft:Austria: Difference between revisions

From DATA4PT WIKI
Jump to navigation Jump to search
(creation of austrian page (some parts need to be rephrased))
 
mNo edit summary
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
== Overview in the National Level ==
== Overview in the National Level ==
For many implementations the VDV standards (incl. VDV736) are preferred over other options, for them being tailored to the regional specifics.
For many implementations, the VDV standards (incl. VDV736) are preferred over other options, for them being tailored to the regional specifics.


[https://data.mobilitaetsverbuende.at/en MVO] publishes NeTEx data and preferably uses VDV736 (SIRI-SX) for situation information.
[https://data.mobilitaetsverbuende.at/en MVO] publishes NeTEx data and preferably uses VDV736 (SIRI-SX) for situation information.
Line 7: Line 7:


=== Description ===
=== Description ===
For our purposes of operating and maintaining the customer information channels of Wienerlinien (Wienmobil-App, digital signage & departure boards, Website, On-Board Information, etc.), we have introduced an API-Gateway as a middleware component.
For the purposes of operating and maintaining customer information channels (such as the WienMobil app, digital signage and departure boards, the website, on-board information, etc.), Wiener Linien has introduced an API gateway as a middleware component. This ensures that all customer-facing channels source their information from a single system (the API gateway), providing consistent information across all available platforms.
 
This is to ensure that all information channels presented to the customer source the information from one single system (API-Gateway). Thus, the customer will find homogenous information in all channels available to them.


=== Architecture ===
=== Architecture ===
Since the data sources of the API-Gateway may provide different formats or data necessary for ‘customer information’ may be scattered over various independent sources, we have decided to implement SIRI and/or NeTEx as canonical data format within the API-GW.
Since the data sources connected to the API Gateway may provide different formats, or the data required for "customer information" may be scattered across various independent sources, Wiener Linien has implemented SIRI and/or NeTEx as the canonical data formats within the API Gateway. This approach facilitates the consolidation of information within the API Gateway, ensuring it serves as the single point of truth for all customer information channels.


This allows for easy consolidation of information within the API-GW to ensure the API-GW is the single point of truth for all customer information channels.
The API Gateway can provide customer information channels with data in the canonical format (SIRI or NeTEx) or transform the data into any format required by the consuming system.


The API-GW can provide the customer information channels directly with information in the canonical format (SIRI or NeTEx) or transform the data into any format required by the consuming system.
For specific use cases, the data can be enriched before being provided to the customer information channels:
 
For certain use cases the data can be enriched before being provided to the customer information channel:


* Automatic translation of SIRI-SX Situation Descriptions
* Automatic translation of SIRI-SX Situation Descriptions
* Generation of sign language video
* Generation of sign language videos
* Generation of workload or delay estimates based on ML
* Creation of workload or delay estimates using machine learning


=== Use cases ===
=== Use cases ===
The following use cases illustrate how Wiener Linien utilizes the API Gateway and data standards to operate and maintain customer information channels:


* FIS+: On Board information screens in our latest subway rolling stock (X-Wagen)
FIS+ involves on-board information screens in the latest subway rolling stock (X-Wagen). The necessary data, including station departures and current situations, is retrieved from internal data sources, transformed into the SIRI-SM and SIRI-SX canonical formats, and then converted into a proprietary format that contains only the most relevant information. This format is extremely lightweight due to limited bandwidth, and the information is subsequently forwarded to the rolling stock.
** The necessary information (station departures & current situations) is pulled from the internal data source, transformed to SIRI-SM & SIRI-SX (canonical format), transformed into a proprietary format containing only the most relevant information (super lightweight as the bandwidth is very limited) and forwarded to the rolling stock.


* Wienmobil App & Wienmobil Monitor: The necessary information (station departures & current situations) is pulled from the data sources (incl. external data sources of other transport operators (ÖBB)), transformed to SIRI-SM & SIRI-SX (canonical format), cached within the API-GW & forwarded on demand to the APP Backend (not conforming to standard as we omit some of the redundant overhead)
For the WienMobil App and WienMobil Monitor, the relevant information (station departures and current situations) is pulled from multiple data sources, including external sources from other transport operators like ÖBB. This data is transformed into the canonical SIRI-SM and SIRI-SX formats, cached within the API Gateway, and then delivered on demand to the app backend. The format is optimized by omitting redundant overhead to improve efficiency.


* E-Paper timetable: The necessary information (station departures & current situations) is pulled from internal data sources, transformed to SIRI-SM & SIRI-SX (canonical format), cached within the API-GW & forwarded on demand to the e-Paper Backend
The e-Paper timetable follows a similar process. Station departure and current situation data are pulled from internal data sources, transformed into SIRI-SM and SIRI-SX, cached within the API Gateway, and sent to the e-Paper backend as needed.


* Sign language videos: For the generation of sign language videos, the current situations are regularly pulled from internal data sources, transformed to SIRI-SX and forwarded to the API of SignTime. SignTime checks the situation description for new or updated entries and generates a sign language video for each situation. A Weblink to the video is returned and the API-GW can add this link as custom fields to any further SIRI-SX messages.
For the generation of sign language videos, current situation data is regularly retrieved from internal sources, transformed into SIRI-SX, and sent to the SignTime API. SignTime processes the situation descriptions, generating a sign language video for each relevant entry. A link to the video is returned and can be added as a custom field in any subsequent SIRI-SX messages.


* Wienmobil Alexa Skill: The necessary information (station departures) is pulled from the data sources (incl. external data sources of other transport operators (ÖBB) ), transformed into SIRI-SM (canonical format), cached within the API-GW & forwarded on demand to the Backend System of the Alexa Skill
In the case of the WienMobil Alexa Skill, the required information (station departures) is sourced from internal and external data sources (such as ÖBB), transformed into SIRI-SM, cached in the API Gateway, and provided on demand to the backend system of the Alexa Skill.


=== Outcome ===
=== Outcome ===
 
The chosen data standard framework is highly robust, accommodating virtually any use case. However, this flexibility introduces significant complexity, which can be challenging for some colleagues and implementors. Despite this, it is well-suited as a canonical data format for these reasons. With this framework in place, Wiener Linien is well-prepared to meet the requirements of EU Regulation 2017/1926.
* Very well thought out data standard framework -> Any Use Case is possible.
** This comes at the cost of high complexity, for some colleagues and implementors this is quite challenging.
** Perfect as canonical data format for that reason.
* We are ready to tackle EU DV 2017/1926.

Latest revision as of 16:15, 17 September 2024

Overview in the National Level

For many implementations, the VDV standards (incl. VDV736) are preferred over other options, for them being tailored to the regional specifics.

MVO publishes NeTEx data and preferably uses VDV736 (SIRI-SX) for situation information.

Use cases

Description

For the purposes of operating and maintaining customer information channels (such as the WienMobil app, digital signage and departure boards, the website, on-board information, etc.), Wiener Linien has introduced an API gateway as a middleware component. This ensures that all customer-facing channels source their information from a single system (the API gateway), providing consistent information across all available platforms.

Architecture

Since the data sources connected to the API Gateway may provide different formats, or the data required for "customer information" may be scattered across various independent sources, Wiener Linien has implemented SIRI and/or NeTEx as the canonical data formats within the API Gateway. This approach facilitates the consolidation of information within the API Gateway, ensuring it serves as the single point of truth for all customer information channels.

The API Gateway can provide customer information channels with data in the canonical format (SIRI or NeTEx) or transform the data into any format required by the consuming system.

For specific use cases, the data can be enriched before being provided to the customer information channels:

  • Automatic translation of SIRI-SX Situation Descriptions
  • Generation of sign language videos
  • Creation of workload or delay estimates using machine learning

Use cases

The following use cases illustrate how Wiener Linien utilizes the API Gateway and data standards to operate and maintain customer information channels:

FIS+ involves on-board information screens in the latest subway rolling stock (X-Wagen). The necessary data, including station departures and current situations, is retrieved from internal data sources, transformed into the SIRI-SM and SIRI-SX canonical formats, and then converted into a proprietary format that contains only the most relevant information. This format is extremely lightweight due to limited bandwidth, and the information is subsequently forwarded to the rolling stock.

For the WienMobil App and WienMobil Monitor, the relevant information (station departures and current situations) is pulled from multiple data sources, including external sources from other transport operators like ÖBB. This data is transformed into the canonical SIRI-SM and SIRI-SX formats, cached within the API Gateway, and then delivered on demand to the app backend. The format is optimized by omitting redundant overhead to improve efficiency.

The e-Paper timetable follows a similar process. Station departure and current situation data are pulled from internal data sources, transformed into SIRI-SM and SIRI-SX, cached within the API Gateway, and sent to the e-Paper backend as needed.

For the generation of sign language videos, current situation data is regularly retrieved from internal sources, transformed into SIRI-SX, and sent to the SignTime API. SignTime processes the situation descriptions, generating a sign language video for each relevant entry. A link to the video is returned and can be added as a custom field in any subsequent SIRI-SX messages.

In the case of the WienMobil Alexa Skill, the required information (station departures) is sourced from internal and external data sources (such as ÖBB), transformed into SIRI-SM, cached in the API Gateway, and provided on demand to the backend system of the Alexa Skill.

Outcome

The chosen data standard framework is highly robust, accommodating virtually any use case. However, this flexibility introduces significant complexity, which can be challenging for some colleagues and implementors. Despite this, it is well-suited as a canonical data format for these reasons. With this framework in place, Wiener Linien is well-prepared to meet the requirements of EU Regulation 2017/1926.