Complex type

EstimatedServiceJourneyInterchangeStructure

Defined in SIRI/xsd/siri_model/siri_estimatedVehicleJourney.xsd:153

Type for Estimated SERVICE JOURNEY INTERCHANGE.

Used by elements

Content model

Type structure

8 top-level
  • choice 1..1
    • InterchangeCode 0..1 InterchangeCodeType

      Identifier of ESTIMATED SERVICE JOURNEY INTERCHANGE in case it is an addition to the plan. (since SIRI 2.1)

    • ConnectionLinkRef 0..1 ConnectionLinkRefStructure

      Reference to a physical CONNECTION LINK over which the SERVICE JOURNEY INTERCHANGE takes place. (since SIRI 2.0)

    • FeederJourneyRef 1..1 ConnectingJourneyRefStructure

      Reference to a connecting feeder VEHICLE JOURNEY. (since SIRI 2.0)

    • FeederArrivalStopRef 0..1 StopPointRefStructure

      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)

    • FeederVisitNumber 0..1 VisitNumberType

      Sequence of visit to Feeder stop within Feeder JOURNEY PATTERN.

    • FeederStopOrder 0..1 xsd:positiveInteger

      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)

    • AimedArrivalTimeOfFeeder 0..1 xsd:dateTime

      Planned time at which feeder VEHICLE is scheduled to arrive. (since SIRI 2.1)

    • DistributorJourneyRef 1..1 ConnectingJourneyRefStructure

      Reference to a connecting distributor VEHICLE JOURNEY. (since SIRI 2.0)

    • DistributorDepartureStopRef 0..1 StopPointRefStructure

      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)

    • DistributorVisitNumber 0..1 VisitNumberType

      Sequence of visit to Distributor stop within Distributor JOURNEY PATTERN.

    • DistributorStopOrder 0..1 xsd:positiveInteger

      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)

    • AimedDepartureTimeOfDistributor 0..1 xsd:dateTime

      Planned time at which distributor VEHICLE is scheduled to depart. (since SIRI 2.1)

    • groupInterchangePropertyGroup 0..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)

  • InterchangeStatus 0..1 InterchangeStatusEnumeration

    Whether this interchange is planned, updated, additional or cancelled. (since SIRI 2.1)

  • choice 1..1
    • WillNotWait 1..1 EmptyType

      Distributor will not wait, i.e., connection is not guaranteed or broken. SIRI 2.0

    • WillWait 1..1 WillWaitStructure

      Details about how (long) the distributor services may be held in order to guarantee the connection. (since SIRI 2.0)

  • ExpectedArrivalTimeOfFeeder 0..1 xsd:dateTime

    Time at which feeder VEHICLE is expected to arrive. (since SIRI 2.1)

  • ExpectedDepartureTimeOfDistributor 0..1 xsd:dateTime

    Time at which distributor VEHICLE is expected to depart. (since SIRI 2.0)

  • ConnectionMonitoring 0..1 xsd:boolean

    Whether connection monitoring is active or not for this connection. (since SIRI 2.0)

  • groupInterchangeTimesGroup 0..1

    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)

    • groupInterchangeWaitTimeGroup 1..1

      Elements for INTERCHANGE WAIT TIME.

      • StandardWaitTime 0..1 xsd:duration

        Standard wait time for INTERCHANGE. SIRI v2,0

      • MaximumWaitTime 0..1 xsd:duration

        Maximum time that Distributor will wait for Feeder for INTERCHANGE. SIRI v1.0

      • MaximumAutomaticWaitTime 0..1 xsd:duration

        Maximum automatic wait time that Distributor will wait for Feeder for INTERCHANGE. (since SIRI 2.0)

    • groupInterchangeTransferDurationGroup 1..1

      Elements for INTERCHANGE TRANSFER duration.

      • StandardTransferTime 0..1 xsd:duration

        Standard transfer duration for INTERCHANGE. SIRI v2,0

      • MinimumTransferTime 0..1 xsd:duration

        Minimum transfer duration for INTERCHANGE. SIRI v2,0

      • MaximumTransferTime 0..1 xsd:duration

        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).