[RFC] Feature Proposal - Elevator dimensions

[IanH]

@Minh_Nguyen

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.

If you figure out their schedules. I would just treat them as a room on each floor. Except that room is able to move between floors.

@wielandb-paid

have added height= and door:height= to the proposal to address your concerns.

Door height might be useful. Though do we care about the elevator itself.

[Minh_Nguyen (Minh Nguyễn)]

@IanH

@Minh_Nguyen

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.

If you figure out their schedules. I would just treat them as a room on each floor. Except that room is able to move between floors.

No need, we have interval for those that operate on a schedule, and for the majority that don’t, button_operated=yes is sufficient. We can map a route=railway relation for the physical infrastructure but need not map a route=elevator relation for the service that runs on it.

OK, I’ve had enough fun. There’s little sense in mapping a vertical feature as a thoroughfare of any sort anyways.

Candid Camera Classic: Sideways Elevator!

[IanH]

@Minh_Nguyen

we have interval for those that operate on a schedule, and for the majority that don’t, button_operated=yes is sufficient.

I assume that cover the edge case of it running a Shabbat schedule. Basically stopping at every floor so no one has to press a button.

[OPENER_next]

Hi everyone, I just wanted to give an update regarding the proposal.

We finished addressing most of your points and concerns in the proposal.
Especially we:

• added mapping guideline for specially shaped elevators
• reworked the mapping of elevators with adjacent doors
• added mapping guideline for the special case where an elevator has a different (outer) door on a level
• created some graphics to better illustrate some edge case mappings

Let us know what you think.

[Kovoschiz]

While area is an interesting exploration, I should have suggested not including it. =elevator needs to be a point (or line for inclinators) to be usable in routing. indoor=room was already suggested for it, although I find it weird for shafts and stairwells.

[OPENER_next]

It is not like we are really proposing something new in this case. Elevators are already mapped as areas and the wiki also states this. What we really do is to further specify what the area describes and how to map it so it actually works for routers.

While I see that data consumers have a slightly easier job with nodes, areas shouldn’t be a problem for them. Routers can either route along the way like they already do for pedestrian areas (it would basically work like routing along an inclined elevator). Alternatively they can also simplify the elevator area to a node in the preprocessing (which is what I would do).

Also we do not recommend mapping them as areas, they are just an alternative way of mapping for certain scenarios.

[Woazboat]

As a side note: Some routers do not support routing over highway area edges. Valhalla is the most prominent example, not sure about others.

Elevators mapped as areas should be tagged with area=yes to keep in line with the rest of highway=* and to differentiate them more easily from linear elevators.

[Tordanik (Tobias Knerr)]

The proposal currently has a small contradiction with Simple Indoor Tagging regarding door mapping. In SIT, the only required tag for a door node is door=*. In contrast, the proposal considers door=* optional, and instead requires indoor=door (which is not mentioned in SIT).

The outer door should be connected to either the inner door or the elevator via a highway=footway;path .

I assume you mean either highway=footway or highway=path, rather than actually using a semi-colon separator in the value?

Thank you for putting the work into specifying elevator mapping to this level of detail!

[OPENER_next]

Thanks for your feedback.

The proposal currently has a small contradiction with Simple Indoor Tagging regarding door mapping. In SIT, the only required tag for a door node is door=*. In contrast, the proposal considers door=* optional, and instead requires indoor=door (which is not mentioned in SIT).

That is true. We were following wiki pages like https://wiki.openstreetmap.org/wiki/Key:indoor and especially Key:door - OpenStreetMap Wiki where door is described as a key to further specify a type but not to map a feature on its own. At the end we do not have a strong opinion on that but I feel it is better to align with the door wiki page.

I assume you mean either highway=footway or highway=path, rather than actually using a semi-colon separator in the value?

Yes, you are absolutely right. I Fixed it. Thanks!

[OPENER_next]

Elevators mapped as areas should be tagged with area=yes to keep in line with the rest of highway=* and to differentiate them more easily from linear elevators.

I agree. We will update the wiki. Thanks!

[Minh_Nguyen (Minh Nguyễn)]

@Woazboat

As a side note: Some routers do not support routing over highway area edges. Valhalla is the most prominent example, not sure about others.

As far as I know, none of the major routing engines can route through an area. OpenTripPlanner and Per Pedes Routing do support routing through areas, though few if any OTP deployments enable it due to performance concerns. This issue has a running list of the issues tracking support in various routing engines.

[Woazboat]

Yes, pretty much no major router can route through an area. What I meant is that Valhalla also refuses to route over the area borders like other routers do in that case.