DATA4PT NeTEx Validation Rules Overview rules
142 of 142 rules
| Code | Description | Severity | Category |
|---|---|---|---|
| C.01.02 | The versions of NeTEx schema being used should be specified | 10 | structure |
| C.01.03 | The versions of the profile being used should be specified | 20 | structure |
| C.01.04 | The PublicationRequest element in the header should be populated | 40 | structure |
| C.01.05 | Any Topics mentioned in the Header must be present in the Delivery | 40 | integrity |
| C.02.01 | All objects are uniquely identified | 10 | structure |
| C.02.03 | All elements (except CODESPACE) should have a version attribute. | 10 | structure |
| C.02.03-b | The order number on elements in sequences of child elements should be unique | 30 | semantic |
| C.02.04 | All references should include an explicit version on the reference. | 30 | integrity |
| C.02.05 | All frames should have a default CODE SPACE declared | 10 | structure |
| C.02.05-b | Any local reference should correspond to an object declared elsewhere in the same document. | 10 | structure |
| C.02.06 | All CODE SPACE prefixes used in identifiers should be declared with a CODE SPACE on the frame. | 10 | structure |
| C.02.07 | The format of element identifiers should follow any rules specific to the profile | 40 | structure |
| C.03.01 | The version number of each VERSION FRAME should be populated with a number | 20 | structure |
| C.03.02 | The FrameDefaults of a VERSION FRAME should have values appropriate to the content | 30 | structure |
| C.03.04 | Only the specialisation of VERSION FRAME (RESORCE FRAME, SITE FRAME, SERVICE FRAME, SERVICE FRAME< TIMETABLE FRAME, and SERVICE CALENDAR FRAME) appropriate to the profile should be used | 40 | structure |
| C.03.05 | A TYPE OF FRAME is specified on each VERSION FRAME. and corresponds to one of those required by the profile | 30 | structure |
| C.03.05-b | Types of Frame in use: (EU_PI_COMMON. PI_PI_STOP. EU_PI_NETWORK. EU_PI_TIMETABLE. EU_PI_CALENDAR. EU_PI_LINE_OFFER. EU_PI_NETWORK_OFFER. EU_PI_STOP_OFFER. EU_PI_METADATA) | 30 | structure |
| C.04.01 | The same object type should only be present in a single frame type | 30 | structure |
| C.04.02 | Ordered sequences of child elements shall be serialized in sequence in the accordance with the ascending value of their order attribute - | 30 | semantic |
| C.04.04 | Single instances of ancillary and child elements should be declared inline as part of an object. | 40 | structure |
| C.04.04-b | Elements should not be repeated unnecessarily as separate instances. | 40 | quality |
| C.04.05 | NOTICes should be declared locally | 40 | structure |
| C.09.01 | On a VALIDITY CONDITION. ToDate must not be later than FromDate on any date range | 20 | structure |
| C.09.02 | On a VERSION FRAME. ToDate must not be later than FromDate on any date range. | 10 | structure |
| C.09.03 | ToDate must not be later than FromDate on other date ranges | 20 | structure |
| C.09.04 | Date ranges of elements in the frame must lie between date ranges of the VALIDITY CONDITION on the VERSION FRAME | 20 | semantic |
| C.09.06 | If the URL field is filled. the validity of the URL must be checked and must resolved | 40 | format |
| C.09.07 | Check valid ISO codes for lang etc. | 20 | structure |
| C.09.08 | Check valid ISO codes for Country. etc. | 30 | format |
| C.09.10 | A coordinate system should be specified for spatial coordinates | 20 | structure |
| C.09.11 | WGS84 is the preferred coordinate system | 40 | structure |
| C.09.12 | A POINT should normally have spatial coordinates specified. | 40 | structure |
| C.09.13 | A ZONE should normally have at least a centroid point specified. | 40 | structure |
| S.01.01 | Every STOP PLACE has a Name or ShortName attibute | 20 | structure |
| S.01.03 | Every STOP PLACE has a StopPlaceType attribute with correct value | 30 | structure |
| S.01.04 | All stop identifiers (QUAY. all STOP PLACEs. GROUPs OF STOP PLACEs and ACCESS) must comply with the profile codification | 30 | structure |
| S.01.05 | A responsible OPERATOR must be declared for each STOP PLACE(Can be defaulted from frame) | 30 | structure |
| S.01.08 | Any STOP PLACE that is declared should be referenced by a STOP ASSIGNMENT | 50 | quality |
| S.03.01 | STOP PLACES should be organised hierarchically so as to separate the modes. | 30 | structure |
| S.03.02 | A Monomodal STOP PLACE should only have QUAYS of a single mode | 30 | structure |
| S.03.02-b | SCHEDULED STOP POINT must be assigned to a STOP PLACE | 50 | quality |
| S.03.03 | MODE of a QUAY of a monomodal STOP PLACE should match the STOP PLACE | 40 | semantic |
| S.03.04 | Multimodal STOP PLACE and should contain at two different monomodal STOP PLACEs of different MODes | 40 | structure |
| S.03.05 | GROUP OF STOP PLACEs should contain only STOP PLACEs | 40 | structure |
| S.03.06 | Name of a QUAY should not repeat those of the STOP PLACE | 40 | structure |
| S.04.01 | A SCHEDULED STOP POINT must have an instantiated Name field | 30 | integrity |
| S.04.02 | SCHEDULED STOP POINT must have the same mode as the assigned STOP PLACE | 30 | semantic |
| S.04.02-b | SCHEDULED STOP POINT must have similar spatial coordinates to those of the assigned STOP PLACE | 30 | structure |
| S.04.03 | If a SCHEDULED STOP POINT is assigned to a STOP PLACE the type of stop should be consistent on both. And also on any QUAY | 30 | integrity |
| S.08.01 | Location Is Unreasonable For QUAY | 30 | plausibility |
| S.08.02 | Location Is Unreasonable For STOP POINT | 30 | plausibility |
| S.08.03 | Distance Between QUAY and STOP PLACE too long | 30 | semantic |
| S.08.04 | Check if there are any nearby, very similar locations of the same EntityType | 40 | structure |
| S.09.01 | Distance between SCHEDULED STOP POINTS at a CONNECTION is plausible | 30 | plausibility |
| S.09.01-b | The location of QUAY and SCHEDULED STOP POINT should be within reasonable distance of the location or surface of STOP PLACE | 30 | plausibility |
| S.15.01 | Every TOPOGRAPHIC PLACE has a Name | 40 | structure |
| S.15.02 | Type of TOPOGRAPHIC LOCATIONS | 40 | structure |
| S.15.03 | PostalRegion attribute on ADDRESS element | 40 | structure |
| S.15.04 | Hierarchy of TOPOGRAPHIC LOCATIONS | 40 | structure |
| S.15.06 | Management of STOP PLACE's additionalTopographicPlaces (belonging to several municipalities) | 40 | structure |
| S.30.05 | Membership of a SITE by a SITE COMPONENT. | 40 | structure |
| S.31.01 | The members of a CONSTRAINT ZONE are SCHEDULED STOP POINTs | 40 | structure |
| S.31.02 | A ROUTING CONSTRAINT ZONE must be defined either by Stop or by a boundary | 20 | structure |
| S.31.03 | A ROUTING CONSTRAINT ZONE must specify the nature of its use. | 40 | structure |
| T.02.01 | Each LINE should have a different name and a different public code | 20 | structure |
| T.02.02 | TransportSubmode must be a part of the TransportMode | 30 | integrity |
| T.02.02-b | Every LINE must have an OPERATOR | 30 | integrity |
| T.02.03 | The TypeOfLineRef must meet the profile requirements | 40 | structure |
| T.02.04 | MODE and SUBMODE of a LINE must be consistent with stops and journeys | 30 | semantic |
| T.02.05 | A LINE must have at least one ROUTE | 30 | integrity |
| T.02.05-b | The “inverse” of the SERVICE PATTERN must match the approximate reverse of sequence | 40 | semantic |
| T.02.08 | If no RouteRef is available in a SERVICE JOURNEY. a RouteView with LineRef must be available | 30 | structure |
| T.02.10 | Check that there is at least one LINE in any GROUP OF LINEs | 30 | structure |
| T.02.11 | The main line of a GROUP OF LINEs must be part of the group | 30 | integrity |
| T.02.11-b | Colour used for each separate LINE should be distinct | 40 | quality |
| T.02.12 | A LINE must have one or more ROUTE instances | 40 | integrity |
| T.02.13 | A ROUTE must be referenced by a SERVICE JOURNEY PATTERN directly or indirectly. | 40 | integrity |
| T.02.14 | The MODE of a GROUP OF LINEs NETWORK must be consistent with that of the individual LINEs | 30 | semantic |
| T.03.01 | A primary SERVICE JOURNEY shall have at least one SERVICE PATTTERN, and/or have a list of CALLs | 20 | structure |
| T.03.01-b | A ROUTE must have one or more SERVICE PATTERNs that use it. | 50 | quality |
| T.03.01-c | A SERVICE JOURNEY must reference a SERVICE PATTERN. | 30 | integrity |
| T.03.03 | SERVICE JOURNEY PATTERN must contain POINTS IN JOURNEY PATTERN | 40 | structure |
| T.03.03-b | A SERVICE JOURNEY PATTERN must have a minimum of two Points | 30 | structure |
| T.03.04 | The TransportMode and TransportSubmode of the Journey must respect the choices of the profile | 30 | structure |
| T.03.04-b | JOURNEY PATTERNs of SERVICE JOURNEYs shall only include S POINTS IN JOURNEY PATTERN that reference SHCEDULED STOP POINTs | 10 | structure |
| T.03.06 | An OPERATOR must be declared for each SERVIOCE JOURNEY | 20 | structure |
| T.03.09 | A substitution SERVICE JOURNEY must reference a SERVICE JOURNEY that it is replacing | 40 | integrity |
| T.04.01 | Every SERVICE JOURNEY should be referenced either by a GROUP OF SERVICEs or by a SERVICE JOURNEY INTERCHANGE or by an INTERCHANGE RULE. | 40 | integrity |
| T.04.02 | A SERVICE JOURNEY instances that have a similar DIRECTION and DAY TYPE and JOURNEY PATTERN should be grouped with a GROUP OF SERVICEs | 30 | structure |
| T.07.11 | DESTINATION DISPLAYs should always have at least one "FrontText" | 40 | structure |
| T.07.12 | DESTINATION DISPLAY VARIANTs always have at least one "FrontText" | 40 | structure |
| T.07.XX | Check if the Journey PATTERN matches any associated ROUTE | 40 | semantic |
| T.08.01 | A SERVICE JOURNEY have at least one DAY TYPE | 20 | structure |
| T.08.02 | A DAY TYPE must have sufficient PropertiesOfDay to characterise it | 30 | structure |
| T.08.05 | Days without scheduled SERVICE JOURNEYs for a Line must raise a warning | 30 | structure |
| T.08.11 | Validity period of the SERVICE JOURNEYs must fall within the validity period of the VERSION FRAME | 20 | structure |
| T.08.12 | The validity of the timetable must be at least N days. | 40 | structure |
| T.09.01 | Every POINT IN JOURNEY POINT In a JOURNEY PATTERN used by a JOURNEY must have an PASSING TIME with arrival and departure time (except for the first and last stop) | 20 | integrity |
| T.09.02 | There should be a time specified on each CALL of a SERVICE JOURNET | 30 | structure |
| T.09.03 | Successive DayOffset+PassingTimes for the POINTs IN JOURNEY Pattern or CALLS of a Journey must not decrease. N | 20 | structure |
| T.09.06 | Consistency of schedules: schedules at the earliest and at the latest | 20 | semantic |
| T.09.07 | Successive timing between stops should be consistent with specified durations from TIMING LINKs t | 20 | semantic |
| T.09.09 | PASSING TIMEs for successive POINT IN JORUNEY PATTERNS must result in a plausible speed for the MODE and VEHICLE TYPE | 30 | plausibility |
| T.09.10 | The duration of a SERVICE JORUNEY Journey should be consistent with the timings and distances. | 30 | semantic |
| T.11.01 | Shared JOURNEY PARTs must be independent of any specific SERVICE JORUNEY | 40 | structure |
| T.11.02 | Each JOURNEY PART should be coherent with the SERVICE PATTERN of the SERVICE JOURNEY | 20 | semantic |
| T.11.03 | Timings of each JOURNEY PART should be coherent with the times of the SERVICE JOURNEY | 10 | semantic |
| T.11.05 | JOURNEY PART is coherent with the parent JOURNEY | 20 | semantic |
| T.11.09 | JOURNEY PART COUPLEs should be consistent with JOURNEY PARTs | 20 | semantic |
| T.12.02 | Distance between SCHEDULED STOP POINTS in JOURNEY PATTERN is plausible | 30 | plausibility |
| T.12.04 | If the DESTINATION DISPLAY is flagged as changing at a point, then the new DESTINATION DISPLAY must be present. | 40 | structure |
| T.14.01 | TEMPLATE SERVICE JOURNEYs must have an associated frequency or rhythm | 20 | integrity |
| T.14.01-b | Specific VEHICLE TYPE capabilities should be populated (e.g. wheelchair) | 40 | structure |
| T.14.02 | RHYTHMICAL JOUREY GROUP should not be used in EPIP | 20 | structure |
| T.14.03 | For a HEADWAY JOURNEY GROUa frequency must be specified | 20 | structure |
| T.14.04 | End of Period of cadences for JOURNEY FREQUENCY GROUP must be specified | 20 | structure |
| T.14.07 | TEMPLATE SERVICE JOURNEY must have an appropriate type attribute | 20 | integrity |
| T.14.09 | Reference usage for HEADWAY JOURNEY GROUP and RHYTHMICAL JOURNEY GROUP should be declared in frame and not inline | 30 | integrity |
| T.14.10 | JOURNEY FREQUENCY GROUP must contain more than one SERVICE JOURNEY | 30 | structure |
| T.14.XX | Consistency of the return route | 20 | semantic |
| T.14.XX-b | LINE and ROUTE should be linked consistently | 20 | semantic |
| T.21.01 | A TRANSFER must have a transfer time | 30 | integrity |
| T.21.01-b | NOTICE ASSIGNMENTS are only related to TIMETABLEs. SERVICE JOURNEYs. POINTs IN JOURNEYPATTERN. SERVICE JOURNEY INTERCHANGEs | 40 | structure |
| T.21.02 | Transit times should be specified on DEFAULT CONNECTIONs and SITE CONENCTIONs.. | 40 | structure |
| T.21.03 | Transit times should be specified on CONNECTIONs. | 40 | structure |
| T.21.04 | Checking the type of transfer | 30 | structure |
| T.21.05 | Reasonable walking speed - Consistency between duration and distance of a CONNECTION / TRANSFER | 20 | plausibility |
| T.21.05-b | Check if the SERVICE JOURNEY INTERCHANGE transfer distance is reasonable | 30 | plausibility |
| T.21.07 | Duration of interchanges between SERVICE JOURNEYS | 30 | semantic |
| T.25.01 | FLEXIBLE SERVICEA should be characterised by a FlexibleServiceType. This should be coherent with the LINE type. | 30 | semantic |
| T.25.01-b | CLASS of USE on PASSENGER CAPACITY should be restricted to subset of possible values. | 40 | format |
| T.25.02 | FLEXIBLE SERVICEs using point standing for a zone should have the required ZONE. | 30 | structure |
| T.25.02-b | Order of TRAIN COMPONENTs | 20 | semantic |
| T.25.03 | FLEXIBLE SERVICEs using stopping areas require a zone containing stops. | 40 | structure |
| T.25.03-b | CLASS of USE on TRAIN ELEMENT should be restricted to subset of possible values. | 30 | format |
| T.25.04 | FLEXIBLE SERVICE should be coherent with any frequency interval | 20 | semantic |
| T.25.05 | Use specific instances for FLEXIBLE SERVICE PROPERTies for each FLEXIBL SERVICE | 30 | structure |
| T.30.01 | The URL of the schematic plan must be valid | 40 | structure |
| T.30.02 | Check objects in SCHEMATIC MAPs | 40 | structure |
| T.35.01 | Specific BOOKING ARRANGEMENTs must be given | 30 | structure |
| T.40.02 | A Type of Vehicle must be named | 30 | structure |
| T.48.01 | Any SCHEDULED STOP POINT that is declared should be used. i.e. referenced by an assignment or POINT IN PATTERN etc. | 40 | quality |