Closing elevators and other station infrastructure via SIRI(-FM?)
Leonard Ehrenfried
Hello,
I'm a developer of OpenTripPlanner and several people have approached me how I would implement the closing of elevators and other station infrastructure with a realtime feed.
My reply is usually that I would investigate how to do it with SIRI-FM and since I was asked yesterday again, I'm actually doing some investigation.
Is it as simple as doing this?
I'm a developer of OpenTripPlanner and several people have approached me how I would implement the closing of elevators and other station infrastructure with a realtime feed.
My reply is usually that I would investigate how to do it with SIRI-FM and since I was asked yesterday again, I'm actually doing some investigation.
Is it as simple as doing this?
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Siri xmlns="http://www.siri.org.uk/siri" xmlns:ns2="http://www.ifopt.org.uk/acsb" xmlns:ns3="http://www.ifopt.org.uk/ifopt" xmlns:ns4="http://datex2.eu/schema/2_0RC1/2_0" xmlns:ns5="http://www.opengis.net/gml/3.2">
<ServiceDelivery>
<FacilityMonitoringDelivery>
<FacilityCondition>
<FacilityRef>elevator-123</FacilityRef>
<FacilityStatus>
<Status>notAvailable</Status>
</FacilityStatus>
</FacilityCondition>
</FacilityMonitoringDelivery>
</ServiceDelivery>
</Siri>Ideally I would like to also say somewhere that it is an elevator ("lift" in SIRI languague) but I'm struggling to find a clear way of expressing that.
Or is this more of a use case for SIRI-SX?
cc
SIRI is to provide the update of the status of the EQUIPMENT, but not to describe the EQUIPMENT itself (which is only required once, and not at each updated).
The EQUIPMENT description itself is expected to be provided via NeTEx (see EPIAP - European Passenger Information Accessibility Profile - for the most detailed description).
However if you really don't have the NeTEx description, you can use the Facility description proposed by SIRI (but that is really a very simple summary... see below)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <Siri xmlns="http://www.siri.org.uk/siri" xmlns:ns2="http://www.ifopt.org.uk/acsb" xmlns:ns3="http://www.ifopt.org.uk/ifopt" xmlns:ns4="http://datex2.eu/schema/2_0RC1/2_0" xmlns:ns5="http://www.opengis.net/gml/3.2"> <ServiceDelivery> <FacilityMonitoringDelivery> <FacilityCondition> <Facility> <FacilityCode>elevator-123</FacilityCode> <Features> <Feature> <AccessFacility>lift</AccessFacility> </Feature> </Features> </Facility> <FacilityStatus> <Status>notAvailable</Status> </FacilityStatus> </FacilityCondition> </FacilityMonitoringDelivery> </ServiceDelivery> </Siri><!--First describe the location: -->
<Consequence>
<!-- 2nd consequence describes accessibiltity restrictions -->
<!-- After that you can start with a PublishingAction -->
FM: Facility monitoring, a view based on the actual facilities.
You could argue that FM is similar to VM. It is oriented around specific input data. Where as SX is a provided solution.
I meant more: are SIRI-SX message just "bits of text" that you attach to various enties or should the message that
Maybe the answer is that it's just data and the application can use it as it sees fit.
So your take is that SIRI-SX is for "passenger text" and SIRI-FM for actually making parts of the network unpassable?
I also want to share our Swiss approach even though Steffen did a great job of summarizing it.
On top level the affected pt element is always a stop place. The elevator is identified by its OpenStreeMap ID since this is the only "map" identifier known by all possible consumers. The FacilityName can be quite long, containing entraces, street names and important POIs (in this case simply the platform as it is sufficient for passengers to locate the facility):
The Consequence with the platforms where step free access is no longer possible:
The PassengerInformationAction with textual content in different "sizes" (short for displays with limited space and long for journey planner):
Cheers,
Adrian