This proposal aims to establish a unified way of how to tag the dimensions of an elevator.
https://wiki.openstreetmap.org/wiki/Proposal:Elevator_dimensions
Please discuss this proposal on its Wiki Talk page.
Can you explain how they are defined for elevator with multiple doors on adjacent side (not opposing)? And non-rectangular elevators?
I added a section about that. 
Thanks for your feedback.
Ok sorry, I see the diagram. But have you considered how elevators can have multiple panels? This is besides lower ones for wheelchairs. They are found in elevators with multiple doors. Assuming elevators without floor buttons (controlled at lobby) have 1 control panel.
Also, the panel can be found at the corner Reddit - Dive into anything
To define circular etc elevators, and possibly remove the need for 2 dimensions on square elevators, something should be proposed for their shape.
Maybe just define length as the longer side and width as the shorter side for the corner case where the doors are not opposite each other. If they are equal it doesn’t matter and if they aren’t there’s no complicated logic involving the button position required. Referencing the length/width to the button position doesn’t really gain you any benefit if you have no idea where the buttons are located in relation to everything else
I think just having two width/length tags with the same value is the simplest solution for square elevators. You don’t really gain any benefit and only introduce more corner cases and complexity by introducing something like shape=square / square=yes. The amount of tags is the same, but there’s a lot more logic involved to process the information.
1 Like
What might be interesting to consider is different door widths and door types at different floors. I think I’ve encountered old retrofitted elevators where the door at the ground floor was a simple automatic sliding door for both the outside door and the elevator cabin door, but some of the outside doors on the upper levels were swing doors that did not automatically open and had to be pushed open manually. This might be a bit too specific and rare though.
The door type of the elevator would definitely be interesting for users and as far as I can tell is not yet specified for elevators. This could be as simple as noting that the already existing door=* tag can also be applied to elevators.
What is still missing is the maximum height of the door. People who transport furniture, for example, are happy to know the clear height of the doors.
What I was thinking is whether to allow eg radius= and diameter= for circular ones. Ellipse/oval ones can keep using length= + width= for the major and minor axis. There is a separate appeal to show bullet/capsule shaped glass elevators in the architecture.
Will be easier to say these ideas belong to door:*= , and not handle them here. Keep this focused on the elevator cabin. At the same time, there is nothing big to argue about how to apply length= and width= on rectangular ones.
That said, “depth” is a common and standard professional term for the length= , and won’t be misunderstand as the long side. On the other hand, depth= is used for the vertical dimension in water, or perhaps a container.
and next idea would be catering for elliptical shapes or rounded corners:
Maybe it’s easier to say wheelchair=yes/no
1 Like
I thought this is related to an unsorted group of ideas to be more specific than wheelchair= Proposal:Accessibility - OpenStreetMap Wiki
Theoretically, won’t be unacceptable to introduce some sense of chamfer or fillet for these. Then in all seriousness, there are glass elevators with round end-caps (rectangle + half-circle).
Just another angle on this. There are many hundreds of elevators in train stations in Italy. Many of them are unable to carry bicycles to the platforms. Some of them do if you put the bike diagonally. Hence I would appreciate also a diagonal measure.
(Not joking - this a real practical problem for intermodal transport. It took s lot of lobbying to get space fore bicycles on the trains, but unfortunately, the standard train station elevator is too small for a normal bicycle)
1 Like
I should be implicit with width and length (plus the information
whether the corners are rounded. Simply add the rounding radius.)
1 Like
If we would go this path then length should define the longer side and width the lower side for all cases (not just the special case). Because as a data consumer you don’t know anymore whether it is a special case or a none special case.
We decided against that in order to keep the common understanding of “width” and “length” intact.
Since the buttons are usually on the side/next to the door, the “button rule” also holds true for most ordinary elevators.
I agree that the door type can be interesting. Though for outside doors I would suggest mapping a separate door node with the respective type. This especially solves the problem when having different types on different floors.
While I would like to solve the problem for circular, elliptical or bullet shape elevators there will always be special cases like:
- Reddit - Dive into anything
- https://5.imimg.com/data5/XS/YU/MY-3306309/capsule-glass-elevator-500x500.jpg
So I would consider rounded elevators as special cases as well. Elevators with non rectangular shapes can still be mapped as an area.
1 Like
As some of you have pointed out the proposal does not support circular or rounded elevators.
What do you think about re-using the following keys to cover at least some of those cases?
This would cover:
- circular elevators
- elliptical elevators
This still wouldn’t cover:
- half ellipse + half circle
- rounded corners of a rectangle
- any n-gon shapes other than squares/rectangles
Obviously not all conceivable shapes can be covered via tagging. I created a poll, to get an overall consensus about which shapes should be representable by the tagging scheme and which should rather be mapped as an area.
Which shapes should be representable by the tagging scheme?
- recentgular
- circular
- elliptical
- semi circular
- semi elliptical
- rectangular with individual rounded corners (covers bullet shape)
- other n-gonal shapes
- other n-gonal shapes with roundings
0
voters
Tagging different door types via separate nodes is probably the easiest solution and doesn’t require any changes to tagging schemes. Specifying that door=* tags can be added to the elevator object for the normal elevator door would still be beneficial though.
I would be careful to not make the 99% case more complicated for the sake of very rare outliers. Adding shape=round + diameter=* is not too complicated and seems fine. The default should still be assumed as rectangular though so that shape=* doesn’t have to be added every single time.
Most other cases can probably be reasonably approximated via those methods. OSM tags are not a precise geometric modeling language. If there really is a need to specify the dimensions for some other arbitrary shapes in the future, those can be added in a different proposal.
1 Like
See, I was getting around to thinking that we’d map the elevator tracks as rail-based public transport, albeit with vertically stacked stop positions. That would keep us from having to map elevator cars at all, regardless of shape, since we don’t normally map vehicles unless they’re inoperable and completely stationary.
I have added height= and door:height= to the proposal to address your concerns.