Call Button height may vary in different levels
Closed this issue · 13 comments
Hi there,
while modeling a small german station we came across a thought, that the call button height may vary from level to level. The problem with the current CallButtonHeight is that it can only be assigned to a lift equipment while we would prefer to assign it to an EquipmentPlace where the lift is referenced, which for our understanding resembles the location where you can enter and there fore also call the lift.
Can you give any advise on how to handle this topic?
Could, perhaps, a minimalist solution suffice - re-defining CallButtonHeight as the maximum height of the call buttons of all levels? Reaching a button that is too low is almost always possible.
Is this kind of unusual situation something that we want to model ? I would personally favour notices or detailed description in such case... there will always be some rare uncovered case (for example no call button at a specific level for some security reason, etc.), and that's where notices and descriptions are highly important.
I would not have a problem to have the external call button on the SiteElement as well (because this is were it is).
The following idea came to my mind during the discussion in the meeting this morning: Adding one or more AccessibilityRefinement to an EquipmentPlace with the functionality of overriding values of an Equipment. This would be applicable to the lift button as well as to the door handle problems. Depending on the EquipmentPlace from which one approaches the lift, entrance, escalator, etc., a different button height or handle type could be specified.
<xsd:complexType name="AccessibilityRefinementType">
<xsd:annotation>
<xsd:documentation>Type used for adding or overriding accessibility information of an Equipment.</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:sequence>
<xsd:element name="EquipmentRef" type="EquipmentRefStructure" minOccurs="1"/>
<xsd:element name="EquipmentPlaceRef" type="EquipmentPlaceRefStructure" minOccurs="0">
<xsd:annotation>
<xsd:documentation>The EquipmentPlace from which the Equipment is approached.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="ElementName" type="xsd:NMTOKEN" minOccurs="1"/>
<xsd:element name="ElementValue" type="xsd:NMTOKEN" minOccurs="1"/>
<!-- Rest not really needed -->
<xsd:element name="MaxHeight" type="LengthType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Maximally necessary height to operate the element.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="MinHeight" type="LengthType" minOccurs="0"/>
<xsd:element name="WayIn" type="xsd:boolean" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Whether the Equipment, accessed or approached from the current EquipmentPlace, is on the way from the outside towards a quay and a vehicle. Not sure whether this is really useful (entrances, stairs, lifts, etc.).</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="WayOut" type="xsd:boolean" minOccurs="0"/>
</xsd:sequence>
</xsd:complexContent>
</xsd:complexType>
The advantage of the extra element that has the button is that there is a topological relationship towards the executed actions.
As a workaround you could specify a different LiftEquipment instance on each floor , and give it different values for the call height etc . But a clearer solution would be to add a separate LiftCallEquipment that had just the relevant attributes
e,g, for the following NeTEAx UML
For me it is ok.
If we go with the LiftCallEquipment solution, then it would seem logical or consequent to me to take a similar approach for the additions proposed in #555. That could mean: (A) Instead of the OtherExitDoors one would have something like DoorPositionInCabin, which could be added to the LiftCallEquipment; (B) A new EntranceDoorHandlingEquipment with a DoorHandle element would cover the cases when handles differ between the two sides of the door (and perhaps as well to indicate if an entrance can only be used in one direction).
I think the decision should just take into consideration that broader context.
The LiftCallEquipment sounds good to me, as long as the CallButtonHeight stays in place, so that in 99 percent of lifts we do not need to generate another element for each lift and level. Duplicating the LiftEquipment would create all kinds of practical problems, so we should definely not do that. And yes. it would only be consequent to introduce EntranceDoorHandlingEquipment.
I see that we don't want to wait for the merge of the PR, so I close the issue.