Content
| Table of Contents |
|---|
...
NeTEx was created by CEN / TC278 / WG3 / SG9 lead by France. The final part of the format was published in 2015. The format was created to support the needs of a collection of public transport data providers in Europe, among others ERA (European Rail Agency) and UIC (International Union of Railways).
NeTEx is an a general purpose XML format that facilitates the exchange of timetable complex public transport data between distributed systems. Data in the NeTEx format should be used to effectively update various information and operational applications through both file-based services and web service architectures. The official website contains a detailed explanation of the intention underlying the standard, data models and publicly available standard documentation. In particular, "NeTEx White Papers", available under the website's Downloads-section provides a good introduction to how different concepts in public transport can be modelled using NeTEx.
NeTEx is a comprehensive data format intended to describe different concepts in for public transport data in different ways, and in various ways. In many cases, there will be parts of the specification that exceed requirements in actual implementation. Therefore, the extraction of necessary objects, which constitute a so-called NeTEx profile, should be made. Such a profile should be used to specify which parts of the NeTEx format are expected to be exchanged between systems in a given context.
...
- NeTEx xsd-version is a numeric value specifying the NeTEx XSD (XML Schema) version being used (format X.Y)
- NO-NeTEx-<profilnavn> is the profile name with one of the following values:
- stops
- networktimetable
- fares
- Profile version is a numeric value specifying the Norwegian NeTEx-profile version being used (format X.Y)
...
| Info |
|---|
Note that when referring to an object with both id and version, the consistency validation of the XML-file will require the existence of the object referred to (with the same referred id and version) within the same file. This This also applies when the version is defined as "any". When For the same reason, when referring to external objects (for example an ID in the national stop place registry), the version attribute must be omitted in order for the XML file to be valid. |
When the version attribute is stated on a reference, this reference is validated against existing objects with the same "ID + VERSION" in the current PublicationDelivery. Because XML validation uses string comparison in Schema validation it is not possible to use version="any" for references to objects with explicit version numbers. If there are several possible versions of the objects defined internally in the file, and a reference to the latest version is desired, a reference without version attributes should be used (just like when referencing external objects).
...
| Anchor | ||||
|---|---|---|---|---|
|
Id's to The ID attribute of NeTEx objects must follow a common pattern, and are should be structured in the following way:
[codespace]:[type]:[ididentification]
- codespace
Codespace Codespace uniquely represents the owner, creator, or administrator of the data. (see codespacesSee List of current Codespaces.) - type
Should Type should always be the name of the NeTEx data type, using exactly the same spelling as implemented in the NeTEx XSD (for example NetworkResourceFrame, TransportMode, Network, Line, StopPlace, Quay etc.) - id
A numeric value, unique for the data type (unique in the identification
Identification must be a value which, in context of the first two parts (codespace + type) of the ID), uniquely identifies the data object. Please note that the ID identification string can only allows use numbers (0-9), both cases of characters lowercase (a-z) and uppercase (A-zZ) letters, dash (-) , and underscore (_), and the structuring colon (:)in any combination.
| Object | ID examples: |
|---|---|
| Line | RUT:Line:ABC |
| Route | RUT:Route:3434 |
| RoutePoint | RUT:RoutePoint:43423342-3424 |
...
The first column is omitted if the table only contains elements (it is used to separate attributes and elements).
| DataManagedObject < EntityInVersion < Entity | ||||
|---|---|---|---|---|
| Name | Type | Cardinality | Description | |
| attr | responsibilitySetRef | ResponsibilitySetIdType | 1: 1 | Points to roles and responsibility areas connected to STOP PLACE, BOARDING ZONE or ACCESS ZONE |
| elem | keyList | KeyList | 0: 1 | A set of key-value pairs which describes additional properties for the relevant object (LINE, STOP PLACE, BOARDING ZONE, PLANNED STOP POINT etc.), and necessary for third-party systems (eg. ticketing, journey-planning, real-time) |
| elem | Extentions | ExtentionStructure | 0: 1 | Extension element for data not defined by NeTEx. |
| elem | BrandingRef | BrandingRefStructure | 0: 1 | Reference to Brand (e.g. Ruter, AtB) |
...