Difference between revisions of "FAQ NeTEX"

From DATA4PT WIKI
Jump to navigation Jump to search
(Created page with "= NeTEx overview = 250px|right|link=http://netex-cen.eu/|alt= '''NeTEx''' has been developed under the aegis of CEN (Comité Européen de Normalisation) an...")
 
 
(23 intermediate revisions by the same user not shown)
Line 1: Line 1:
= NeTEx overview =
+
== How do you create C# classes from the NeTEx XSD? ==
[[File:NeTEx.png|250px|right|link=http://netex-cen.eu/|alt=]]
 
  
'''NeTEx''' has been developed under the aegis of CEN (Comité Européen de Normalisation) and is the most recent development stage in over fifteen years work to systemise and harmonize European passenger information data.
+
It is possible to create C# classes in different ways.
  
NeTEx provides a means to exchange data for passenger information such as stops, routes timetables and fares, among different computer systems, together with related operational data. It can be used to collect and integrate date from many different stakeholders, and to reintegrate it as it evolves through successive versions.
+
There are many tools out there, but for instance, you could use the Microsoft xsd.exe tool or the mganss/XMLSchemaClassGenerator tool available on Github at https://github.com/mganss/XmlSchemaClassGenerator
  
NeTEx is intended to be a general purpose XML format, designed for the efficient, updateable exchange of complex transport data among distributed systems. This allows the data to be used in modern web services architectures and to support a wide range of passenger information and operational applications.
+
Currently there are some issues if you try to use the official NeTEx XSD as a starting point with either of these tools.
  
To find out more about the '''NeTEX data model''', visit the [http://netex-cen.eu/ NeTEX website].
+
However, the above-mentioned tools work fine if you use them together with an adapted set of XSD-files available from Data4PT. The file set is designed to be compatible with the official NeTEx XSD and to cover many important use cases. It does however not cover all use cases possible with the official schema. There is an interactive graphical presentation of the adapted and reduced XSD available at https://data4pt.org/NeTEx/GraphicKit/Documention_of_reduced_XSD.html
  
To verify your NeTEx data, use our [https://greenlight.atomite.io/ '''free validation tool'''].
+
If you wish to try out this reduced XSD, you can download it at https://data4pt.org/NeTEx/GraphicKit/XSD_reduced.zip
  
=NeTEx-Light  =
+
The work steps if you are using the Microsoft tool are:
[[File:NeTEx EPIP reduced XSD.png|right|thumb|link=https://data4pt.org/NeTEx/GraphicKit/Documention_of_reduced_XSD.html|Graphic and interactive technical presentation NeTEx Light (reduced XSD)]]The normative NeTEx schema could be considered very big and extensive. Code generation tools for C# have difficulties with processing it. In order to use NeTEx within C# this derived XSD was created. This schema should be used informative, for application development, but not for validation purposes. This schema has been reduced to only match the scope of the EPIP Profile (European Passenger Information Profile) but remains compliant with the main NeTEx Schema.
 
  
The '''graphic interactive technical presentation''' and the technical artefacts are available [https://data4pt.org/NeTEx/GraphicKit/Documention_of_reduced_XSD.html here].
+
Get the zipped XSD. Extract the ZIP to a folder.
 +
Make sure that you have a recent version of the xsd.exe. It is part of the .NET Framework Developer Pack and can be downloaded from https://dotnet.microsoft.com/download/dotnet-framework
 +
Install the developer pack. The xsd.exe will be placed in a folder with a path similar to C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools
 +
Open a command prompt in the same folder as where the NeTEx_publication_reduced-NoConstraint.xsd resides.
 +
Execute the following command (you may have to adapt the path to xsd.exe): "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\xsd.exe"/c/language:C# gml_combo_v3_2_1_simplified.xsd NeTEx_publication_reduced-NoConstraint.xsd
 +
The work steps if you are using the MGANSS tool are:
  
=NeTEx EPIP =
+
* Get the zipped XSD. Extract the ZIP to a folder.
Ideally, all member states will provide NeTEx files according to the European Passenger Information Profile (EPIP) on their respective National Access Point. Data4PT provides some artefacts to '''simplify''' producing and quality assure such information.
+
* Download and extract the binary from https://github.com/mganss/XmlSchemaClassGenerator/releases to a separate folder e.g. C:\MGANSS.
EPIP-adapted version of the full NeTEx XML schema has been produced.  
+
* Open a command prompt in the same folder as where the NeTEx_publication_reduced-NoConstraint.xsd resides.
* Browse the '''graphic and interactive''' technical presentation and download the relevant artefacts and available example [https://data4pt.org/NeTEx/GraphicKit/Documention_of_XSD_for_EPIP.html here].
+
* Execute the following command (you may have to adapt the path to the exe):
[[File:NeTEx EPIP XSD.png|center|thumb|link=https://data4pt.org/NeTEx/GraphicKit/Documention_of_XSD_for_EPIP.html|Graphic and interactive technical presentation NeTEx XSD for EPIP]]
+
C:\MGANSS\XmlSchemaClassGenerator.Console.exe NeTEx_publication_reduced-NoConstraint.xsd -n http://www.opengis.net/gml/3.2=gml-v
<br clear=all>
 
  
= NeTEx national and EU minimum profiles inventory =
+
--[[User:Anasfou|DATA4PT Team]] ([[User talk:Anasfou|talk]]) 19:41, 19 May 2022 (CEST)
A number of national and transnational profiles have already been defined for different European countries, while there are new profiles under development. In the following table, DATA4PT provides an overview of the key characteristics of the national profiles per country, including the data categories that are currently covered. The table will be continuously updated following new implementations.   
 
  
''*Data categories are identified based on [https://eur-lex.europa.eu/eli/reg_del/2017/1926/oj MMTIS EU Regulation 1926/2017]''
+
== Is it possible to get access to the fares/schedule data? ==
  
<nowiki>**</nowiki> European Passenger Information Profile
+
Yes, the part 3 of NeTEx is fully dedicated to fares and works for all modes of public transport (bus, trains, trams, flexible modes, etc.).
  
<nowiki>***</nowiki> European Passenger Information Accessibility Profile   
+
There is a set of white papers describing NeTEx (http://netex-cen.eu/?page_id=14) and one is dedicated to fares:
 +
http://netex-cen.eu/wp-content/uploads/2015/12/10.NeTEx-Fare-WhitePaper_1.04.pdf
  
{| class="wikitable filterable" style="padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;border-spacing:0;text-align:center; "
+
Fares can be quite big topic and people defining them have a lot of imagination. This resulted in NeTex Part 3 being quite big and it is strongly advised to use only a small subset of it which is relevant to your needs. This what we call a Profile. France, Nordic countries, and UK have a fares national profiles. Information about current national profiles is about existing profiles is available [https://data4pt.org/w/index.php?title=NeTEX#Published_profiles here]. A minimum European profile is currently under specification with the support of DATA4PT and it is planned to be delivered to CEN processes by end of June 2024.  
! colspan="18" |Functional scope per profile
 
|-
 
! colspan="2" style="text-align:center; min-width: 100px; max-width: 150px;" |Profiles
 
! style="width: 80px;" |Full NeTEx format
 
! style="width: 80px;" |EPIP**
 
! style="width: 80px;" |EPIAP***
 
! style="width: 80px;" |Austria
 
! style="width: 80px;" |Croatia
 
! style="width: 80px;" |Czech Republic
 
! style="width: 80px;" |Denmark
 
! style="width: 80px;" |France
 
! style="width: 80px;" |Italy
 
! style="width: 80px;" | Netherlands
 
! style="width: 80px;" |Nordic <small><small>(Norway, Sweden, Finland, Denmark currently)</small></small>
 
! style="width: 80px;" |Portugal
 
! style="width: 80px;" |Slovenija
 
! style="width: 80px;" |Switzerland
 
! style="width: 80px;" |UK
 
! style="width: 80px;" |Irish
 
! style="width: 80px;" | German<br> VDV
 
|-
 
| colspan="2" |Availability of NeTEx national profile
 
!
 
!
 
!under development
 
|Specified but  not yet in operation
 
| not yet specified
 
|not yet specified
 
|not yet specified
 
|Specified and partially in operation
 
|Specified but not yet in operation
 
| specified but not yet in  operation
 
|Specified and in use
 
| Specified and in use
 
|specified but not yet in operation
 
|in progress
 
|Specified and in use
 
| specified
 
|
 
|-
 
| colspan="2" |NeTEx EPIP based
 
!
 
!
 
!
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|-
 
| colspan="2" |NeTEx EPIP compatible
 
!
 
!
 
!
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|-
 
| colspan="2" |Available mappings with full NeTEx profile
 
!
 
!
 
!
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|[https://www.vdv.de/netex.aspx VDV NeTEx page]
 
|-
 
| colspan="2" |Available mappings with EPIP profile
 
!
 
!
 
!
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|-
 
! colspan="2" |Data categories
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
|-
 
| style="font-weight:bold; background-color:#efefef;" |LOS 1
 
| style="font-weight:bold; background-color:#efefef;" |Static data -  Level of service 1
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
|-
 
|LOS 1-1
 
| Address identifiers (building  number, street name, postcode)
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|-
 
|LOS 1-2
 
|Topographic places (city, town,  village, suburb, administrative unit)
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|-
 
|LOS 1-3
 
|Points of interest (related to transport information) to which  people may wish to travel
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|-
 
|LOS 1-4
 
|Operational Calendar, mapping  day types to calendar dates
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|-
 
|LOS 1-5
 
|Identified access nodes (all  scheduled modes)
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|-
 
|LOS 1-6
 
|Geometry/map layout structure of  access nodes (all scheduled modes)
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|-
 
|LOS 1-7
 
|Connection links where  interchanges may be made, default transfer times between modes at  interchanges
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|-
 
|LOS 1-8
 
|Network topology and  routes/lines (topology)
 
|[[File:compliant.png|15px|link=]]
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|[[File:compliant.png|15px|link=]]
 
|[[File:compliant.png|15px|link=]]
 
|[[File:compliant.png|15px|link=]]
 
|[[File:compliant.png|15px|link=]]
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|-
 
|LOS 1-9
 
|Transport operators
 
|[[File:compliant.png|15px|link=]]
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|[[File:compliant.png|15px|link=]]
 
|[[File:compliant.png|15px|link=]]
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|-
 
|LOS 1-10
 
|Timetables
 
|[[File:compliant.png|15px|link=]]
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|[[File:compliant.png|15px|link=]]
 
|[[File:compliant.png|15px|link=]]
 
|[[File:compliant.png|15px|link=]]
 
|[[File:compliant.png|15px|link=]]
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|-
 
|LOS 1-11
 
|Planned interchanges between  guaranteed scheduled services
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|For connection links we use  journeyplanner based on OSM map data, road, cycle and pedestrian network is  based on OpenStreetMap
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|-
 
|LOS 1-12
 
|Hours of operation
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|-
 
|LOS 1-13
 
|Vehicles (low floor; wheelchair  accessible.)
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|-
 
|LOS 1-14
 
|Accessibility of access nodes,  and paths within an interchange (such as existence of lifts, escalators)
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|-
 
|LOS 1-15
 
|Existence of assistance services  (such as existence of on-site assistance)
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|-
 
|LOS 1-16
 
|Road network
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|-
 
|LOS 1-17
 
|Cycle network (segregated cycle  lanes, on-road shared with vehicles, on-path shared with pedestrians)
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|-
 
|LOS 1-18
 
|Pedestrian network and  accessibility facilities
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|-
 
|
 
|Framework data
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|-
 
| style="font-weight:bold; background-color:#efefef;" |LOS 2
 
! style="font-weight:bold; background-color:#efefef;" |Static data - Level of service  2
 
!
 
!
 
!
 
!in progress
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
|-
 
|LOS 2-1
 
| Park & Ride stops
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|-
 
|LOS 2-2
 
| Bike sharing stations
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|-
 
|LOS 2-3
 
|Car-sharing stations
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|-
 
|LOS 2-4
 
|Publicly accessible refuelling  stations for petrol, diesel, CNG/LNG, hydrogen powered vehicles, charging  stations for electric vehicles
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|Only charging stations for  electric vehicles
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|-
 
|LOS 2-5
 
|Secure bike parking (such as  locked bike garages)
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|-
 
| LOS 2-6
 
|Information service
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|-
 
|LOS 2-7
 
| Where and how to buy tickets for  scheduled modes, demand responsive modes and car parking (all scheduled modes  and demand-responsive incl. retail channels, fulfilment methods, payment  methods)
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|-
 
|LOS 2-8
 
|Trip plans, auxiliary  information, availability check
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|-
 
|LOS 2-9
 
|Basic common standard fares (all  scheduled modes)
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|-
 
|LOS 2-10
 
|Fare network data (fare  zones/stops and fare stages)
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|-
 
|LOS 2-11
 
|Standard fare structures (point  to point including daily and weekly fares, zonal fares, flat fares)
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|-
 
|LOS 2-12
 
|Vehicle facilities such as  classes of carriage, on-board Wi-Fi.
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|-
 
| style="font-weight:bold; background-color:#efefef;" | LOS 3
 
! style="font-weight:bold; background-color:#efefef;" |Static data - Level of service  3
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
!
 
|-
 
|LOS 3-1
 
|Passenger classes (classes of  user such as adult, child, student, veteran, impaired access and qualifying  conditions and classes of travel such as 1st, 2nd.)
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|-
 
|LOS 3-2
 
| Common fare products (access  rights such as zone/point-to-point including daily and weekly  tickets/single/return, eligibility of access, basic usage conditions such as  validity period/operator/time of travel/interchanging, standard point to  point fares prices for different point to point pairs including daily and  weekly fares/zonal fare prices/flat fare prices)
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|-
 
|LOS 3-3
 
| Special Fare Products: offers  with additional special conditions such as promotional fares, group fares,  season passes, aggregated products combining different products and add on  products such as parking and travel, minimum stay
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|-
 
|LOS 3-4
 
|Basic commercial conditions such  as refunding/replacing/exchanging/transferring and basic booking conditions  such as purchase windows, validity periods, routing restrictions zonal  sequence fares, minimum stay.
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|-
 
|LOS 3-5
 
|How to pay tolls (incl. retail  channels, fulfilment methods, payment methods)
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|-
 
|LOS 3-6
 
| How to book car sharing, taxis,  cycle hire etc. (incl. retail channels, fulfilment methods, payment methods)
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|-
 
|LOS 3-7
 
|Where how to pay for car  parking, public charging stations for electric vehicles and refuelling points  for CNG/LNG, hydrogen, petrol and diesel powered vehicles (incl. retail  channels, fulfilment methods, payment methods)
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|-
 
|LOS 3-8
 
| Detailed cycle network  attributes (surface quality, side-by-side cycling, shared surface, on/off  road, scenic route, ‘walk only’, turn or access restrictions (e.g. against  flow of traffic)
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|-
 
|LOS 3-9
 
|Parameters needed to calculate  an environmental factor such as carbon per vehicle type or passenger mile or  per distance walked
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|-
 
|LOS 3-10
 
|Parameters such as fuel  consumption needed to calculate cost
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|-
 
|LOS 3-11
 
|Estimated travel times by day  type and time-band by transport mode/combination of transport modes
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|[[File:compliant.png|15px|link=]]
 
|
 
|
 
|
 
|
 
|
 
|
 
|-
 
|
 
!'''Links to the available documentation<ref>https://github.com/nick-knowles/NeTEx/wiki/NationalProfiles</ref>'''
 
|
 
|
 
|
 
|
 
[https://arge-oevv.atlassian.net/wiki/spaces/NET/overview Austrian profile]
 
|
 
|
 
|Denmark implements currently the [https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/728891481/Nordic+NeTEx+Profile Nordic Profile] and the EU profiles
 
|
 
*[http://www.normes-donnees-tc.org/format-dechange/donnees-theoriques/netex/ French Profile]
 
*[http://www.normes-donnees-tc.org/wp-content/uploads/2021/01/Profil-NeTEx-elements-communsF-v2.2.pdf Common Profile]
 
*[http://www.normes-donnees-tc.org/wp-content/uploads/2014/05/NF_Profil_NeTEx_pour_les_arrets-_F-_-_v2.pdf Stop Profile]
 
*[http://www.normes-donnees-tc.org/wp-content/uploads/2019/11/NF_Profil-NeTEx-pour-les-R%C3%A9seauxF-v2.1.pdf Network Profile]
 
*[http://www.normes-donnees-tc.org/wp-content/uploads/2019/11/NF&#x20;Profil-NeTEx-pour-les-HorairesF-v2.1.pdf Timetable Profile]
 
*[http://www.normes-donnees-tc.org/wp-content/uploads/2021/11/NF_Profil-NeTEx-pour-les-TarifsF-v1.2.pdf Fare Profile]
 
*[http://www.normes-donnees-tc.org/wp-content/uploads/2021/10/NF_Profil-NeTEx-pour-les-ParkingsF-v1.2a.pdf Parking Profile]
 
*[http://www.normes-donnees-tc.org/wp-content/uploads/2021/01/Profil-NeTEx-pour-laccessibiliteF-v2.2.pdf Accessibility Profile]
 
|
 
[http://netex-cen.eu/?page_id=237 Italian Profile]
 
|
 
*[https://bison.dova.nu/standaarden/nederlands-netex-profiel Netherlands profile]
 
*[https://bison.dova.nu/sites/default/files/bison_prijzen_producten_en_tarieven_v8.1.3.0_release.pdf Bison Fares]
 
|[https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/728891481/Nordic+NeTEx+Profile Nordic Profile]
 
|
 
[https://ptprofiles.azurewebsites.net/netex-profile Portuguese Profile]
 
|
 
[https://www.nap.si/_resources/profiles/NeTEx_SI_Profile_v2.pdf Slovenian Profile]
 
|
 
[https://transportdatamanagement.ch/en/standards/ Swiss profile - Work In progress]
 
|
 
*[http://netex.uk/farexchange/ UK Profile (FareExchange)]
 
*[http://netex.uk/farexchange/doc/uk_profile/DfT-NeTEx-1-Fares-Intro-2019.06.17-v0.09.pdf Introduction]
 
*[http://netex.uk/farexchange/doc/uk_profile/DfT-NeTEx-2-Base_Spec-2019.06.30-v0.14.pdf Stops and Timetables]
 
*[http://netex.uk/farexchange/doc/uk_profile/DfT-NeTEx-3-Fares_Spec-2019.06.17-v0.17.pdf Fares]
 
|
 
*[http://netex.ie/ Irish Profile]
 
*[http://netex.uk/netexie/doc/EIRE_NP/NTA-NeTEx-1-Spec-2020.08.12-v0.22.pdf Profile Elements]
 
*[http://netex.uk/netexie/doc/EIRE_NP/NTA-NeTEx-2-Mappings-2020.08.06-v0.22.pdf Profile Data Mappings]
 
|
 
[https://www.vdv.de/vdv-462-netex-recommendation-v00-22-english.pdfx VDV462]
 
|}
 
  
 +
--[[User:Anasfou|DATA4PT Team]] ([[User talk:Anasfou|talk]]) 10:28, 06 November 2023 (CEST)
  
If you believe that your use cases are resolved in an existing profile, it is highly recommended to adopt an existing solution and cooperate with the corresponding entity. You will save resources while you will ensure that your profile is interoperable. You can also find contact details for some of the entities responsible for the profiles in the documentation list. Otherwise you can contact us in [https://data4pt-project.eu/requests-requirements/ DATA4PT].
+
== Is it correct to include the data category VehicleType in the TimetableFrame as in the NX-PI-01_LU_NAP_LINE_AVL-AVL-91_20210113.xml EPIP example file? ==
  
=NeTEx software / tools=
+
This example file is available for download under https://data4pt-project.eu/knowledge-database/guidelines/, it includes the data category VehicleType.
General purpose XML tools can be used to work with the NeTEx XML schema and XML documents that conform to it, for example either the proprietary [http://www.altova.com/xmlspy.html XML SPY] , or [http://www.oxygenxml.com/ Oxygen] or see free tools at http://www.garshol.priv.no/download/xmltools/. A wide variety of mainstream XML tools are available to validate XML and to create bindings to specific programming languages (.NET, Java, PHP, C++).<ref>http://netex-cen.eu/?page_id=258</ref>
+
Yes, the European Passenger Information Profile, CEN/TS 16614-4:2020,(EPIP) states that the data category VehicleType can be provided in the TimetableFrame. See table 131 – TypeOfFrame: EU_PI_TIMETABLE in the documentation.
  
To look at the design models, an interactive UML viewer such as [http://www.sparxsystems.com/ Enterprise Architect] is extremely helpful, although a set of static web pages is also available. Sample mappings to a variety of national formats (VDV, BISON, etc) as well as GTFS have been developed and are included in the NeTEx standard.<ref>http://netex-cen.eu/?page_id=258</ref>
+
--[[User:Anasfou|DATA4PT Team]] ([[User talk:Anasfou|talk]]) 19:50, 19 May 2022 (CEST)
  
The following list of software is known to support NeTEx. We distinguish between different categories that may later receive a list of key performance indicators.
+
== Are there other possibilities where to define the vehicle type? ==
  
==Conversion of NeTEx between other formats==
+
Yes, the European Passenger Information Profile, CEN/TS 16614-4:2020,(EPIP) actually also allows, as an option, that the data category VehicleType is instead provided in the ResourceFrame. See table Table 127 TypeOfFrame: EU_PI_COMMON in the documentation. This second option is now (2021-02-24) also supported in the set of XSD-files available for download from the project website.
{| class="wikitable"
 
! colspan="1" | Name
 
! colspan="1" |Availability
 
! colspan="1" |Description
 
! colspan="1" |Profile
 
! colspan="1" |License
 
! colspan="1" |URL
 
|-
 
! rowspan="1" style="text-align:left;" |[[netex-protobuf]]
 
|Available
 
|NeTEx to protobuf converter
 
|all
 
|EUPL
 
|https://github.com/entur/netex-protobuf
 
|-
 
! rowspan="1" style="text-align:left;" |[[gtfs2netexfr]]
 
|Available
 
| Export GTFS data to NeTEx.
 
|French
 
|
 
|https://github.com/CanalTP/transit_model/tree/master/gtfs2netexfr
 
|-
 
! rowspan="1" style="text-align:left;" |[[hastus]]
 
|Available
 
|Giro Hastus OIG script to export NeTEx from a system, in addition can export crew operations.
 
|Dutch, Nordic(?)
 
|AGPL-3.0
 
|https://github.com/skinkie/hastus
 
|-
 
! rowspan="1" style="text-align:left;" |[[josm-plugin-netex-converter]]
 
|Available
 
|Export OpenStreetMap pedestrian routing information into NeTEx.
 
|
 
| GPL 2.0
 
|https://gitlab.com/labiangashi/josm-plugin-netex-converter/
 
|-
 
! rowspan="1" style="text-align:left;" |[[netex-gtfs-converter-java]]
 
|Available
 
|Export NeTEx data to GTFS
 
|Nordic
 
|EUPL
 
|https://github.com/entur/netex-gtfs-converter-java
 
|-
 
!Chimera
 
|Available
 
|Chimera is a framework for semantic data transformation pipelines. A converter between GTFS and NeTEx has been implemented adopting an intermediate Transmodel representation.
 
|Nordic (ready), EPIP/Italian (ongoing)
 
|Framework Apache License 2.0, Mapping GTFS-NeTEx – Proprietary license
 
|Framework – https://github.com/cefriel/chimera
 
Mapping GTFS-NeTEx – https://snap-project.eu/
 
|-
 
!'''OpenMove ATLAS'''
 
|Available
 
|The management platform OpenMove ATLAS allows import and editing of data in GTFS format and export also in GTFS or NeTEx format (currently the Italian Profile is supported, other profiles can be implemented on request).
 
|EPIP
 
Italian
 
|Proprietary license
 
|https://www.openmove.com/
 
|-
 
!'''GTFS2NeTEx-converter'''
 
|Available
 
|Converts GTFS data in NeTEx Italian Profile.
 
|EPIP
 
Italian
 
|Proprietary License
 
|Work in Progress
 
|-
 
|}
 
  
==Data Validation tools==
+
--[[User:Anasfou|DATA4PT Team]] ([[User talk:Anasfou|talk]]) 19:50, 19 May 2022 (CEST)
{| class="wikitable"
 
! colspan="1" |Name
 
! colspan="1" |Availability
 
! colspan="1" | Description
 
! colspan="1" |Profile
 
! colspan="1" |License
 
! colspan="1" |URL
 
|-
 
! rowspan="1" style="text-align:left;" |[[XMLlint]]
 
|Available
 
|XML syntax validation, XSD schema validation and constraint checking.
 
|All
 
|MIT
 
|http://www.xmlsoft.org/
 
|-
 
|}
 
  
==Language bindings and software development aids==
+
== How to manage translations with "MultilingualString" in NeTex? ==
{| class="wikitable"
+
There are a lot of MultilingualString in NeTEx. All implementions use them. It may be slightly different depending on the language (Java, C/C++, Ruby, Go, Python, etc.) and also on the use case (e.g. there are translations available to be used).
! colspan="6" |NeTEx XML bindings
 
|-
 
! colspan="1" |Name
 
! colspan="1" |Availability
 
! colspan="1" |Description
 
! colspan="1" | Profile
 
! colspan="1" |License
 
! colspan="1" |URL
 
|-
 
! rowspan="1" style="text-align:left;" |[[netex-java-model]]
 
| Available
 
|NeTEx XML bindings for Java, with additions to map temporal types to native objects.
 
|Any
 
|EUPL
 
|https://github.com/entur/netex-java-model
 
|-
 
! rowspan="1" style="text-align:left;" |[[netex-csharp-model]]
 
|Not Available
 
|NeTEx XML bindings for C#. Currently being researched with a variety of tools.<br>Contact DATA4PT if you have questions or have found the golden egg.
 
|Any
 
|
 
|
 
|-
 
! rowspan="1" style="text-align:left;" |[[netex-parser-java]]
 
|Available
 
|Parse NeTEx files and lookup entities in an index
 
|Nordic
 
|EUPL
 
|https://github.com/entur/netex-parser-java
 
|-
 
|}
 
  
==Editing /Management  & visualisation tools for NeTEx data==
+
Furthermore, for translations, AlternativeTexts are expected to be used (they do contain MultilingualString but also some more information as presented in the following schema).
{| class="wikitable"
 
! colspan="1" |Name
 
! colspan="1" |Availability
 
! colspan="1" |Description
 
! colspan="1" |Profile
 
! colspan="1" |License
 
! colspan="1" | URL
 
|-
 
! rowspan="1" style="text-align:left;" |[[Chouette|Nplan]]
 
|Available
 
|Java backend / TypeScript frontend for create/edit/export of NeTEx data (Support both Timetable based and On-demand polygon based services)
 
|Nordic
 
|EUPL
 
|backend - https://github.com/entur/uttu
 
frontend - https://github.com/entur/enki
 
|-
 
! rowspan="1" style="text-align:left;" |[[NSR]]
 
| Available
 
|Java backend / JavaScript frontend for import/creation/edit/export for NeTEx stops data. (Act as a National Stops Register for the whole of Norway)
 
|Nordic
 
|EUPL
 
|backend - https://github.com/entur/tiamat
 
frontend - https://github.com/entur/abzu
 
|-
 
! rowspan="1" style="text-align:left;" |[[Chouette]]
 
|Available
 
|Java backend / Ruby frontend for import/validation/edit/export of NeTEx data. Highly modified version of the old AFIMB version of Chouette. NOTE: Legacy software not recommended for new implemetations
 
|Nordic
 
|CeCILL-B
 
|backend - https://github.com/entur/chouette
 
frontend -  https://github.com/entur/chouette2
 
|-
 
! rowspan="1" style="text-align:left;" |[[Chouette]]
 
|Available
 
|Java based NeTEx tools, transforms between profiles and standards (NeTEx, GTFS, Neptune).
 
|EPIP
 
|Apache 2.0
 
|https://enroute.mobi/produits/chouette/
 
|-
 
! rowspan="1" style="text-align:left;" |[[mobilitx]]
 
| Available
 
|
 
|
 
|
 
|https://mobilitx.diginext.fr/
 
|-
 
! rowspan="1" style="text-align:left;" |[[mobiref]]
 
|Available
 
|
 
|
 
|
 
|https://www.lumiplan.com/produit/mobiref/
 
|-
 
! rowspan="1" style="text-align:left;" |[[NeTEx Reader]]
 
| In Development
 
|C# based XML tool, based on Giro Hastus XSD.
 
|Dutch
 
|
 
|https://www.youtube.com/watch?v=mpb_1Y9uR5k
 
|-
 
! rowspan="1" style="text-align:left;" |[[netexconv2]]
 
|In Development
 
|Java based NeTEx tools, transforms between profiles and standards (NeTEx, DINO, HAFAS, KV1, GTFS).
 
|Dutch, EPIP, Nordic, VDV462
 
|
 
|
 
|-
 
! rowspan="1" style="text-align:left;" |[[IVU.cloud]]
 
|Available
 
|
 
|EPIP
 
|
 
|https://www.ivu.com/news/news/article/delfi-successfully-migrates-to-ivucloud.html
 
|-
 
! rowspan="1" style="text-align:left;" |[[Motus]]
 
|Available
 
|Motus is the Fleet Scheduling Management System provided by Pluservice. The application is designed by independent and integrated modules which can be activated according to specific operational needs.  
 
  
One of the latest module created and already available is the generation of NeTEx datasets starting from the operational data collected by public transport operators. For this purpose, Motus receives the input data starting from a GTFS and it is able to enrich  these data with further relevant information such as contracts, vehicles. Then Motus transforms these data into the NeTEx Italian profile.  
+
https://data4pt.org/w/images/2/2a/MultilingualString.png
  
'''Data model:''' the database is designed according to Transmodel specifications, European reference standard (EN12896) for public  transport.
+
Also note that an object can have multiple names (not translations but different possible naming): in such case AlternativeNames should be considered.
|Italian
 
|
 
|https://www.pluservice.net/it/soluzioni/gestione-rete-e-turni
 
|-
 
|}
 
  
==NeTEx data enabled==
+
An xml example (EPIP example file), where MultilingualString attributes (lang) are used is available in the DATA4PT knowledge database.
{| class="wikitable"
 
! colspan="1" |Name
 
! colspan="1" |Availability
 
! colspan="1" | Description
 
! colspan="1" |Profile
 
! colspan="1" |License
 
! colspan="1" |URL
 
|-
 
! rowspan="1" style="text-align:left;" |[[OpenTripPlanner]]
 
| Available
 
|Timetable and shortest path journey planner supporting reading various input formats including GTFS and NeTEx.
 
| Nordic
 
| Apache 2.0
 
|http://docs.opentripplanner.org/en/dev-2.x/Netex-Norway/
 
|-
 
|}
 
  
==Planning system supporting native NeTEx export ==
+
To check your data sets, you may use EPIP adapted XML-schema. The graphic documentation of the EPIP NeTEx XSD, including MultilingualString description is available here .
{| class="wikitable"
 
!Name
 
!Availability
 
!Description
 
!Profile
 
|-
 
! rowspan="1" style="text-align:left;" |[[Hastus]]
 
|Available
 
|Planning system from Giro for public transport
 
| Nordic
 
|-
 
! rowspan="1" style="text-align:left;" |[[Trapeze Cloud TP10|Trapeze]]
 
|Available
 
|Planning system from Trapeze for public transport
 
|Nordic
 
|-
 
! rowspan="1" style="text-align:left;" |[[DG Buss]]
 
|Available
 
|Planning system from Datagrafikk for public transport
 
|Nordic
 
|-
 
! rowspan="1" style="text-align:left;" |[[Train Plan]]
 
|Available
 
|Planning system from Trapeze for railway
 
|Nordic
 
|-
 
! rowspan="1" style="text-align:left;" |[[IVU]]
 
|In development
 
|Planning system from IVU for public transport
 
|Nordic
 
|-
 
! rowspan="1" style="text-align:left;" |[[IVU]]
 
|In development
 
|Planning system from IVU for railway
 
|Nordic
 
|-
 
! rowspan="1" style="text-align:left;" |[[Turnit]]
 
|Available
 
|Planning system from Turnit for public transport
 
|Nordic
 
|-
 
! rowspan="1" style="text-align:left;" |[[Nplan]]
 
|Available
 
|Planning system from Entur for public transport
 
|Nordic
 
|-
 
! rowspan="1" style="text-align:left;" |[[TPSI]]
 
|Available
 
|Planning system from HaCon for railway
 
|Nordic
 
|}
 
  
= NeTEx Part 5 for New Modes =
 
The NeTEx extension for New Modes addresses the development of a data exchange format dedicated to the publication of data concerning ‘Alternative Modes’ (as requested in EU COMMISSION DELEGATED REGULATION (EU) 2017/1926 of 31 May 2017). This work will generate NeTEx Part 5 focusing on (but not a limitation to) car sharing, cycle sharing, carpooling, car/cycle rental. It is primarily oriented towards static data (describing the service that is offered and associated infrastructure, more than its current running status). The corresponding real-time information is provided by SIRI. More information can be found in [https://netex-cen.eu/?page_id=534 NeTEx website]. The technical standard is now available by  '''CEN/TS 16614-5:2022 (E).''' 
 
  
Supportive material is already available through different channels (check below).  
+
Generally, NeTEx example files can be found in the main github repository ,  while also other databases with examples are available, (e.g. from ENTUR).
  
== Technical artefacts ==
+
--[[User:Anasfou|DATA4PT Team]] ([[User talk:Anasfou|talk]]) 19:57, 19 May 2022 (CEST)
The XML schema (XSD) for NeTEx Part 5 New Modes is available in [https://github.com/NeTEx-CEN/NeTEx/tree/new-modes GitHub]. In this NeTEx - CEN GitHub channel, examples are also provided, along with other useful documentation.
 
  
== Canonical mapping with GBFS ==
+
== When I try to generate java classes, Ι have a duplication class error. Is it necessary to have those 2 types: vehicleJourneyStopAssignmentsInFrame_RelStructure and VehicleJourneyStopAssignmentsInFrame_RelStructure? ==
Preceding the publication of the extension of the Network Timetable Exchange (NeTEx) for ‘new modes’, the EU-funded project DATA4PT and MobilityData experts release the high-level mapping between the General Bikeshare Feed Specification (GBFS) and Transmodel in order to support better interoperability of shared mobility data feeds. The mapping report is available [[index.php?title=Media:Canonical mapping - NeTEx and SIRI new modes with GBFS.pdf|here]]. 
 
  
= References =
+
It should be only one branch vehicleJourneyStopAssignmentsInFrame_RelStructure. Maybe the second is in a "dead file". Please check https://github.com/NeTEx-CEN/NeTEx/blob/master/xsd/netex_part_2/part2_journeyTimes/netex_vehicleJourney_version.xsd).
<references />
+
 
 +
In general, regarding java classes, you may check ENTUR recommendations available here https://github.com/entur/netex-java-model.
 +
 
 +
--[[User:Anasfou|DATA4PT Team]] ([[User talk:Anasfou|talk]]) 20:03, 19 May 2022 (CEST)
 +
 
 +
== How to use "keylist" to express secondary identifiers for network? ==
 +
 
 +
The element ''keylist'' and child element ''KeyValue'' is the right way to add secondary identifiers for a network. The ''keylist'' element should be positioned before ''PrivateCode''. For example:
 +
  <Network version="any" changed="2022-06-10T09:30:36Z" id="FR1:Network:1045:LOC">
 +
    <keyList>
 +
      <KeyValue typeOfKey="ALTERNATE_IDENTIFIER">
 +
        <Key>NETWORK_SAE</Key>
 +
        <Value>456</Value>
 +
      </KeyValue>
 +
    </keyList>
 +
    <PrivateCode>123</PrivateCode>
 +
  </Network>
 +
 
 +
--[[User:Anasfou|DATA4PT Team]] ([[User talk:Anasfou|talk]]) 18:47, 11 June 2022 (CEST)
 +
 
 +
== Is there a way to express in NeTEx and/or SIRI that the information of provided occupancy level of a public transport vehicle is based on a prognosis (e.g. historical data) or real-time measured data? ==
 +
 
 +
SIRI VM (vehicle monitoring service) and SIRI SM (stop monitoring) already today allow a simple enumeration describing the general Occupancy level for a monitored Vehicle Journey.
 +
In the coming SIRI version (currently under voting process):
 +
- the enumeration value set will be extended and additional values added. Some additional constructions on Call level will also be added.
 +
- SIRI Estimated Timetable (ET) will be extended  with the possibility to exchange passenger count and occupancy information per Call. This will include recorded information as well as estimated values for coming Calls.
 +
The XSD itself is already fully finalised and usable from here https://github.com/SIRI-CEN/SIRI
 +
 
 +
Also, you can find a very relevant document about " Vehicle Occupancy Data" from RTIG (UK trade body for public transport technology stakeholders) here : https://www.rtig.org.uk/system/files/documents/RTIGT039-1.1%20Providing%20Vehicle%20Occupancy%20Data%20-%20Data%20Interfaces.pdf
 +
It includes detailed references to SIRI and NeTEx data structures :
 +
- The NeTEx format includes PassengerCapacity as part of the VehicleType and has a structure that allows for detail - including seated and standing capacities, to be handled
 +
- The Occupancy field in SIRI is one of the optional properties of ProgressInfo of a MonitoredVehicleJourney. This element can be used in both SIRI-SM and SIRI-VM services.
 +
- There is, in addition, an Occupancy field in the EstimatedCall structure of the SIRI-ET service. If this is populated it represents a predicted passenger load. If the corresponding field is filled in a MonitoredVehicleJourney, this should be used in preference - as it reflects the actual current passenger occupancy value.
 +
 
 +
--[[User:Anasfou|DATA4PT Team]] ([[User talk:Anasfou|talk]]) 12:40, 03 August 2022 (CEST)
 +
 
 +
== How different levels of stops of complex stations are expressed in NeTEx EPIP? ==
 +
 
 +
To describe different levels of stops in complex stations, the XSD is adapted as follows:
 +
 
 +
<xsd:complexType name="levels_RelStructure">
 +
    <xsd:sequence>
 +
        <xsd:element ref="Level" maxOccurs="unbounded"/>
 +
    </xsd:sequence>
 +
    <xsd:attributeGroup ref="ModificationSetAttributeGroup"/>
 +
</xsd:complexType>  
 +
 
 +
The updated XSD is available https://data4pt.org/w/index.php?title=NeTEX#NeTEx_EPIP.
 +
--[[User:Anasfou|DATA4PT Team]] ([[User talk:Anasfou|talk]]) 13:32, 3 August 2022 (CEST)
 +
 
 +
== How to differentiate a basic JourneyPattern from one that takes into account re-routings due to planned deviations? ==
 +
 
 +
For planned deviations, another version of JourneyPattern needs to be described having different validity conditions than the regular JourneyPattern. For deviations that occur the same day of the operation, SIRI Estimated Timetable (ET) can be used, and for deviations known some days before the operational day, SIRI Production Timetable (PT) can be used.
 +
 
 +
Moreover, there is today no element in the XSD that states if a JourneyPattern is "normal" or "diversion".
 +
This means that you would probably need to analyse the timetable over a longer period of time and compare how often different JourneyPatterns (or versions of a certain JourneyPattern) are actually used on a certain Direction to find which is the "normal" one.
 +
 
 +
--[[User:Anasfou|DATA4PT Team]] ([[User talk:Anasfou|talk]]) 19:16, 9 September 2022 (CEST)
 +
 
 +
== Where can I find the UML model for NeTEX? ==
 +
 
 +
The UML of NeTEx is available https://www.netex-cen.eu/model/conceptual/part1/index.htm. NeTEx is based on data model Transmodel, of which the UML is available in Enterprise Architect file https://www.transmodel-cen.eu/model/. This version corresponds to the CEN v6.0 release c2018, with revisions from 2021. For more information regarding the data model (Transmodel) please check here https://www.transmodel-cen.eu/downloads/. Updates on the Transmodel UML are expected in the coming period.
 +
 
 +
--[[User:Anasfou|DATA4PT Team]] ([[User talk:Anasfou|talk]]) 16:08, 22 September 2022 (CEST)
 +
 
 +
== Where can I find information about how and when NeTEx is going to be able to store data about: taxi services, rent of vehicles (with or without driver), parking areas (the classical one, for private cars etc.), low emission zones in cities?  ==
 +
 
 +
TRANSMODEL Part 10 and NeTEx Part 5 (Alternative Modes API) are relevant to the referred functional scope except of low emission zones. In particular, NeTEx Part 5, covers all alternative modes: Vehicle Sharing (any kind of vehicle, car, bike, scooter etc.), Vehicle Pooling (any kind of vehicle, car, van etc.), Transport Network Companies, Renting, Taxis.
 +
 
 +
NeTEx also includes mobilityServiceConstraintZones that can be applied to any public transport and new mode services and be a restriction for certain types of vehicles. However this needs to be connected to some services, since NeTEx and Transmodel are not describing the private vehicle use (except for carpooling where there is a public offer on the private vehicle). So, there is no explicit description of Low Emission Zones, where the limitation is triggered by a pollution level. Possible enhancement can be considered.
 +
 
 +
NeTEx Part 5 (CEN/TS 16614-5) is complementary to the previous parts (1/2/3/4). It is fully aligned with the new Transmodel Part 10, being the underlaying data model.
 +
Transmodel extension published as CEN TS 17413:2019. The conversion of CEN TS 17413:2019 into an EN is going to be the Transmodel -Part 10. General information about NeTEx Part 5 is available here http://netex-cen.eu/wp-content/uploads/2021/03/NeTEx-extension-for-New-Modes-Detailed-Scope-v04.pdf. The specifications are also now published by CEN.
 +
 
 +
Besides the CEN documentation, the users (IT suppliers/operators,  in general developers etc.) can have access to the technical artefacts (XSD) through the publicly available repository in GitHub (check https://data4pt.org/w/index.php?title=NeTEX#NeTEx_Part_5_for_New_Modes). In addition, there is an available mapping-comparison with GBFS, the bike sharing data format from Mobility Data https://data4pt.org/w/index.php?title=NeTEX#Canonical_mapping_with_GBFS.
 +
 
 +
Since NeTEx is about scheduled data (including location of parking places, capacity etc.), is complemented by SIRI for realtime data. Therefore, SIRI has also been extended (recently voted) to cover new modes (vehicles availability, parking places availability etc.). This extension is in SIRI Part 4 (Facility Monitoring).
 +
In particular for parking, there is a comprehensive description in NeTEx. France for example has already a dedicated profile for parking – the documentation in french is available here http://www.normes-donnees-tc.org/wp-content/uploads/2021/10/NF_Profil-NeTEx-pour-les-ParkingsF-v1.2a.pdf ).
 +
 
 +
--[[User:Anasfou|DATA4PT Team]] ([[User talk:Anasfou|talk]]) 16:28, 22 September 2022 (CEST)
 +
 
 +
== How to manage codespaces in NeTEx where unique identifiers are needed? ==
 +
 
 +
In NeTEx a rule to code IDs is included to ease uniqueness (Europe wide) and stability of IDs.
 +
 
 +
 
 +
[[File:1.jpg|thumb]]
 +
 
 +
For example in Italy, they applied this rule, using NUTS code for country-code and local-code.
 +
 
 +
<ServiceCalendarFrame id="epd:IT:ITC1:ServiceCalendarFrame_EU_PI_CALENDAR:scf" version="any">
 +
<TypeOfFrameRef versionRef="any" ref="epip:EU_PI_CALENDAR"/>
 +
<ServiceCalendar id="IT:ITC1:ServiceCalendar:C01" version="any">
 +
<dayTypes>
 +
<DayType id="IT:ITC1:DayType:5:dt:A" version="any">
 +
 
 +
Any other rule can be accepted provided that IDs are unique and stable. Using operator's code inside an ID is not suggested as the Operator can change. With the NeTEx recommended rule, even if the Operator changes, the ID will have to remain the same, ignoring that change. Also the Operator code may not be a good choice for the uniqueness of shared lines or shared stops.
 +
 
 +
--[[User:Anasfou|DATA4PT Team]] ([[User talk:Anasfou|talk]]) 10:04, 05 October 2022 (CEST)
 +
 
 +
 
 +
== How to describe two similar stops sequences when the one has a boarding and alighting information and the other has not? ==
 +
 
 +
One ROUTE is enough, it can cover two different JOURNEY PATTERNS if the vehicle will traverse the same physical path in both cases. The relation between ROUTE POINT and SCHEDULED STOP POINT is formally through projection.
 +
 
 +
 
 +
--[[User:Anasfou|DATA4PT Team]] ([[User talk:Anasfou|talk]]) 11:12, 2 November 2022 (CET)
 +
 
 +
== Should "RouteLink" have a unique identifier? ==
 +
 
 +
Each unique RouteLink should have a unique identifier (id-attribute).
 +
Note that a RouteLink over time may be altered and still retain its original identifier, but  each modification should have a different version-attribute.
 +
 
 +
At the same time it is OK to refer to the same RouteLink in relation to different Lines, if those Lines include a shared physical path for some part of the respective routes. This applies also if the Lines are provided in separate files.
 +
 
 +
--[[User:Anasfou|DATA4PT Team]] ([[User talk:Anasfou|talk]]) 15:44, 12 January 2023 (CET)
 +
 
 +
== What is the difference between stopAreas, Quays, stopPlaces? ==
 +
 
 +
 
 +
A STOP AREA is "A group of SCHEDULED STOP POINTs close to each other." so it definitely does not correspond to the quays and stopPlaces of the IFOPT base.
 +
 
 +
Having a scheduledStopPoint belonging a a single journeyPattern, however this does go via the StopPointInJourneyPattern which is allowing multiple reuse of the same scheduledStopPoint. A scheduledStopPoint can be assigned to StopPlace or Quays thanks to the PassengerStopAssignment.
 +
[[File:Stop assignment model.png|thumb]]
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
--[[User:Anasfou|DATA4PT Team]] ([[User talk:Anasfou|talk]]) 11:50, 3 May 2023 (CET)
 +
== How to model a transport ticket that costs 6 euros on the 1st day and 3 euros for each additional day? ==
 +
 
 +
This is a typical case of pricing of a SALES OFFER PACKAGEs: several such packages may exist composed of 1, 2,…n elements and a specific price is provided according to the number of the SALES OFFER PACKAGE ELEMENTS in the SALES OFFER PACKAGE.
 +
 
 +
So for this particular example:
 +
The PRICE of the SALES OFFER PACKAGE composed of one SALES OFFER PACKAGE ELEMENT is 6 euros.
 +
The price of the SALES OFFER PACKAGE composed of 2…n SALES OFFER PACKAGE ELEMENTs is 6 + (n-1)*3 euros.
 +
 
 +
You may consider a PREASSIGNED FARE PRODUCT (e.g. a day pass) which is provided by one or more SALES OFFER PACKAGE ELEMENTs. Access rights may correspond to a PREASSIGNED FARE PRODUCT but also other types of access right might be granted by a SALES OFFER PACKAGE ELEMENT.
 +
 
 +
Moreover, the definition of TimeIntervals  is related to the description of the time-related fare structure elements  (for example the use of the network during 1 hour would represent a SALES OFFER PACKAGE ELEMENT A - 1 hour pass, the use of the network during 5 hours represent a SALES OFFER PACKAGE ELEMENT B - 5 hours pass). In the present example, the fare structure elements are identical (use of the network during one day several times). So only the pricing differs according to the number of products purchased. TimeInterval will be rather suitable to the pricing of a single trip (DayOffset are only there because some long distance trips can exceed the day).
 +
 
 +
[[File:Stop assignment model.png|thumb]]
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
--[[User:Anasfou|DATA4PT Team]] ([[User talk:Anasfou|talk]]) 11:13, 1 September 2023 (CET)
 +
== How to model "hail and ride" section? ==
 +
Hail and ride usually is modelled by using a FlexibleStopPlace that can refer to HailAndRide areas as shown in the UML diagrams below. Hail and Ride is described in CEN TS 16614-1. Examples can be found in [https://github.com/NeTEx-CEN/NeTEx/tree/master/examples NeTEx-CEN GitHub] like this [https://github.com/NeTEx-CEN/NeTEx/blob/master/examples/functions/timetable/Netex_01.4_Bus_SimpleTimetable_WithConnection.xml one].
 +
 
 +
[[File:FlexibleStopPlace with HailandRideArea.png|thumb|UML diagram of FlexibleStopPlace with HailAndRide]]
 +
 
 +
 
 +
[[File:HailAndRide.png|thumb|364x364px]]
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
--[[User:Anasfou|DATA4PT Team]] ([[User talk:Anasfou|talk]]) 16:40, 17 October 2023 (CET)
 +
 
 +
== How to start implementing NeTEx Part 5 for new modes (vehicle sharing, rental, taxis etc.)? ==
 +
Simple steps for new users/implementers of NeTEx Part 5: 
 +
 
 +
1) Watch the introduction webinar for NeTEx Part 5, available on [https://data4pt-project.eu/knowledge-database/training-material/ DATA4PT website] under the title “DATA4PT webinar 24 November 2022: NeTEx and SIRI standards for new modes” (direct link to the [https://www.youtube.com/watch?v=F_lK1mfKgbk video] and presentation of the [https://data4pt-project.eu/wp-content/uploads/2022/12/DATA4PT-NeTEx-validation-tool-webinar_Presentation.pdf webinar]).
 +
 
 +
2) Read the pdf – official CEN documentation CEN/TS 16614-5 (where also some examples are given). The document can be bought from any national standardization body.
 +
 
 +
3) Use XML editor (there are commercial tools or free tools - a short list is available by [https://data4pt.org/w/index.php?title=NeTEX#Software_.26_tools_.F0.9F.A7.B0 DATA4PT wiki]), to check the [https://github.com/NeTEx-CEN/NeTEx/tree/master/xsd/netex_part_5 XSD for Part 5]  and check the [https://github.com/NeTEx-CEN/NeTEx/tree/master/examples/functions/newModes examples] from [https://github.com/NeTEx-CEN/NeTEx/tree/master Github NeTEx repository].
 +
 
 +
4) Create your own .xml examples based on the XSD and the examples available in GitHub. If the user has no technical background, then IT tool provider is needed to support him/her following the same steps. A general list of tools is available in [https://data4pt.org/w/index.php?title=NeTEX#Software_.26_tools_.F0.9F.A7.B0 DATA4PT wiki.]   
 +
 
 +
5) Validate the example with the XML editor and the Greenlight validator https://greenlight.itxpt.eu/. The latter is the tool that provides feedback both on errors that concern the NeTEx XSD but also the content (plausibility checks). More artefacts about the tool where customisation of the rules is possible is available in [https://github.com/ITxPT/DATA4PTTools /ITxPT/DATA4PTTools]  GitHUb repository. 
 +
 
 +
6) Use the [https://data4pt-project.eu/requests-requirements/ DATA4PT helpdesk] for more technical guidance.     
 +
 
 +
Finally, a useful material for small operators that they use already GBFS is:
 +
 
 +
-the canonical mapping between GBFS and NeTEx/SIRI to get their head around the fields/attributes they need at a quick glance
 +
 
 +
- the .xml example that is GBFS-based from the NeTEx GitHub repo.
 +
 
 +
Relevant material is available [https://data4pt.org/w/index.php?title=NeTEX#NeTEx_part_5_for_.F0.9F.86.95_modes here]
 +
 
 +
 
 +
--[[User:Anasfou|DATA4PT Team]] ([[User talk:Anasfou|talk]]) 10:45, 6 November 2023 (CET)
 +
 
 +
 
 +
 
 +
== How to implement DayTypeAssignment in NeTEx? Using OperatingPeriodRef or UicOperatingPeriodRef? ==
 +
 
 +
Both "OperatingPeriodRef" and "UicOperatingPeriodRef" are in the same substitutionGroup named OperatingPeriods, therefore both options may be used without impacting the interoperability of the file. UicOperatingPeriodRef is probably cleaner to reference a UicOperatingPeriod.In NeTEx EPIP (European Passenger Information Profile) UicOperatingPeriod is mandatory (providing the ValidDayBits is mandatory).
 +
[[File:Image.png|thumb]]
 +
 
 +
 
 +
 
 +
 
 +
--[[User:Anasfou|DATA4PT Team]] ([[User talk:Anasfou|talk]]) 12:18, 16 February 2024 (CET)
 +
 
 +
== Does a scheduledStopPoint ID need to be unique per public transport Line?  ==
 +
 
 +
A scheduledStopPoint ID does not need to be unique per Line.
 +
In situations where several Lines use the exact same stop point they may refer to this same stop point using the same scheduledStopPoint ID. If there is a unique ID for the exact same stop that can be used globally it is also ideal from interoperability point of view.
 +
 
 +
More precisely, based on NeTEx terminology, a LINE is defined as "A group of ROUTEs which is generally known to the public by a similar name or number."
 +
A ROUTE is defined as "An ordered list of located POINTs defining one single path through the road (or rail) network. A ROUTE may pass through the same POINT more than once."
 +
JOURNEY PATTERN, defined as "An ordered list of SCHEDULED STOP POINTs and TIMING POINTs on a single ROUTE, describing the pattern of working for public transport vehicles. A JOURNEY PATTERN may pass through the same POINT more than once. The first point of a JOURNEY PATTERN is the origin. The last point is the destination."
 +
 
 +
In order not to make confusion, when parsing the XML input, the data user needs to sufficiently preserving awareness of the context in which the scheduledStopPoint ID is being used. With a correct awareness of the context, the ID can be augmented, for example via a composite ID made up of Line plus stop IDs. This would make different occurrences of the same stop have different IDs, without breaking the NeTEx rules.
 +
 
 +
 
 +
 
 +
--[[User:Anasfou|DATA4PT Team]] ([[User talk:Anasfou|talk]]) 17:38, 25 March 2024 (CET)

Latest revision as of 17:39, 25 March 2024

How do you create C# classes from the NeTEx XSD?

It is possible to create C# classes in different ways.

There are many tools out there, but for instance, you could use the Microsoft xsd.exe tool or the mganss/XMLSchemaClassGenerator tool available on Github at https://github.com/mganss/XmlSchemaClassGenerator

Currently there are some issues if you try to use the official NeTEx XSD as a starting point with either of these tools.

However, the above-mentioned tools work fine if you use them together with an adapted set of XSD-files available from Data4PT. The file set is designed to be compatible with the official NeTEx XSD and to cover many important use cases. It does however not cover all use cases possible with the official schema. There is an interactive graphical presentation of the adapted and reduced XSD available at https://data4pt.org/NeTEx/GraphicKit/Documention_of_reduced_XSD.html

If you wish to try out this reduced XSD, you can download it at https://data4pt.org/NeTEx/GraphicKit/XSD_reduced.zip

The work steps if you are using the Microsoft tool are:

Get the zipped XSD. Extract the ZIP to a folder. Make sure that you have a recent version of the xsd.exe. It is part of the .NET Framework Developer Pack and can be downloaded from https://dotnet.microsoft.com/download/dotnet-framework Install the developer pack. The xsd.exe will be placed in a folder with a path similar to C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools Open a command prompt in the same folder as where the NeTEx_publication_reduced-NoConstraint.xsd resides. Execute the following command (you may have to adapt the path to xsd.exe): "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\xsd.exe"/c/language:C# gml_combo_v3_2_1_simplified.xsd NeTEx_publication_reduced-NoConstraint.xsd The work steps if you are using the MGANSS tool are:

  • Get the zipped XSD. Extract the ZIP to a folder.
  • Download and extract the binary from https://github.com/mganss/XmlSchemaClassGenerator/releases to a separate folder e.g. C:\MGANSS.
  • Open a command prompt in the same folder as where the NeTEx_publication_reduced-NoConstraint.xsd resides.
  • Execute the following command (you may have to adapt the path to the exe):

C:\MGANSS\XmlSchemaClassGenerator.Console.exe NeTEx_publication_reduced-NoConstraint.xsd -n http://www.opengis.net/gml/3.2=gml-v

--DATA4PT Team (talk) 19:41, 19 May 2022 (CEST)

Is it possible to get access to the fares/schedule data?

Yes, the part 3 of NeTEx is fully dedicated to fares and works for all modes of public transport (bus, trains, trams, flexible modes, etc.).

There is a set of white papers describing NeTEx (http://netex-cen.eu/?page_id=14) and one is dedicated to fares: http://netex-cen.eu/wp-content/uploads/2015/12/10.NeTEx-Fare-WhitePaper_1.04.pdf

Fares can be quite big topic and people defining them have a lot of imagination. This resulted in NeTex Part 3 being quite big and it is strongly advised to use only a small subset of it which is relevant to your needs. This what we call a Profile. France, Nordic countries, and UK have a fares national profiles. Information about current national profiles is about existing profiles is available here. A minimum European profile is currently under specification with the support of DATA4PT and it is planned to be delivered to CEN processes by end of June 2024.

--DATA4PT Team (talk) 10:28, 06 November 2023 (CEST)

Is it correct to include the data category VehicleType in the TimetableFrame as in the NX-PI-01_LU_NAP_LINE_AVL-AVL-91_20210113.xml EPIP example file?

This example file is available for download under https://data4pt-project.eu/knowledge-database/guidelines/, it includes the data category VehicleType. Yes, the European Passenger Information Profile, CEN/TS 16614-4:2020,(EPIP) states that the data category VehicleType can be provided in the TimetableFrame. See table 131 – TypeOfFrame: EU_PI_TIMETABLE in the documentation.

--DATA4PT Team (talk) 19:50, 19 May 2022 (CEST)

Are there other possibilities where to define the vehicle type?

Yes, the European Passenger Information Profile, CEN/TS 16614-4:2020,(EPIP) actually also allows, as an option, that the data category VehicleType is instead provided in the ResourceFrame. See table Table 127 – TypeOfFrame: EU_PI_COMMON in the documentation. This second option is now (2021-02-24) also supported in the set of XSD-files available for download from the project website.

--DATA4PT Team (talk) 19:50, 19 May 2022 (CEST)

How to manage translations with "MultilingualString" in NeTex?

There are a lot of MultilingualString in NeTEx. All implementions use them. It may be slightly different depending on the language (Java, C/C++, Ruby, Go, Python, etc.) and also on the use case (e.g. there are translations available to be used).

Furthermore, for translations, AlternativeTexts are expected to be used (they do contain MultilingualString but also some more information as presented in the following schema).

https://data4pt.org/w/images/2/2a/MultilingualString.png

Also note that an object can have multiple names (not translations but different possible naming): in such case AlternativeNames should be considered.

An xml example (EPIP example file), where MultilingualString attributes (lang) are used is available in the DATA4PT knowledge database.

To check your data sets, you may use EPIP adapted XML-schema. The graphic documentation of the EPIP NeTEx XSD, including MultilingualString description is available here .


Generally, NeTEx example files can be found in the main github repository , while also other databases with examples are available, (e.g. from ENTUR).

--DATA4PT Team (talk) 19:57, 19 May 2022 (CEST)

When I try to generate java classes, Ι have a duplication class error. Is it necessary to have those 2 types: vehicleJourneyStopAssignmentsInFrame_RelStructure and VehicleJourneyStopAssignmentsInFrame_RelStructure?

It should be only one branch vehicleJourneyStopAssignmentsInFrame_RelStructure. Maybe the second is in a "dead file". Please check https://github.com/NeTEx-CEN/NeTEx/blob/master/xsd/netex_part_2/part2_journeyTimes/netex_vehicleJourney_version.xsd).

In general, regarding java classes, you may check ENTUR recommendations available here https://github.com/entur/netex-java-model.

--DATA4PT Team (talk) 20:03, 19 May 2022 (CEST)

How to use "keylist" to express secondary identifiers for network?

The element keylist and child element KeyValue is the right way to add secondary identifiers for a network. The keylist element should be positioned before PrivateCode. For example:

 <Network version="any" changed="2022-06-10T09:30:36Z" id="FR1:Network:1045:LOC">
    <keyList>
      <KeyValue typeOfKey="ALTERNATE_IDENTIFIER">
        <Key>NETWORK_SAE</Key>
        <Value>456</Value>
      </KeyValue>
    </keyList>
    <PrivateCode>123</PrivateCode>
 </Network>

--DATA4PT Team (talk) 18:47, 11 June 2022 (CEST)

Is there a way to express in NeTEx and/or SIRI that the information of provided occupancy level of a public transport vehicle is based on a prognosis (e.g. historical data) or real-time measured data?

SIRI VM (vehicle monitoring service) and SIRI SM (stop monitoring) already today allow a simple enumeration describing the general Occupancy level for a monitored Vehicle Journey. In the coming SIRI version (currently under voting process): - the enumeration value set will be extended and additional values added. Some additional constructions on Call level will also be added. - SIRI Estimated Timetable (ET) will be extended with the possibility to exchange passenger count and occupancy information per Call. This will include recorded information as well as estimated values for coming Calls. The XSD itself is already fully finalised and usable from here https://github.com/SIRI-CEN/SIRI

Also, you can find a very relevant document about " Vehicle Occupancy Data" from RTIG (UK trade body for public transport technology stakeholders) here : https://www.rtig.org.uk/system/files/documents/RTIGT039-1.1%20Providing%20Vehicle%20Occupancy%20Data%20-%20Data%20Interfaces.pdf It includes detailed references to SIRI and NeTEx data structures : - The NeTEx format includes PassengerCapacity as part of the VehicleType and has a structure that allows for detail - including seated and standing capacities, to be handled - The Occupancy field in SIRI is one of the optional properties of ProgressInfo of a MonitoredVehicleJourney. This element can be used in both SIRI-SM and SIRI-VM services. - There is, in addition, an Occupancy field in the EstimatedCall structure of the SIRI-ET service. If this is populated it represents a predicted passenger load. If the corresponding field is filled in a MonitoredVehicleJourney, this should be used in preference - as it reflects the actual current passenger occupancy value.

--DATA4PT Team (talk) 12:40, 03 August 2022 (CEST)

How different levels of stops of complex stations are expressed in NeTEx EPIP?

To describe different levels of stops in complex stations, the XSD is adapted as follows:

<xsd:complexType name="levels_RelStructure">

   <xsd:sequence>
       <xsd:element ref="Level" maxOccurs="unbounded"/>
   </xsd:sequence>
   <xsd:attributeGroup ref="ModificationSetAttributeGroup"/>

</xsd:complexType>

The updated XSD is available https://data4pt.org/w/index.php?title=NeTEX#NeTEx_EPIP. --DATA4PT Team (talk) 13:32, 3 August 2022 (CEST)

How to differentiate a basic JourneyPattern from one that takes into account re-routings due to planned deviations?

For planned deviations, another version of JourneyPattern needs to be described having different validity conditions than the regular JourneyPattern. For deviations that occur the same day of the operation, SIRI Estimated Timetable (ET) can be used, and for deviations known some days before the operational day, SIRI Production Timetable (PT) can be used.

Moreover, there is today no element in the XSD that states if a JourneyPattern is "normal" or "diversion". This means that you would probably need to analyse the timetable over a longer period of time and compare how often different JourneyPatterns (or versions of a certain JourneyPattern) are actually used on a certain Direction to find which is the "normal" one.

--DATA4PT Team (talk) 19:16, 9 September 2022 (CEST)

Where can I find the UML model for NeTEX?

The UML of NeTEx is available https://www.netex-cen.eu/model/conceptual/part1/index.htm. NeTEx is based on data model Transmodel, of which the UML is available in Enterprise Architect file https://www.transmodel-cen.eu/model/. This version corresponds to the CEN v6.0 release c2018, with revisions from 2021. For more information regarding the data model (Transmodel) please check here https://www.transmodel-cen.eu/downloads/. Updates on the Transmodel UML are expected in the coming period.

--DATA4PT Team (talk) 16:08, 22 September 2022 (CEST)

Where can I find information about how and when NeTEx is going to be able to store data about: taxi services, rent of vehicles (with or without driver), parking areas (the classical one, for private cars etc.), low emission zones in cities?

TRANSMODEL Part 10 and NeTEx Part 5 (Alternative Modes API) are relevant to the referred functional scope except of low emission zones. In particular, NeTEx Part 5, covers all alternative modes: Vehicle Sharing (any kind of vehicle, car, bike, scooter etc.), Vehicle Pooling (any kind of vehicle, car, van etc.), Transport Network Companies, Renting, Taxis.

NeTEx also includes mobilityServiceConstraintZones that can be applied to any public transport and new mode services and be a restriction for certain types of vehicles. However this needs to be connected to some services, since NeTEx and Transmodel are not describing the private vehicle use (except for carpooling where there is a public offer on the private vehicle). So, there is no explicit description of Low Emission Zones, where the limitation is triggered by a pollution level. Possible enhancement can be considered.

NeTEx Part 5 (CEN/TS 16614-5) is complementary to the previous parts (1/2/3/4). It is fully aligned with the new Transmodel Part 10, being the underlaying data model. Transmodel extension published as CEN TS 17413:2019. The conversion of CEN TS 17413:2019 into an EN is going to be the Transmodel -Part 10. General information about NeTEx Part 5 is available here http://netex-cen.eu/wp-content/uploads/2021/03/NeTEx-extension-for-New-Modes-Detailed-Scope-v04.pdf. The specifications are also now published by CEN.

Besides the CEN documentation, the users (IT suppliers/operators, in general developers etc.) can have access to the technical artefacts (XSD) through the publicly available repository in GitHub (check https://data4pt.org/w/index.php?title=NeTEX#NeTEx_Part_5_for_New_Modes). In addition, there is an available mapping-comparison with GBFS, the bike sharing data format from Mobility Data https://data4pt.org/w/index.php?title=NeTEX#Canonical_mapping_with_GBFS.

Since NeTEx is about scheduled data (including location of parking places, capacity etc.), is complemented by SIRI for realtime data. Therefore, SIRI has also been extended (recently voted) to cover new modes (vehicles availability, parking places availability etc.). This extension is in SIRI Part 4 (Facility Monitoring). In particular for parking, there is a comprehensive description in NeTEx. France for example has already a dedicated profile for parking – the documentation in french is available here http://www.normes-donnees-tc.org/wp-content/uploads/2021/10/NF_Profil-NeTEx-pour-les-ParkingsF-v1.2a.pdf ).

--DATA4PT Team (talk) 16:28, 22 September 2022 (CEST)

How to manage codespaces in NeTEx where unique identifiers are needed?

In NeTEx a rule to code IDs is included to ease uniqueness (Europe wide) and stability of IDs.


1.jpg

For example in Italy, they applied this rule, using NUTS code for country-code and local-code.

<ServiceCalendarFrame id="epd:IT:ITC1:ServiceCalendarFrame_EU_PI_CALENDAR:scf" version="any"> <TypeOfFrameRef versionRef="any" ref="epip:EU_PI_CALENDAR"/> <ServiceCalendar id="IT:ITC1:ServiceCalendar:C01" version="any"> <dayTypes> <DayType id="IT:ITC1:DayType:5:dt:A" version="any">

Any other rule can be accepted provided that IDs are unique and stable. Using operator's code inside an ID is not suggested as the Operator can change. With the NeTEx recommended rule, even if the Operator changes, the ID will have to remain the same, ignoring that change. Also the Operator code may not be a good choice for the uniqueness of shared lines or shared stops.

--DATA4PT Team (talk) 10:04, 05 October 2022 (CEST)


How to describe two similar stops sequences when the one has a boarding and alighting information and the other has not?

One ROUTE is enough, it can cover two different JOURNEY PATTERNS if the vehicle will traverse the same physical path in both cases. The relation between ROUTE POINT and SCHEDULED STOP POINT is formally through projection.


--DATA4PT Team (talk) 11:12, 2 November 2022 (CET)

Should "RouteLink" have a unique identifier?

Each unique RouteLink should have a unique identifier (id-attribute). Note that a RouteLink over time may be altered and still retain its original identifier, but each modification should have a different version-attribute.

At the same time it is OK to refer to the same RouteLink in relation to different Lines, if those Lines include a shared physical path for some part of the respective routes. This applies also if the Lines are provided in separate files.

--DATA4PT Team (talk) 15:44, 12 January 2023 (CET)

What is the difference between stopAreas, Quays, stopPlaces?

A STOP AREA is "A group of SCHEDULED STOP POINTs close to each other." so it definitely does not correspond to the quays and stopPlaces of the IFOPT base.

Having a scheduledStopPoint belonging a a single journeyPattern, however this does go via the StopPointInJourneyPattern which is allowing multiple reuse of the same scheduledStopPoint. A scheduledStopPoint can be assigned to StopPlace or Quays thanks to the PassengerStopAssignment.

Stop assignment model.png







--DATA4PT Team (talk) 11:50, 3 May 2023 (CET)

How to model a transport ticket that costs 6 euros on the 1st day and 3 euros for each additional day?

This is a typical case of pricing of a SALES OFFER PACKAGEs: several such packages may exist composed of 1, 2,…n elements and a specific price is provided according to the number of the SALES OFFER PACKAGE ELEMENTS in the SALES OFFER PACKAGE.

So for this particular example: The PRICE of the SALES OFFER PACKAGE composed of one SALES OFFER PACKAGE ELEMENT is 6 euros. The price of the SALES OFFER PACKAGE composed of 2…n SALES OFFER PACKAGE ELEMENTs is 6 + (n-1)*3 euros.

You may consider a PREASSIGNED FARE PRODUCT (e.g. a day pass) which is provided by one or more SALES OFFER PACKAGE ELEMENTs. Access rights may correspond to a PREASSIGNED FARE PRODUCT but also other types of access right might be granted by a SALES OFFER PACKAGE ELEMENT.

Moreover, the definition of TimeIntervals is related to the description of the time-related fare structure elements (for example the use of the network during 1 hour would represent a SALES OFFER PACKAGE ELEMENT A - 1 hour pass, the use of the network during 5 hours represent a SALES OFFER PACKAGE ELEMENT B - 5 hours pass). In the present example, the fare structure elements are identical (use of the network during one day several times). So only the pricing differs according to the number of products purchased. TimeInterval will be rather suitable to the pricing of a single trip (DayOffset are only there because some long distance trips can exceed the day).

Stop assignment model.png







--DATA4PT Team (talk) 11:13, 1 September 2023 (CET)

How to model "hail and ride" section?

Hail and ride usually is modelled by using a FlexibleStopPlace that can refer to HailAndRide areas as shown in the UML diagrams below. Hail and Ride is described in CEN TS 16614-1. Examples can be found in NeTEx-CEN GitHub like this one.

UML diagram of FlexibleStopPlace with HailAndRide


HailAndRide.png








--DATA4PT Team (talk) 16:40, 17 October 2023 (CET)

How to start implementing NeTEx Part 5 for new modes (vehicle sharing, rental, taxis etc.)?

Simple steps for new users/implementers of NeTEx Part 5:

1) Watch the introduction webinar for NeTEx Part 5, available on DATA4PT website under the title “DATA4PT webinar 24 November 2022: NeTEx and SIRI standards for new modes” (direct link to the video and presentation of the webinar).

2) Read the pdf – official CEN documentation CEN/TS 16614-5 (where also some examples are given). The document can be bought from any national standardization body.

3) Use XML editor (there are commercial tools or free tools - a short list is available by DATA4PT wiki), to check the XSD for Part 5 and check the examples from Github NeTEx repository.

4) Create your own .xml examples based on the XSD and the examples available in GitHub. If the user has no technical background, then IT tool provider is needed to support him/her following the same steps. A general list of tools is available in DATA4PT wiki.

5) Validate the example with the XML editor and the Greenlight validator https://greenlight.itxpt.eu/. The latter is the tool that provides feedback both on errors that concern the NeTEx XSD but also the content (plausibility checks). More artefacts about the tool where customisation of the rules is possible is available in /ITxPT/DATA4PTTools GitHUb repository.

6) Use the DATA4PT helpdesk for more technical guidance.

Finally, a useful material for small operators that they use already GBFS is:

-the canonical mapping between GBFS and NeTEx/SIRI to get their head around the fields/attributes they need at a quick glance

- the .xml example that is GBFS-based from the NeTEx GitHub repo.

Relevant material is available here


--DATA4PT Team (talk) 10:45, 6 November 2023 (CET)


How to implement DayTypeAssignment in NeTEx? Using OperatingPeriodRef or UicOperatingPeriodRef?

Both "OperatingPeriodRef" and "UicOperatingPeriodRef" are in the same substitutionGroup named OperatingPeriods, therefore both options may be used without impacting the interoperability of the file. UicOperatingPeriodRef is probably cleaner to reference a UicOperatingPeriod.In NeTEx EPIP (European Passenger Information Profile) UicOperatingPeriod is mandatory (providing the ValidDayBits is mandatory).

Image.png



--DATA4PT Team (talk) 12:18, 16 February 2024 (CET)

Does a scheduledStopPoint ID need to be unique per public transport Line?

A scheduledStopPoint ID does not need to be unique per Line. In situations where several Lines use the exact same stop point they may refer to this same stop point using the same scheduledStopPoint ID. If there is a unique ID for the exact same stop that can be used globally it is also ideal from interoperability point of view.

More precisely, based on NeTEx terminology, a LINE is defined as "A group of ROUTEs which is generally known to the public by a similar name or number." A ROUTE is defined as "An ordered list of located POINTs defining one single path through the road (or rail) network. A ROUTE may pass through the same POINT more than once." JOURNEY PATTERN, defined as "An ordered list of SCHEDULED STOP POINTs and TIMING POINTs on a single ROUTE, describing the pattern of working for public transport vehicles. A JOURNEY PATTERN may pass through the same POINT more than once. The first point of a JOURNEY PATTERN is the origin. The last point is the destination."

In order not to make confusion, when parsing the XML input, the data user needs to sufficiently preserving awareness of the context in which the scheduledStopPoint ID is being used. With a correct awareness of the context, the ID can be augmented, for example via a composite ID made up of Line plus stop IDs. This would make different occurrences of the same stop have different IDs, without breaking the NeTEx rules.


--DATA4PT Team (talk) 17:38, 25 March 2024 (CET)