Difference between revisions of "Draft:Italy"

From DATA4PT WIKI
Jump to navigation Jump to search
(Created page with "in progress")
 
Line 1: Line 1:
in progress
+
 
 +
= Overview in National Level =
 +
For the exchange of Public Transport (PT) data with Italian National Access Point (NAP), a NeTEx Profile has been defined among the affected stakeholders.
 +
 
 +
The profile is a subset of the standard; it has been defined selecting the needed concepts (entities and associated attributes) for specific use cases or set of use cases and complemented by rules defined to restrict possibilities of divergent interpretations of open parts of the standard.
 +
 
 +
For Italy, Passenger Information and PT contracts information exchange have been identified as primary Use Cases. In this perspective two levels profile has been defined:
 +
 
 +
- Passenger Information profile (level 1)
 +
- Contracts profile (level 2 – incremental)
 +
 
 +
The italian Profile will be then extended to cover Fares, Alternative Modes (sharing mobility, micromobility) and Accessibility Use Cases, in order to cover all the category data required by Del. Reg. 1926/2017.
 +
 
 +
Typical  Passenger Information’s Use Cases are:
 +
 
 +
- provision of operativity calendars and timetables
 +
- provision of network topology and routes
 +
- provision of transport operators
 +
- provision of access nodes to stop places
 +
- For the level 1 of the Italian Netex Profile, European Passenger Information Profile (EPIP) has been identified as defined in the CEN Technical Specification prTS 16614:PI Profile.
 +
 
 +
Contracts profile
 +
For Contracts, Use Cases are:
 +
 
 +
provision of Contract / Journey Accounting (with operator roles)
 +
provision of Stop Points Facilities (ticketing, accessibility, safety, etc.)
 +
provision of Vehicles Equipments (lift/ramps, wheelchair etc)
 +
The level 2 of the Italian Netex Profile, is defined upon the first level of European Passenger Information Profile (EPIP).
 +
 
 +
Italian implementation
 +
For the Italian NeTEx profile implementation , a dedicated Guideline document has been defined together with an example for each level that shows how to fill the needed structures: the first fully compliant with EPIP (European Passenger Information Profile) and the second including level 2 of NeTEx Italian Profile (e.g. contracts).
 +
 
 +
NAP MMTIS
 +
The italian NeTEx profile is used to exchange with the NAP MMTIS (National Access Point Multi-Modal Travel Information Services) the transport information collected at regional level through collectors named RAP (Regional Access Points) and National Transport Operators. The following figure shows the architecture of this implementation:
 +
 
 +
 
 +
 
 +
= Bolzano, STA (Südtiroler Transportstrukturen)=
 +
 
 +
STA (Südtiroler Transportstrukturen), the in-house company working on behalf of the Public Transport Authority in Bolzano.
 +
STA is positioned in a unique location: is part of Italy but very close to Austria and the majority of the people speaks German. This means that the travel information STA offers (such as bus stop names) has to be multilingual. Therefore, there were needed a standard which allows then to exchange this kind of information considering the multilingual data. NeTEx provided this opportunity. 
 +
STA is in the process of innovating their IT architecture. They opted to implement NeTEx and SIRI ‘natively’, meaning there is no conversion between the production of the data and NeTEx data files from another exchange data format.
 +
 
 +
== System Architecture ==
 +
 
 +
STA opted to implement NeTEx and SIRI ‘natively’, meaning there is no conversion between the production of the data and NeTEx data files from another exchange data format. 
 +
 
 +
 
 +
== Usage ==
 +
 
 +
LinkingAlps is one of the EU projects in which they develop a decentralised network of travel information services. This network will be created by interlinking existing regional or national journey planner services from all neighbour countries, with focus on multimodal transport (public transport, railways, new modes) through a standardised exchange service.
 +
 
 +
Also, for LinkingAlps, they chose to introduce standards that are ready for any future architecture and can accommodate future developments on for example MaaS and ticketing.
 +
 
 +
== Outcome ==

Revision as of 16:58, 29 March 2024

Overview in National Level

For the exchange of Public Transport (PT) data with Italian National Access Point (NAP), a NeTEx Profile has been defined among the affected stakeholders.

The profile is a subset of the standard; it has been defined selecting the needed concepts (entities and associated attributes) for specific use cases or set of use cases and complemented by rules defined to restrict possibilities of divergent interpretations of open parts of the standard.

For Italy, Passenger Information and PT contracts information exchange have been identified as primary Use Cases. In this perspective two levels profile has been defined:

- Passenger Information profile (level 1) - Contracts profile (level 2 – incremental)

The italian Profile will be then extended to cover Fares, Alternative Modes (sharing mobility, micromobility) and Accessibility Use Cases, in order to cover all the category data required by Del. Reg. 1926/2017.

Typical Passenger Information’s Use Cases are:

- provision of operativity calendars and timetables - provision of network topology and routes - provision of transport operators - provision of access nodes to stop places - For the level 1 of the Italian Netex Profile, European Passenger Information Profile (EPIP) has been identified as defined in the CEN Technical Specification prTS 16614:PI Profile.

Contracts profile For Contracts, Use Cases are:

provision of Contract / Journey Accounting (with operator roles) provision of Stop Points Facilities (ticketing, accessibility, safety, etc.) provision of Vehicles Equipments (lift/ramps, wheelchair etc) The level 2 of the Italian Netex Profile, is defined upon the first level of European Passenger Information Profile (EPIP).

Italian implementation For the Italian NeTEx profile implementation , a dedicated Guideline document has been defined together with an example for each level that shows how to fill the needed structures: the first fully compliant with EPIP (European Passenger Information Profile) and the second including level 2 of NeTEx Italian Profile (e.g. contracts).

NAP MMTIS The italian NeTEx profile is used to exchange with the NAP MMTIS (National Access Point Multi-Modal Travel Information Services) the transport information collected at regional level through collectors named RAP (Regional Access Points) and National Transport Operators. The following figure shows the architecture of this implementation:


Bolzano, STA (Südtiroler Transportstrukturen)

STA (Südtiroler Transportstrukturen), the in-house company working on behalf of the Public Transport Authority in Bolzano. STA is positioned in a unique location: is part of Italy but very close to Austria and the majority of the people speaks German. This means that the travel information STA offers (such as bus stop names) has to be multilingual. Therefore, there were needed a standard which allows then to exchange this kind of information considering the multilingual data. NeTEx provided this opportunity. STA is in the process of innovating their IT architecture. They opted to implement NeTEx and SIRI ‘natively’, meaning there is no conversion between the production of the data and NeTEx data files from another exchange data format.

System Architecture

STA opted to implement NeTEx and SIRI ‘natively’, meaning there is no conversion between the production of the data and NeTEx data files from another exchange data format.


Usage

LinkingAlps is one of the EU projects in which they develop a decentralised network of travel information services. This network will be created by interlinking existing regional or national journey planner services from all neighbour countries, with focus on multimodal transport (public transport, railways, new modes) through a standardised exchange service.

Also, for LinkingAlps, they chose to introduce standards that are ready for any future architecture and can accommodate future developments on for example MaaS and ticketing.

Outcome