Vehicle route and destination information

[Robbendebiene]

[!NOTE]
This proposal is part of a series of proposals focusing on accessibility around vehicle types. It is motivated by the development of a NeTEx based vehicle registry as well as the German handbook of accessible travel chains. We are happy to contribute the necessary XSD changes via a pull request on approval.

Rationale

When a vehicle arrives at a stop, passengers need to identify the vehicle's route and/or destination in order to choose the correct vehicle. At train stations this is usually done via automatic announcements and passenger information displays at the platform. For local public transport however, announcements and passenger information displays at a stop are less suitable. This is where vehicle bound systems like a bus headsign or external vehicle speakers can assist. Having visual and audio information is important in order to meet the two-senses principle so that blind and deaf people have access to the information.

Destination displays

Electronic signs mounted on the front, side or rear of a vehicle, that display the vehicle's route number and destination.

Examples

• Bus with front and side destination display (image)
• Tram with side display (image)
• Example display manufacturer (website)

External announcements

Route and destination announcements played over external loudspeakers of the vehicle when arriving at a stop. In Germany this is called "Blindeninformationssystem" which translates to "information system for the blind". Sometimes the announcements are not automatic and instead have to be triggered by a specific device or app.

Examples

• Train - Alstom Coradia Continental (video - the first announcement you here is coming from the train)
• Tram - Skoda ForCity Classic 35T (video, specs - automatic announcement of the route/destination)
• Dresden BLIS System (video - they offer on demand announcements of the vehicle's route/destination and the vehicle's next stop)

Use cases

• If blind or visually impaired people know in advance whether they can identify a vehicle independently, they can adjust and plan their journey accordingly. If announcements exist they also need to know whether a device or app is required to trigger them.
• If deaf people know in advance where the destination displays are located, they can find them more easily and thus identify the right vehicle.

The features are part of the German handbook of public transport accessibility from the DELFI association. (see DEFLI 3021 and DELFI 3031)

Status quo

Destination displays

• The AccessibilityInfoFacilityEnumeration contains the value visualDisplays. However without context it is unclear what kind of information is provided and where the displays are located.
• The PassengerInformationEquipment does not allow the description of a display outside a vehicle showing its route and destination.
• The HeadingSign equipment can be used to describe destination displays, but it misses the location where the sign is mounted on the vehicle.

External announcements

• The AccessibilityInfoFacilityEnumeration contains the value audioInformation. However without context it is unclear what kind of information is provided and where.
• The PassengerSafetyEquipment can be used to describe automatic and on demand announcements, but when assigning it to a vehicle it is unclear if the information is outside or inside the vehicle.

Proposal

The goal is to model the described systems in two level of details. The existence of destination displays can be described via a facility and an equipment can be used to describe where the displays can be found including other details like font size. The existence of automatic vehicle route announcements can be described via a facility and an equipment can be used to describe none automatic announcements including how to trigger them and where they are audible.

External display and announcements via facility

Add additional enumeration values to the PassengerInformationFacilityEnumeration.

<xsd:simpleType name="PassengerInformationFacilityEnumeration">
  <xsd:restriction base="xsd:NMTOKEN">
    <xsd:enumeration value="nextStopIndicator"/>
    <xsd:enumeration value="stopAnnouncements"/>
    <!-- NEW START -->
    <xsd:enumeration value="destinationDisplay">
      <xsd:annotation>
        <xsd:documentation>An electronic sign mounted on the front, side or rear of a vehicle, that displays the vehicle's route number and destination.</xsd:documentation>
      </xsd:annotation>
    </xsd:enumeration>
    <xsd:enumeration value="routeAnnouncements">
      <xsd:annotation>
        <xsd:documentation>When the vehicle arrives, the route and destination are announced automatically over the vehicle's external loudspeakers.</xsd:documentation>
      </xsd:annotation>
    </xsd:enumeration>
    <!-- NEW END -->
    <xsd:enumeration value="passengerInformationDisplay"/>
    <xsd:enumeration value="realTimeConnections"/>
    <xsd:enumeration value="other"/>
  </xsd:restriction>
</xsd:simpleType>

The term destinationDisplay is derived from the existing element DestinationDisplay. Alternative terms for "destination display":

• "destination sign" ( wikipedia)
• "destination indicator"
• "destination blind"
• "route display" Alternative terms for "route announcements":
• "line announcements"
• "destination announcements"

External display via equipment

HeadingSign is used and extended by the additional property VehicleSide borrowed from DeckEntrance. This only requires adjusting the documentations of the VehicleSideEnumeration to be more generic instead of entrance specific. HeadingSign also has DestinationDisplayRef which allows linking to a DestinationDisplay. Alternatively create a special vehicle equipment e.g. DestinationSign or VehicleDestinationSign which extends HeadingSign.

Example for vehicle with front and side destination display

<Vehicle>
  <actualVehicleEquipments>
    <HeadingSign>
      <VehicleSide>frontEnd</VehicleSide>
    </HeadingSign>
    <HeadingSign>
      <VehicleSide>rightSide</VehicleSide>
    </HeadingSign>
  </actualVehicleEquipments>
</Vehicle>

External announcements via equipment

PassengerSafetyEquipment is used and extended by an additional property called AudioAnnouncementsScope of type AudioAnnouncementsScopeListOfEnumerations to depict whether the announcements are made outside and/or inside the vehicle.

<xsd:simpleType name="AudioAnnouncementsScopeListOfEnumerations">
  <xsd:list itemType="AudioAnnouncementsScopeEnumeration"/>
</xsd:simpleType>

<xsd:simpleType name="AudioAnnouncementsScopeEnumeration">
  <xsd:restriction base="xsd:NMTOKEN">
    <xsd:enumeration value="onBoard">
      <xsd:annotation>
        <xsd:documentation>The announcements are proclaimed to passengers inside a vehicle.</xsd:documentation>
      </xsd:annotation>
    </xsd:enumeration>
    <xsd:enumeration value="onSite">
      <xsd:annotation>
        <xsd:documentation>The announcements are proclaimed to passengers at a stop or station like passengers waiting at a platform.</xsd:documentation>
      </xsd:annotation>
    </xsd:enumeration>
  </xsd:restriction>
</xsd:simpleType>

An additional scope might be "onDevice" if a personal device acts as the speaker. An alternativ idea was to use a property called AudioAnnouncementsLocation with values like inside/outside or internal/external or indoor/outdoor or interior/exterior. However these values are only suitable for PassengerSafetyEquipment part of a vehicle. For PassengerSafetyEquipment part of a platform or station these values are ambiguous. The term "scope" is preferred to the term "location" as location in context of an equipment normally describes where the equipment is installed or where the audio is coming from and not where the audio can be heard.

Example for vehicles in Dresden where announcements can be triggered inside and outside the vehicle via specific device

<PassengerSafetyEquipment>
  <AudioAnnouncements>true</AudioAnnouncements>
  <AudioAnnouncementType>onDemand</AudioAnnouncementType>
  <AudioAnnouncementsTrigger>specificDevice</AudioAnnouncementsTrigger>
  <AudioAnnouncementsScope>onBoard onSite</AudioAnnouncementsScope>
</PassengerSafetyEquipment>

Discarded Ideas:

External display via PassengerInformationEquipment

Reuse PassengerInformationEquipment or alternatively create a special vehicle equipment extending the PassengerInformationEquipment. Add the VehicleSide property and reuse the new PassengerInformationFacilityEnumeration value destinationDisplay to depict that it is a destination display. PassengerInformationEquipment also has LogicalDisplayRef to reference a DestinationDisplay.

<PassengerInformationEquipment>
  <VehicleSide>
    frontEnd
  </VehicleSide>
  <PassengerInformationFacilityList>
    destinationDisplay
  </PassengerInformationFacilityList>
</PassengerInformationEquipment>

Resolution: Usually one would not describe a vehicle destination display as a passenger information display even though technically it is one. Therefore the HeadingSign seems to be a better fit than the PassengerInformationEquipment.

External announcements via HeadingSign

HeadingSign has an AudioTriggerMethod property. The respective enumeration contains the following values: "presenceDetector", "mobileApp", "internetPage", "specificDevice", "pushButton", "other". A value such as "automatic" could be added to the enumeration to model automatic announcements. Resolution: In reality the destination display of a vehicle usually does not provide the audio output in contrast to other stationary passenger information displays with audio output. Additionally at least technically the vehicle could have no destination display but destination announcements which couldn't be modeled via HeadingSign.

Model content of audio announcements

Add an additional property of type enumeration list to PassengerSafetyEquipment which could be called AudioAnnouncementsContents to describe what kind of information is announced. Possible values: route, nextStop, arrivals, departures, delay, disruptions, cancellations, platformChanges, safety, security. Resolution: It is hard to find a good set of fixed values. Also for most of the announcements on train stations almost all values have to be set. A new dedicated value for PassengerInformationFacilityEnumeration seems more suitable.