Call Button height may vary in different levels

[jomes-db]

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?

https://github.com/NeTEx-CEN/NeTEx/blob/7a1af73cf6060c813c0be272fd77a2eaabf821d7/xsd/netex_part_1/part1_ifopt/netex_ifopt_equipmentAccess_version.xsd#L843

[trurlurl]

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.

[Aurige]

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.

[ue71603]

I would not have a problem to have the external call button on the SiteElement as well (because this is were it is).

[trurlurl]

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>

[skinkie]

The advantage of the extra element that has the button is that there is a topological relationship towards the executed actions.

[nick-knowles]

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

[ue71603]

@Aurige @skinkie @trurlurl If you give a clear indication, if you the LiftCallEquipment is ok. Then @trurlurl and I could model it.