FAQ NeTEX
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.
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.
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).
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.
== 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 (direct links 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 doc can be bought from any national standardization body. 3) Use XML editor (there are commercial tools like XML spy, oxygen or free tools), to check the XSD and check the examples from Github 4) Create their own .xml examples based on the XSD and the examples available in GitHub. Contact tool providers to see if they support NeTEx files creation for new modes (check the list of the tools dedicated for EPIP – might have been extended for NeTEx Part 5). The truth is that if the user has no IT skills at all, then only an IT tool provider can support him/her following the same steps. 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). 6) Use the DATA4PT helpdesk for more technical guidance.To start with, it is important the operators to learn about the theoretical background. There is already available on DATA4PT website a webinar and corresponding presentation under the title “DATA4PT webinar 24 November 2022: NeTEx and SIRI standards for new modes” (they need to scroll down in the list to find it or you share the direct links to the video and ppt).
Additional very important material is the XSD for Part 5. https://data4pt.org/w/index.php?title=NeTEX#NeTEx_Part_5_for_New_Modes. In NeTEx – CEN Github, there are also some examples of XML files.
There are tools provided either for free or not, with which someone can create NeTEx files. https://data4pt.org/w/index.php?title=NeTEX#Editing_.2FManagement_.26_visualisation_tools_for_NeTEx_data. However, there is a need to contact the tool providers and ask them if Part 5 is also included nowadays.
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.
I would also recommend you to connect the small operators with some large operators that they have already similar development (for example authorities that they have under their responsibility all modes including new ones). We may also help in bringing them in contact with operators/authorities working on the topic in other countries to exchange knowledge (for example Italy has defined national profile to support new modes, PTA in Vienna works on the implementation of NeTEx new modes- preparing their local profile, etc.)