Complex type
EstimatedServiceJourneyInterchangeStructure
Defined in OpRa/SIRI/xsd/siri_model/siri_estimatedVehicleJourney.xsd:155
Type for Estimated SERVICE JOURNEY INTERCHANGE.
Used by elements
Content model
Type structure
-
-
Reference to a SERVICE JOURNEY INTERCHANGE.
-
Identifier of ESTIMATED SERVICE JOURNEY INTERCHANGE in case it is an addition to the plan. (since SIRI 2.1)
-
Reference to a physical CONNECTION LINK over which the SERVICE JOURNEY INTERCHANGE takes place. (since SIRI 2.0)
-
Reference to a connecting feeder VEHICLE JOURNEY. (since SIRI 2.0)
-
SCHEDULED STOP POINT at which feeder journey arrives. Assuming, for example, that the feeder is redirected to another QUAY by a dispositive measure in order to shorten the transfer time, how do we communicate this change in the interchange? If the STOP POINTs are modelled QUAY accurate, FeederArrivalStopRef should always reference the STOP POINT of the new/expected QUAY (which was transmitted in the ESTIMATED VEHICLE JOURNEY). (since SIRI 2.1)
-
Sequence of visit to Feeder stop within Feeder JOURNEY PATTERN.
-
For implementations in which the overall order is not defined by VISIT NUMBER, i.e. in case VisitNumberIsOrder is set to false, ORDER can be used to associate the stop order instead. ORDER is also used together with VISIT NUMBER in scenarios where an extra CALL is inserted as a result of despatching alterations. Because such an extra CALL may have the same VisitNumber as another (cancelled) CALL, the STOP ORDER is needed. (since SIRI 2.1)
-
Planned time at which feeder VEHICLE is scheduled to arrive. (since SIRI 2.1)
-
Reference to a connecting distributor VEHICLE JOURNEY. (since SIRI 2.0)
-
SCHEDULED STOP POINT at which distributor journey departs. Assuming that the distributor is directed to another QUAY (and that STOP POINTs are modelled QUAY accurate), DistributorDepartureStopRef should always reference the STOP POINT of the new/expected QUAY (which was transmitted in the ESTIMATED VEHICLE JOURNEY). (since SIRI 2.1)
-
Sequence of visit to Distributor stop within Distributor JOURNEY PATTERN.
-
For implementations in which the overall order is not defined by VISIT NUMBER, i.e. in case VisitNumberIsOrder is set to false, ORDER can be used to associate the stop order instead. ORDER is also used together with VISIT NUMBER in scenarios where an extra CALL is inserted as a result of despatching alterations. Because such an extra CALL may have the same VisitNumber as another (cancelled) CALL, the STOP ORDER is needed. (since SIRI 2.1)
-
Planned time at which distributor VEHICLE is scheduled to depart. (since SIRI 2.1)
-
Properties of SERVICE JOURNEY INTERCHANGE. It is important to note that the InterchangePropertyGroup displays planning data whereas, for example, InterchangeStatus or Will(Not)Wait contain the real-time data. A SERVICE JOURNEY INTERCHANGE may be transmitted with "Guaranteed=true", but also WillNotWait due to major despatching alterations. However, Will(Not)Wait will always take precedence over the property Guaranteed, which means that WillNotWait breaks the connection regardless of whether Guarateed was transmitted. (since SIRI 2.1)
-
Whether the passenger can remain in VEHICLE (i.e. BLOCKlinking). Default is 'false': the passenger must change vehicles for this connection.
-
Whether the SERVICE JOURNEY INTERCHANGE is guaranteed. Default is 'false'; SERVICE JOURNEY INTERCHANGE is not guaranteed.
-
Whether the SERVICE JOURNEY INTERCHANGE is advertised as a connection. Default is 'false'.
-
-
-
Whether this interchange is planned, updated, additional or cancelled. (since SIRI 2.1)
-
-
Distributor will not wait, i.e., connection is not guaranteed or broken. SIRI 2.0
-
Details about how (long) the distributor services may be held in order to guarantee the connection. (since SIRI 2.0)
-
-
Time at which feeder VEHICLE is expected to arrive. (since SIRI 2.1)
-
Time at which distributor VEHICLE is expected to depart. (since SIRI 2.0)
-
Whether connection monitoring is active or not for this connection. (since SIRI 2.0)
-
Contains various types of transfer and wait times of a SERVICE JOURNEY INTERCHANGE. Implementation Note: what happens if, for example, the interchange times and a QUAY change in xxxStopAssignment of the ESTIMATED VEHICLE JOURNEY suggest contradictory transfer/wait times? In case of doubt, the interchange times are to be favoured because they are transmitted explicitly. (since SIRI 2.1)
-
Elements for INTERCHANGE WAIT TIME.
-
Standard wait time for INTERCHANGE. SIRI v2,0
-
Maximum time that Distributor will wait for Feeder for INTERCHANGE. SIRI v1.0
-
Maximum automatic wait time that Distributor will wait for Feeder for INTERCHANGE. (since SIRI 2.0)
-
-
Elements for INTERCHANGE TRANSFER duration.
-
Standard transfer duration for INTERCHANGE. SIRI v2,0
-
Minimum transfer duration for INTERCHANGE. SIRI v2,0
-
Maximum transfer duration for INTERCHANGE. SIRI v2,0
-
-
-
Extensions to schema. (Wrapper tag used to avoid problems with handling of optional 'any' by some validators).