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 cray and people defining them have a lot of imagination. This resulted in NeTex Part3 being quite big and it is strongly advised to use only a small subset of it (what we call a Profile): France, Norway and UK are currently working on a fare national profiles. A minimum European profile should be produced at some point (with the support of DATA4PT).

--DATA4PT Team (talk) 19:44, 19 May 2022 (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. It seems that in this example the FARE STRUCTURE ELEMENTs provide the same access rights for each of the SALES OFFER PACKAGE ELEMENTs. 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 ELEMENT is 6 + (n-1)*3 euros.

Part of the SALES OFFER PACKAGE is the PREASSIGNED FARE PRODUCT.

Under this element, a dayPass (PREASSIGNED FARE PRODUCT), and a set of dayPass(es) with validity conditions would correspond better to this use case. A TimeInterval type pricing structure will be more relevant to the pricing of a single trip (the DayOffset are only there because some long distance trips can exceed the day).