Simple rhythm based bus line
Content
- 1 Line 61A, Oslo
- 1.1 Description of the line
- 1.1.1 Link
- 1.2 PublicationDelivery
- 1.2.1 Frameset
- 1.3 CompositeFrame
- 1.3.1 Codespace
- 1.4 ResourceFrame
- 1.4.1 Organisation
- 1.4.1.1 organisations
- 1.4.2 Site Frame
- 1.4.2.1 SiteFrame
- 1.4.1 Organisation
- 1.5 Service Frame
- 1.5.1 General concepts
- 1.5.1.1 Network
- 1.5.1.2 Line
- 1.5.1.3 Direction
- 1.5.1.4 DestinationDisplay
- 1.5.1.4.1 Network | Line | Direction | Destination
- 1.5.2 Route
- 1.5.2.1 routePoints
- 1.5.2.2 routes
- 1.5.3 ScheduledStopPoints
- 1.5.3.1 StopAssignments
- 1.5.3.1.1 StopAssignment
- 1.5.3.1 StopAssignments
- 1.5.4 JourneyPattern
- 1.5.5 Notice
- 1.5.5.1 Service Calendar Frame
- 1.5.6 ServiceCalendar
- 1.5.7 DayTypes
- 1.5.8 Timeband
- 1.5.1 General concepts
- 1.6 Timetable Frame
- 1.6.1 Validity
- 1.6.1.1 validityConditions
- 1.6.2 Vehicle Journeys
- 1.6.1 Validity
- 1.1 Description of the line
Line 61A, Oslo
According to the Norwegian NeTEx-profile, each Line must be defined in its own separate XML-file.
Description of the line
Line 61A is a circular bus line passing the following stops:
Tveita T
Tveita bedriftsområde
Solfjellet
Larsbråten
Tveita bedriftsområde
Tveita
Tveita T
Departures are fixed to leave 15 minutes past every whole hour between 0915 and 1415, Monday through Saturday. The Line is modelled with a Route, where Timetable is modelled as Periodical Journeys (TemplateServiceJourney) based on RhythmicalJourneyGroup.
Link
The XML example in it its entirety can be found in the GitHub repository: https://github.com/entur/profile-norway-examples/blob/master/netex/network/Line61A.xml
PublicationDelivery
Defines the contents of the submitted file
Frameset
<?xml version="1.0" encoding="UTF-8"?>
<PublicationDelivery
version="1.0"
xmlns="http://www.netex.org.uk/netex"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.netex.org.uk/netex ../../xsd/NeTEx_publication.xsd">
[...]
<dataObjects>
<CompositeFrame version="1" created="2015-12-13T00:00:00Z" id="RUT:Norway:CompositeFrame:0061">
[...]
<frames>
<ResourceFrame version="any" id="RUT:ResourceFrame:RF1">
[...]
</ResourceFrame>
<SiteFrame version="any" id="RUT:SiteFrame:SF01">
[...]
</SiteFrame>
<ServiceFrame version="any" id="RUT:ServiceFrame:0061">
[...]
</ServiceFrame>
<ServiceCalendarFrame version="any" id="RUT:ServiceCalendarFrame:SCF01">
[...]
</ServiceCalendarFrame>
<TimetableFrame version="any" id="RUT:TimetableFrame:TF02">
[...]
</TimetableFrame>
</frames>
</CompositeFrame>
</dataObjects>
</PublicationDelivery>
Below is a more detailed description of the most important elements that must be included in the data transfer to Entur:
CompositeFrame
This Frame is used to group ("wrap") frames with data, and define ownership of the dataset in the submission's codespace. This describes the "namespace" - Xmlns - (cf. Administration code), which defines the submitter of the dataset.
Each operator, as well as other authorities, has its own unique namespace, allocated by Entur.
Codespace
<codespaces>
<!-- Codespace for Ruter -->
<Codespace id="ruter">
<Xmlns>RUT</Xmlns>
<XmlnsUrl>http://www.ruter.no/</XmlnsUrl>
</Codespace>
<!-- Codespace for national stop place registry-->
<Codespace id="nhr">
<Xmlns>NHR</Xmlns>
<XmlnsUrl>http://stoppested.entur.org</XmlnsUrl>
</Codespace>
</codespaces>
ResourceFrame
Organisation
organisations
<organisations>
<!-- Owner of line -->
<Authority version="1" id="RUT:Company:0">
<CompanyNumber>991609407</CompanyNumber>
<!-- Organisasjonsnummer -->
<Name>Ruter</Name>
<LegalName>RUTER AS</LegalName>
<OrganisationType>authority</OrganisationType>
</Authority>
<!-- Operator of line -->
<Operator version="1" id="RUT:Company:1">
<CompanyNumber>985615616</CompanyNumber>
<Name>Unibuss</Name>
<LegalName>UNIBUSS AS</LegalName>
<CustomerServiceContactDetails>
<Phone>0047 177</Phone>
<Url>http://www.ruter.no</Url>
<FurtherDetails>Kontaktskjema på websider</FurtherDetails>
</CustomerServiceContactDetails>
</Operator>
</organisations>
Site Frame
Description of a stop place can be found in more detail under Stop place - Simple. Other files should only contain simplified references to the stop places with IDs from the stop place registry.
SiteFrame
Service Frame
Defines data for a Route, such as Networks, Lines stops, etc.
General concepts
Network
Lines under a common "umbrella", e.g. the bus lines owned by Ruter.
Line
A group of Routes known by the same marketed name, e.g. Metro Line 2.
Direction
Defines the direction of a line. Line 61A is a clockwise roundtrip.
DestinationDisplay
Specifies the destination information for the Line (commonly matching the text displayed on the front of the bus).
Network | Line | Direction | Destination
Route
routePoints
All route points are listed as references to StopPoints.
Even if you have multiple routes, all route points must be defined in the same routePoints block. The route points are subsequently used to define the routes. As shown in the next section, the references are specified as a sequential list of the RoutePoints used in each Route.
routes
Line 61A is a circular route and has no reverse pattern.
A Route always consists of a sequence of PointOnRoute, referring to the already defined RoutePoints mentioned above.
ScheduledStopPoints
Each stop served by Line 61A must be defined as a ScheduledStopPoint in order to be used as a StopPoint in a JourneyPattern.
StopAssignments
Linking of a ScheduledStopPoint to a defined StopPlace/Quay is done through a PassengerStopAssignment. (All StopPlaces and Quays belong to the NSR codespace.)
StopAssignment
JourneyPattern
The line's pattern (unique sequence of stops) is defined as a JourneyPattern. For the circular line 61A, there is only one pattern.
Notice
Notices (Free text fields, sometimes referred to as footnotes) referring to the entire Line, are modelled in the ServiceFrame.
Specific noticeAssignmens for a JourneyPattern is specified/referenced under PointInJourneyPattern and correspondingly for a VehicleJourney under Call.
Service Calendar Frame
Defines data for time, days, periods, and other calendar items.
ServiceCalendar
Because line 61A follows the same departure pattern every day, an example has been created with a ServiceCalendar, containing a relevant description of day and time.
If more calendars are needed, the time objects can be defined externally, in the ServiceCalendarFrame itself, and be reused by referencing them in different ServiceCalendars.
DayTypes
Description of day(s) with a set of properties, for example, which weekdays the dayType applies to.
Timeband
Specifies time. In the context of a Frequency Group (in the example, a RhythmicalJourneyGroup), <StartTime> is defined as "00" to describe how many minutes over each full hour there are departures. Multiple departures within each hour are indicated by a Timeband for each departure.
Timetable Frame
Defines data for scheduled departures, stops, and arrivals for a given trip (Journey) on a given date.
Validity
Validity period for the timetable is indicated by AvailabilityCondition.
validityConditions
Vehicle Journeys
A specific trip with passengers for a given day type can be specified in the following ways:
TemplateServiceJourney describes ServiceJourneys in a recurring pattern for a given period
A set of ServiceJourneys, each describing an individual trip
For a line like 61A, which has a recurring departure time (Simple route - Bus (rhythm based departure)#Timeband) and follows the same route (pattern) every day, a TemplateServiceJourney with a RhythmicalJourneyGroup describing the departure pattern can be used.