Austria - Revision history

Anonymous: added short description of wiener linien

2024-12-11T12:26:28Z

added short description of wiener linien

← Older revision		Revision as of 14:26, 11 December 2024
Line 1:		Line 1:
	== Overview in the National Level ==		== Overview in the National Level ==
	~~''TO GET MORE INFO ON 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.

Line 9:		Line 7:

	=== Description ===		=== Description ===
	''~~MISSING A SHORT DESCRIPTION OF~~ Wiener Linien''		'''Wiener Linien''' (Viennese Lines) is the company running most of the public transit network in the city of Vienna, Austria. Thus, it is responsible for managing the city's extensive network of buses, trams, and metro systems. It was established in 1978, and is part of the city corporation Wiener Stadtwerke.

	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.		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.

Anasfou: Anasfou moved page Draft:Austria to Austria

2024-12-11T12:02:07Z

Anasfou moved page Draft:Austria to Austria

← Older revision	Revision as of 14:02, 11 December 2024
(No difference)

KaiP Wienerlinien: Formatting of use case list fixed & Direct mention of third party removed

2024-09-30T09:16:49Z

Formatting of use case list fixed & Direct mention of third party removed

← Older revision		Revision as of 11:16, 30 September 2024
Line 31:		Line 31:
	* 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.		* 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.		* 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 a third party API. The thrid party system 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.
	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.

	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 implementers. 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.		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 implementers. 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.

Anasfou: /* Implementation */

2024-09-25T08:23:04Z

Implementation

← Older revision		Revision as of 10:23, 25 September 2024
Line 1:		Line 1:
	== Overview in the National Level ==		== Overview in the National Level ==
			''TO GET MORE INFO ON 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.

Line 7:		Line 9:

	=== Description ===		=== Description ===
			''MISSING A SHORT DESCRIPTION OF Wiener Linien''

	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.		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.

Line 23:		Line 27:
	The following use cases illustrate how Wiener Linien utilizes the API Gateway and data standards to operate and maintain customer information channels:		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.		* '''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 '''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.		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.
Line 34:		Line 37:

	=== 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.		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 implementers. 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.

Anasfou: /* Use cases */

2024-09-25T08:18:58Z

Use cases

← Older revision		Revision as of 10:18, 25 September 2024
Line 20:		Line 20:
	* Creation of workload or delay estimates using machine learning		* Creation of workload or delay estimates using machine learning

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

Anonymous at 14:15, 17 September 2024

2024-09-17T14:15:29Z

← Older revision		Revision as of 16:15, 17 September 2024
Line 21:		Line 21:

	=== 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+ 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.		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.

Anonymous: rephrasing

2024-09-17T09:34:36Z

rephrasing

← Older revision		Revision as of 11:34, 17 September 2024
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~~-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.		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 ~~certain~~ use cases the data can be enriched before being provided to the customer information ~~channel~~:		For specific use cases, the data can be enriched before being provided to the customer information channels:

	* 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 ===
			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.

	* FIS+: On Board information screens in our latest subway rolling stock (X-Wagen)		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 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)

	* 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.

Anonymous: creation of austrian page (some parts need to be rephrased)

2024-09-13T08:01:59Z

creation of austrian page (some parts need to be rephrased)

New page

== 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.

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

== Use cases ==

=== 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.

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 ===
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.

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-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 certain use cases the data can be enriched before being provided to the customer information channel:

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

=== Use cases ===

* FIS+: On Board information screens in our latest subway rolling stock (X-Wagen)
** 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)

* 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

* 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.

* 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

=== Outcome ===

* 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.