-
Notifications
You must be signed in to change notification settings - Fork 0
VersionFrame
Within a NeTEx XML Document, NeTEx data is organized within containers called VERSION FRAMEs.
There are different types of specific VERSION FRAME, each intended as a set of related data elements for a given functional area, for example;
- A SERVICE FRAME has SCHEDULED STOP POINT, LINE, ROUTE and other data describing elements making up the transport network;
- A TIMETABLE FRAME has data on the SERVICE JOURNEYs making up a timetable;
- A SERVICE CALENDAR FRAME contains DAY TYPEs and other elements defining temporal conditions that apply to other elements.
A COMPOSITE FRAME can be used to group other frames (but frames cannot be nested otherwise). Within a specific frame, elements of different types (stops, lines, journeys, etc) are each grouped under a specific tag, usually named as the plural of the content element, for example , scheduledStopPoints, for a set of SCHEDULED STOP POINT elements. A GENERAL FRAME can contain any element in any order.
The data within a given frame should be consistent and coherent and is all subject to any VALIDITY CONDITIONs that attach to the frame.
Here's an example of a simple SERVICE FRAME containing a LINE and two SCHEDULED STOP POINTS.
<ServiceFrame version="1.0" id="epd:UK:myb:ServiceFrame_UK_PI_NETWORK:Line_3:myb"
dataSourceRef="myb:Mybus" responsibilitySetRef="myb:tariffs">
<Name>Netwrok elements for Mybus Line 3</Name>
<TypeOfFrameRef ref="fxc:UK:DFT:TypeOfFrame_UK_PI_NETWORK:FXCP" versionRef="fxc:v1.0"/>
<codespaces>
<CodespaceRef ref="naptStop_data"/>
</codespaces>
<prerequisites>
<ResourceFrameRef version="1.0"
ref="epd:UK:MYBUS:ResourceFrame_UK_PI_COMMON:MYBUS:myb"/>
</prerequisites>
<!--==== LINEs ==== -->
<lines>
<Line version="1.0" id="myb:Line_3">
<Name>Mybus 3</Name>
<Description>Alpha - -Gamma</Description>
<PublicCode>3</PublicCode>
<PrivateCode type="noc_data">METR_1</PrivateCode>
<OperatorRef version="1.0" ref="noc:MYBUS">137122</OperatorRef>
<LineType>local</LineType>
<PaymentMethods>cash</PaymentMethods>
</Line>
</lines>
<!--==== STOP POINTs ==== -->
<scheduledStopPoints>
<ScheduledStopPoint version="naptStop:any" id="naptStop:4400CY0037">
<Name>Alpha</Name>
<TopographicPlaceView>
<TopographicPlaceRef versionRef="nptg:any" ref="nptgLocality:E0056633"/>
<Name>Barchester</Name>
<QualifierName>Barsetshire</QualifierName>
</TopographicPlaceView>
</ScheduledStopPoint>
<ScheduledStopPoint version="naptStop:any" id="naptStop:4400CY0038">
<Name>Beta</Name>
<TopographicPlaceRef versionRef="nptg:any" ref="nptgLocality:E0056633"/>
</ScheduledStopPoint>
<ScheduledStopPoint version="naptStop:any" id="naptStop:4400CY0039">
<Name>Gama</Name>
<TopographicPlaceRef versionRef="nptg:any" ref="nptgLocality:E0056633"/>
</ScheduledStopPoint>
</scheduledStopPoints>
</ServiceFrame>
Transmodel definition
A set of VERSIONs referring to a same DATA SOURCE and belonging to the same TYPE OF FRAME. A FRAME may be restricted by VALIDITY CONDITIONs.
- COMPOSITE FRAME : container for grouping other frames.
- RESOURCE FRAME : common elements such as ORGANISATIONs and RESPONSIBILITY SETS.
- SITE FRAME : elements defining the places relevant to the transport network.
- SERVICE FRAME : elements defining the transport network.
- TIMETABLE FRAME elements making up a timetable.
- FARE FRAME elements defining up a transport FARE PRODUCTs and prices.
- SERVICE CALENDAR FRAME contains DAY TYPEs and other temporal conditions.
- GENERAL FRAME can contain any element in any order.
Frames may indicate other frames as prerequisites.
- Frames of any type can be in any order within a NeTEx XML document.
- There may be more then one instance of a given type of frame within a COMPOSITE FRAME.
A number of different default values can be set on the frame to apply to all its content elements unless individually overridden (For example the CODESPACE and the currency to use for financial amounts. Frames may be classified with a TYPE OF FRAME - this can be useful to indicate the specific NeTEx PROFILE being used.
- Place default values on the frame rather than repeating them on each element.
- Specify an overall VALIDITY CONDITION condition on a COMPOSITE FRAME tto indicate that all the data in it is subject to the same condition. Note that this overall frame condition should not be confused with any contentValidityConditions for the frame - these declare shared conditions that are used by more than one specific element in the frame, but do not necessarily apply to all the elements in the frame.
NeTEx Wiki Home. CEN NeTEx GITHUB