framework
Current version for framework is: v1.5 (last changed Jul 28, 2022)
Content
- 1 Frames
- 1.1 Data conditions
- 1.1.1 FrameDefaults
- 1.1.2 Codespace
- 1.1.2.1 Codespace example
- 1.2 Specific components
- 1.2.1 ResourceFrame
- 1.2.2 SiteFrame
- 1.2.3 ServiceFrame
- 1.2.4 ServiceCalendarFrame
- 1.2.5 TimetableFrame
- 1.2.6 VehicleScheduleFrame
- 1.2.7 FareFrame
- 1.2.8 SalesTransactionFrame
- 1.1 Data conditions
- 2 Components
- 2.1 Abstract Types
- 2.1.1 Entity
- 2.1.2 EntityInVersion
- 2.1.3 DataManagedObject
- 2.1.4 TypeOfValue
- 2.1.5 TypeOfEntity
- 2.1.6 GroupOfEntities
- 2.1.7 Address
- 2.1.8 Assignment
- 2.1.9 Equipment Details
- 2.1.9.1 Equipment
- 2.1.9.2 PassengerEquipment
- 2.1.9.3 ActualVehicleEquipment
- 2.1.10 FacilitySet
- 2.1.11 Place
- 2.1.12 Link
- 2.1.13 LinkSequence
- 2.1.13.1 PointInLinkSequence
- 2.1.13.2 LinkInLinkSequence
- 2.1.14 Projection
- 2.1.15 Organisation
- 2.1.16 PriceableObject
- 2.1.17 FarePrice
- 2.2 Basic Types
- 2.2.1 KeyList
- 2.2.2 AlternativeName
- 2.2.3 ContactStructure
- 2.2.4 DeliveryVariant
- 2.2.5 GeneralGroupOfEntities
- 2.2.6 GroupOfPoints
- 2.2.7 Locale
- 2.2.8 LanguageUsage
- 2.2.9 Location
- 2.2.10 MultilingualString
- 2.2.11 Projection Types
- 2.2.11.1 PointProjection
- 2.2.11.2 ZoneProjection
- 2.2.12 Address Types
- 2.2.12.1 PostalAddress
- 2.2.12.2 RoadAddress
- 2.2.13 Vehicle
- 2.2.14 VehicleType
- 2.2.15 PassengerCapacity
- 2.3 Accessibility Types
- 2.3.1 AccessibilityAssessment
- 2.3.2 AccessibilityLimitation
- 2.3.3 Suitability
- 2.4 Geographical Types
- 2.4.1 Point
- 2.4.2 Zone
- 2.4.3 Polygon
- 2.4.3.1 Polygon-structure
- 2.4.3.1.1 Polygon example
- 2.4.3.1 Polygon-structure
- 2.5 Organisation Types
- 2.5.1 Authority
- 2.5.2 Operator
- 2.5.3 GroupOfOperators
- 2.5.4 Branding
- 2.5.5 DataSource
- 2.5.6 TypeOfAccessRightAssignment
- 2.6 Equipment Types
- 2.6.1 AccessEquipment
- 2.6.1.1 EntranceEquipment
- 2.6.1.2 PlaceLighting
- 2.6.1.3 RampEquipment
- 2.6.1.4 RoughSurface
- 2.6.1.5 CycleStorageEquipment
- 2.6.2 PassengerEquipment
- 2.6.2.1 SanitaryEquipment
- 2.6.3 SiteEquipment
- 2.6.3.1 WaitingRoomEquipment
- 2.6.3.2 ShelterEquipment
- 2.6.4 TicketingEquipment
- 2.6.4.1 TicketingEquipment
- 2.6.5 TicketValidatorEquipment
- 2.6.6 SignEquipment
- 2.6.6.1 GeneralSign
- 2.6.7 LocalService
- 2.6.7.1 AssistanceService
- 2.6.7.2 AssistanceBookingService
- 2.6.7.3 LuggageService
- 2.6.8 ServiceFacilitySet
- 2.6.1 AccessEquipment
- 2.7 Train Types
- 2.7.1 CompoundTrain
- 2.7.2 TrainInCompoundTrain
- 2.7.3 Train
- 2.7.4 TrainSize
- 2.7.5 TrainComponent
- 2.7.6 TrainElement
- 2.8 Notice Types
- 2.8.1 Notice
- 2.8.1.1 AlternativeText
- 2.8.2 NoticeAssignment
- 2.8.1 Notice
- 2.9 Calendar Types
- 2.9.1 DayType
- 2.9.2 PropertyOfDay
- 2.9.3 Timeband
- 2.9.4 DayTypeAssignment
- 2.9.5 OperatingDay
- 2.9.6 OperatingPeriod
- 2.10 Timing
- 2.10.1 JourneyWaitTime
- 2.10.2 JourneyPatternWaitTime
- 2.10.3 JourneyRunTime
- 2.10.3.1 TimingLink
- 2.10.4 JourneyPatternRunTime
- 2.10.5 JourneyHeadway
- 2.11 Constraints
- 2.11.1 CheckConstraint
- 2.11.2 CheckConstraintDelay
- 2.12 Validity Types
- 2.12.1 ValidityCondition
- 2.12.2 AvailabilityCondition
- 2.12.3 ValidBetween
- 2.12.4 ValidityTrigger
- 2.13 Vehicle Schedule Types
- 2.13.1 Block
- 2.14 Transport Modes
- 2.1 Abstract Types
This document is part of NeTEx Nordic Profile and describes common components and generic concepts used for public transport data exchange in the NeTEx format.
Frames
Frames are used for logical grouping of different NeTEx concepts:
General Frame - frame for an unstructured description of NeTEx-objects. Not used in the Nordic profile.
Resource Frame - frame for common objects, i.e. organisations, responsibilities, equipments etc.
Site Frame - frame for information regarding stop places and places of interest.
Service Frame - frame for information regarding networks lines, routes, planned stops etc.
Service Calendar Frame - frame for defining calendar-information - types of days, operating days, and their relations etc.
Timetable Frame - frame for describing the actual journeys, such as calendar references, departure times, and waiting times etc.prop
Vehicle Schedule Frame - frame for vehicle usage planning with vehicle information, equipment and blocks.
Fare Frame - frame for fare definitions and price information including products and sales offers.
Sales Transaction Frame - frame for data on customer-related sales/purchases and consumption of acquired rights.
Infrastructure Frame - frame for information about infrastructure - garages, roads, intersections etc. Not used in the Nordic profile.
There is an additional Composite Frame, which can be used to group other frames, as long as they have identical ValidityCondition (implicitly inherited from CompositeFrame). There are no requirements regarding order or dependency between frames.
Data conditions
All objects in the profile should be defined with as much generality as possible, and at the highest possible hierarchic level. This is particularly true for:
ValidityCondition / ValidBetween
FrameDefaults
Codespace
Where more specific instances deviate from the general definition at a higher level in the hierarchy, an overruling definition can be set further down the hierarchy.
FrameDefaults
Used to define common values. The following elements are permitted:
Element | Type | Description |
---|---|---|
DefaultCodespaceRef | CodespaceRef | Reference to the default codespace. |
DefaultDataSourceRef | DataSourceRef | Reference to the default data source. |
DefaultLocale | Default locale description | |
DefaultLocationSystem | xsd:normalizedString | Default geographic coordinate system. If defined it should be “ NOTE: The national journey planner and stop place registry requires coordinates in the WGS84 EPSG:4326 format. |
DefaultSystemOfUnits | xsd:normalizedString | Default unit should be |
DefaultCurrency | CurrencyType | Three letter currency code according to |
Codespace
The codespace is used to ensure that objects defined in the frame remain unique even when they are consolidated with data from other data sources. Each codespace is a URL with a unique three-letter code and a description.
Codespace example
<Codespace>
<Xmlns>RUT</Xmlns>
<XmlnsUrl>http://www.entur.org/ns/rut</XmlnsUrl>
<Description>Ruter</Description>
</Codespace>
The codespaces are assigned to each new data provider by Entur. This ensures the uniqueness of data sources. Contact Entur to be assigned a codespace.
Specific components
Listed here is the structure for each frame, and which objects are expected to appear in them.
ResourceFrame
ResourceFrame < DataManagedObject < EntityInVersion < Entity | |||
---|---|---|---|
Name | Type | Cardinality | Description |
dataSources | 0: * | Container for DataSource objects | |
typesOfValue | 0: * | Container for TypeOfValue objects | |
organisations | 0: * | Container for Organisation objects | |
groupsOfOperators | 0: * | Container for GroupOfOperators objects | |
equipments | 0: * | Container for Equipment objects | |
vehicleTypes | 0: * | Container for VehicleType objects | |
vehicles | 0: * | Container for Vehicle objects | |
groupsOfEntities | 0: * | Container for GeneralGroupOfEntities objects |