Proposal talk:Wheelchair lifts and ramps on platforms

Opening times

I'd also propose to add opening times for the ramp, as they differ from the train station's opening times in Germany. Background: The train personnel isn't allowed to use the ramps for insurance reasons, and trained personnel must be at the station. You need to know the times when the train station is staffed with people who are trained to use the devices. I'd suggest "opening_hours:wheelchair:portable_lift" and "opening_hours:wheelchair:portable_ramp" for this. --Hypo808 (talk) 12:23, 11 July 2023 (UTC)

We agree. The only problem is that the opening hours are not always easily discoverable, therefore we were unsure if it would be a good fit for OSM. Tagging opening_hours:wheelchair=* at the public transport relation may also be sufficient. --OPENER (talk) 07:06, 12 July 2023 (UTC)

For most German stations, opening times are available as PDFs from DB Station & Service and DB RegioNetz Infrastruktur. You are right, opening_hours:wheelchair=* on the public_transport=stop_area or public_transport=platform makes more sense. Could we make this tag part of the proposal, as the info is essential to know if you can actually use a ramp/lift as a wheelchair user? --Hypo808 (talk) 09:21, 12 July 2023 (UTC)

We will add an information about opening_hours:wheelchair=* to the proposal defining when the portable lifts and ramps are actually accessible/usable. --OPENER (talk) 14:00, 10 August 2023 (UTC)

Excellent change to use better semantics service_times:*=* for specific needs, instead of potentially misleading opening_hours:*=* meaning of only those times allowed. I had suggested service_times:autism=* to replace opening_hours:autism=* and quiet_hours=* before. —— Kovposch (talk) 10:48, 11 August 2023 (UTC)

Format

Ver 1

Why not ramp:wheelchair:portable=* ? Do you have any other wheelchair:*=* feature-attributes in this style? —— Kovposch (talk) 12:34, 11 July 2023 (UTC)

The main reason is that ramp:wheelchair=* is used for a stationary ramps build near stairs while the proposed tag is used for a moveable/portable ramp usually located at platforms. They are quite distinctive objects even though they provide a similar functionality. We also use wheelchair:lift=* at highway=steps for stair lifts. We considered our tag to be like wheelchair=description just in a more specific machine readable way. Still I see why you may favour your approach. --OPENER (talk) 06:59, 12 July 2023 (UTC)

Ah yes, I forgot where that is. I can't find the English page for wheelchair:lift=* . Have you considered https://community.openstreetmap.org/t/how-to-tag-wheelchair-lift/92137 ?
wheelchair:*=* is not consistent, as it may be interpreted as detailed accessibility in different features under wheelchair=* together with wheelchair:description=* . This overlaps with *:wheelchair=* eg toilet:wheelchair=* . It's not always reliable or intuitive to use the namespace sequence for different meanings.
wheelchair:lift=* may be mistaken as small, short vertical platform lifts designed for wheelchair only. The standard industry term seems to be inclined platform lift. The word is confusing against "elevator" already used in highway=elevator and elevator=* with different meanings. https://www.savaria.com/products/v-1504-unenclosed-vpl https://www.transitionsmobility.com/products/vertical-wheelchair-platform-lifts/commercial-and-residential-outdoor-and-indoor-vertica
I would consider solving platform gap fillers together. Some are tight enough for wheelchairs. https://www.delkorrail.com/images/pdf/17-DELK-0119_PGFBrochure2017_Spreads-For-Web.pdf
Since there is railway=platform_edge , I suggest platform_edge:*=* on the *=platform . This allows platform_edge:wheelchair=* to be used for the wheelchair=* accessibility of the platform gap specifically. The lifts and ramps can be implicitly understood as portable here.

• wheelchair:portable_lift=* → platform_edge:lift=*
• wheelchair:portable_ramp=* → platform_edge:ramp=*
• platform_edge:gap_filler=* : Platform gap fillers (can be extended to platform_edge:door=* and platform_edge:gate=* for platform screen doors and gates, important for preventing wheelchairs from falling down to the track too)

The solution of wheelchair:lift=* depends on whether VPL and IPL are considered highway=elevator and elevator=* . IPL looks similar as a small elevator. Full-sized inclined lifts is also drawn as a Tag:highway=elevator#How_to_map_as_a_way line. The mentioned stair_lift=* is still not clear on vertical vs inclined. platform_lift=* as platform_lift=vertical or platform_lift=inclined could be a usable sub-feature attribute on highway=steps , but eg highway=platform_lift may not be an acceptable alternative to highway=elevator for drawing VPL separately.
—— Kovposch (talk) 11:44, 12 July 2023 (UTC)

Thanks for your extensive thoughts. Just as a summary, your tagging scheme would look like this, right?

railway=platform

public_transport=platform

platform_edge:lift=*

platform_edge:ramp=*

platform_edge:gap_filler=*

I'm personally not a big fan of the term "platform_edge" as lifts are sometimes needed to overcome a vertical gap which isn't necessary caused by the platform edge bur rather by the train/vehicle itself. Maybe we could reuse and build upon entrance:ramp=*? Or form a new tag like boarding:ramp=* and boarding:lift=*?

"This allows platform_edge:wheelchair=*"

The problem with wheelchair=* is, that it makes a lot of assumptions. For example if the entrance is wheelchair accessible heavily depends on the vehicle. Therefore it is far more useful in our opinion to rather map individual properties, like height, the distance from the platform to the middle of the tracks (which we haven't figured out yet how to tag) or the existence of features that assist getting in and out of the vehicle.

Regarding wheelchair:lift=*: when we looked it up it was already more common than stair_lift=*. Also previously such scenarios where sometimes tagged with wheelchair=yes + wheelchair:description=* on stairs. wheelchair:lift=* would again serve as a more detailed and machine readable description why these stairs are wheelchair accessible. I can see though, that a broader tagging approach (like it is done for ramps) could be preferable. For example lift=* + lift:wheelchair=*. Using lift=separate they could be mapped as way with highway=elevator. We prefer the term lift instead of elevator as it seems to be commonly used to describe "smaller elevators" like stair lifts (https://en.wikipedia.org/wiki/Stair_lift)

We also thought about distinguishing between vertical platform lifts (VPL) and incline platform lifts (IPL). We decided for now that it isn't of any importance, since both serve to overcome the stairs. I'd also argue that their accessibility depends on the same properties: dimensions and maxweight. We did not include it in this proposal because we felt that portable and stationary lifts/ramps are two distinct things.--OPENER (talk) 07:31, 14 July 2023 (UTC)

• platform_edge:*=* : Reason is lift=* , ramp=* , and gap_filler=* would logically be added to the railway=platform_edge when that is drawn. You use toilets:wheelchair=* not washroom:toilets=* , when it will be amenity=toilets + wheelchair=* . The "edge" is the edge, not exactly the gap. It's the boarding & alighting location, where the gap, and the level difference are formed. So train level difference should be recorded there.
• platform_edge:wheelchair=* : That's only an idea how it could be used. Can be ignored if undeterminable.
• Centreline distance: This is more complicated, as there will be a varying gap on curves. It will need to have min and max.
• wheelchair:lift=* : Problem is there are other out-of-order formats suffixed directly. Eg wheelchair:places=* (48×) / wheelchair:capacity=* (6×), wheelchair:beds=* (0×), wheelchair:rooms=* (51×) from wheelchair:description=* places , wheelchair:description=* beds , wheelchair:description=* rooms would theoretically be capacity:wheelchair=* (106×), beds:wheelchair=* , rooms:wheelchair=* (7×). Seems inappropriate to adopt it.
• lift=* : Issue is elevator=* is already used. Introducing a new overlapping synonym will be difficult.

I left my related comments about wheelchair:lift=* here as I can't find the proposal page.
—— Kovposch (talk) 11:24, 14 July 2023 (UTC)

The proposal was updated. It would be nice if you could review it again and give us your thoughts. --OPENER (talk) 15:25, 18 July 2023 (UTC)

Ver 2

• platform_lift=incline : Use the adjective platform_lift=inclined from "inclined" platform lift to prevent misunderstanding as incline=*
• platform_lift:length=* + platform_lift:width=* : Will be longer, but should use platform_lift:maxlength:physical=* + platform_lift:maxwidth:physical=* to align with maxwidth:physical=* elsewhere. platform_lift:length=* makes it appear to be how long the lift can extend into the train across the gap when the landing ramp is unfolded.

--- Kovposch (talk) 10:40, 20 July 2023 (UTC)

Thanks. We will change it to platform_lift=inclined.

Looking at the tags without further context and using the existing wiki definitions you are right.

However currently for e.g. door=* the width=* (or height=*) tag is used to describe the clear width. I also assume that people who measure the width of a stationary ramp measure it between the handrails. So one could argue it depends on the context and definition whether width=* or maxwidth:physical=* should be used. For the platform lift the surrounding parts can be seen as a railing similar to the handrail of a ramp or stairs.

Do you nevertheless prefer the maxwidth:physical=* version?

--OPENER (talk) 15:02, 20 July 2023 (UTC)

I suppose door=* is referring to the door leaf, not the whole assembly. It can be installed with a frame, or wall opening directly; but we refer to the moving door itself So there is only one set of dimensions.
You are already using platform_lift:maxweight=* . It seems uniform to use platform_lift:max*=* for others.
—— Kovposch (talk) 05:20, 21 July 2023 (UTC)

Thank you for bringing that to our attention. We changed it in our proposal to platform_lift:maxlength:physical=*, platform_lift:maxwidth:physical=* and ramp:maxwidth:physical=*. --OPENER (talk) 07:42, 21 July 2023 (UTC)

• platform_lift:seat=* : I realize a question. Will this be confused with fixed chair only, no wheelchair platform stair lifts? Those are not even platform_lift=yes ??? https://www.ameriglide.com/item/AmeriGlide---Rave-2.html

—— Kovposch (talk) 05:30, 21 July 2023 (UTC)

Yes, the proposal doesn't include "chair lifts" (not to be confused with https://en.wikipedia.org/wiki/Chairlift), partly because we believe that they are never really used in public spaces as they aid a smaller "group" than platform lifts. On the other hand we favour a generic platform_lift=* tag that is agnostic about the feature it belongs to over a generic stair_lift=* tag which could be agnostic about the type (chair or platform) but not the feature it belongs to (stairs). This way the tag can be reused elsewhere like on public transport platforms. Unfortunately we couldn't find a picture for platform_lift:seat=* with an appropriate license yet.

--OPENER (talk) 11:11, 24 July 2023 (UTC)

Tagging on the platform vs. tagging the lift/ramp objects with their position as nodes

Do you have a rationale why this tagging should be on the platform vs. adding the objects (lifts/ramps) as additional nodes on top of the platforms so we also have their positions? The positions could help organizing mobility services and in emergency cases.

I ask this because I have just asked some wheelchair users about what you need to know about lifts/ramps and they came up with more properties that would have to be copied/proposed as new keys to match this proposal.

For example, a lift (mapped as an extra node) can have

• access=public / access=employees / access=permit (most lifts in German stations are only available if there is trained staff, this can be different in other countries)
• centralkey=*
• manufacturer=*
• operator=*
• model=*
• brand=*

…and so on, which wouldn't work for a lift tagged on the platform. What do you think? --Hypo808 (talk) 09:39, 12 July 2023 (UTC)

One reason is that these features are portable. Even though there may exist "parking areas" or common places for portable lifts it is not certain that they will actually be there. We initially feared that it may not even be a good fit for OSM due to their portable nature. However we believe that they are still bound to a platform which itself is a stationary object so they are somewhat a property of the platform (like a passenger information display). I can see though why one would treat them similar to emergency=defibrillator. Additionally the overall intention of the scheme is to detail the broad wheelchair=* tag for platforms.

The tags you describe mostly do not impact accessibility. As far as I know centralkey=* only applies to stair lifts. At least I can't think of a reason why a portable lift would be locked with a central key. I can see why someone would be interested in the properties, but the goal of our tagging scheme is not to map these objects in all their detail. Instead we are interested in their existence and accessibility related properties which ultimately contributes to the accessibility of the platform. --OPENER (talk) 07:59, 14 July 2023 (UTC)

Link with On Wheels app tags for wheelchair users

Hi with On Wheels we are working on similar tags for wheelchair users. We are looking for tags to indicate a ramp at an entrance of a building. For the moment we have entrance:ramp, but if you will use ramp:wheelchair we should change our tag to entrance:ramp:wheelchair. So it would be good to use the same tagging for portable ramps/lifts and fixed ramps/lifts. Our app would be able to use these tags on our public transport tags.

My gut feeling about this is, that it would be best to re-use the ramp=yes and ramp:wheelchair=* tags on entrances entrance=*. Because these tags indicate that there is a ramp somewhere nearby. Not sure what the benefit or reason for entrance:ramp=* is. Nevertheless I agree that we should aim for a consistent tagging scheme. --OPENER (talk) 09:50, 14 July 2023 (UTC)

Drop platform_lift=* in favour of a tag for stairs in general?

I'm doubting whether a specific tag for lifts carrying wheelchairs up stairs on platforms might be overly specific. These lifts are not only built at platforms but may appear at any type of stairs, as the photos you have used to illustrate such lifts show. Thus, I would suggest to drop platform_lift=* in favour of something like elevator:wheelchair=* in combination with highway=steps. This solution would also allow us to map which stairs are equipped with a lift, if there are multiple stairs leading to a platform.--Grimpeur78 (talk) 14:35, 22 July 2023 (UTC)

As emphasized, "platform" in platform_lift=* refers to the wheelchair-carrying platform of the lift. That's the standard term used.
We have discussed whether vertical platform lifts are considered elevators. While the version now is acceptable, I'm still half-decided on this.
However, you need to consider platform_lift=inclined included here. This requires more work to show in elevator:*=* . highway=elevator represents this by being a line. Again, are they elevators?
Although there is the precedence of ramp:wheelchair=* , *:wheelchair=* fundamentally is not ideal, as it usually means *=* + wheelchair=* a la toilets:wheelchair=* accessibility. Unlike ramp=* , all commonly considered highway=elevator are defined as wheelchair-capable. Using elevator:wheelchair=* for wheelchair-dedicated lifts is then redundant and unclear. Would elevator:bicycle=* be referring to a bike elevator (maybe in bike parking garage), or elevator allowing bikes? In fact, identical inclined platform lift has been advertised for bikes. https://www.hydro-con.dk/en/products/customized-products/bicycle-lift-or-elevator
There are 10 elevator:wheelchair=yes that needs to be checked. Maybe it means whether it has lower wheelchair-height buttons? Plus, 1 elevator:wheelchair=limited interestingly.
—— Kovposch (talk) 06:14, 23 July 2023 (UTC)

I forgot to mention platform lifts are not only for wheelchairs. For platform_lift:seat=yes , the chair is intended for mobility-impaired people who don't use a wheelchair, but still find stair difficult. Wheelchair user obviously won't use it, remaining seated in the wheelchair.
Aside from bikes, platform lifts may be used by strollers and perhaps other devices as well, depending on their rules or staff availability. Framing it for wheelchairs is again not universal.
—— Kovposch (talk) 10:17, 24 July 2023 (UTC)

New example

I'm worried the added paragraph and last photo about highway=elevator will be controversial. It seems contradictory to the 4-point differences of platform_lift=* to elevator=* . To be conservative, I feel there will be less disagreement if not suggesting what feature should be used when drawn separately. Otherwise, there needs to be eg elevator=platform_lift + platform_lift=* to show there's no standard elevators, only a IPL or VPL. —— Kovposch (talk) 10:43, 11 August 2023 (UTC)

Ramps are a feature of trains, not stations

Whilst there are ramps at large staffed stations, by tagging these this proposal implies that only large stations with ramps are wheelchair accessible. This is not the case.

The vast majority of stations have no staff however this should not imply that these stations are not accessible as the ramp is not a feature of the station but of the train.

Trains carry ramps and if someone needs to use them the guard puts it into place and assists the passenger, much like a bus driver will with ramps included on buses.

I don't see how tagging ramps or platform lifts on stations/platforms implies that only these platforms are wheelchair accessible. We explicitly state that there are a lot of factors, foremost the vehicle, that come into play when defining something as accessible for wheelchair users. You cannot deduce accessibility from a platform alone. You can only deduce accessibility for a specific route taking into account the vehicle properties, platform properties and the persons disabilities.

--OPENER (talk) 07:41, 14 August 2023 (UTC)

Why limit to public transit?

Is there a reason why these tags should not be used for places other than public transit? For instance, "pre-accessibility" buildings may be augmented with a ramp that is not at the same place as the main entrance, and that would be useful to know for someone who seeks to use it. --JOlshefsky (talk) 13:47, 23 August 2023 (UTC)

We don't really limit these tags to public transport. The platform_lift=* tag on stairs is supposed to be mapped anywhere in the world similar to the already existing ramp=* tag. We only specify that portable ramps and portable platform lifts located at public transport stops should be mapped using the same keys/schema (adding :portable=yes).

--OPENER (talk) 14:26, 25 August 2023 (UTC)

Should ramps indicate a slope?

The American Disabilities Act (ADA) compliance has a lot of specifications that make a proper accessible ramp; I assume these rules were made to ensure what people with limited mobility can expect, and to include as many of those people as reasonably possible. One of them is that the slope be no more than 1 unit rise per 12 units horizontal length (one inch per foot in Freedom Units™ ;) ). There are some ramps—particularly short ones that span about one step—that are steeper than this, or ones used for equipment carts and not specifically for wheelchairs.

I'm not sure how to specify it so the average user can enter the information. For people like me who know a little about the ADA rules, I can distinguish ramps that are very likely to be compliant (about 1m wide, shallow slopes, railings, etc.) I'm rambling a bit, but I don't know whether a subtag for slope ratio (e.g. 1:12 or 1:10) would be preferable to "compliant" or "primary purpose is for wheelchair/limited mobility access". --JOlshefsky (talk) 13:58, 23 August 2023 (UTC)

If you are talking about stationary ramps, then the slope can already be defined using the incline=* tag. For portable ramps the slope is undefined (or variable) since it depends on the height of the step the ramp is used on and the ramp's length. That's also why we ask for the ramp's length value, so at least in theory the slope can be calculated when knowing the height difference.

--OPENER (talk) 14:26, 25 August 2023 (UTC)

Post voting

Switching from ramp:* to ramp:portable:* - status?

How do we deal with the fact that the vote was on ramp:length=*, ramp:maxweight=*, ramp:maxwidth:physical=*, and ramp:supervised=*, which was later changed and should actually be called ramp:portable:length=*, ramp:portable:maxweight=*, ramp:portable:maxwidth:physical=*, and ramp:portable:supervised=* post voting. Strictly speaking, the changed keys are not accepted and, on the other hand, the accepted ones are outdated. Does a second vote need to be done? --Chris2map (talk) 21:01, 29 February 2024 (UTC)

As we stated in the suggestion for deletion reasoning: After the acceptance of https://wiki.openstreetmap.org/wiki/Proposal:Wheelchair_lifts_and_ramps_on_platforms we created the respective wiki pages, but a mistake slipped through. For example "ramp:length" and similar keys are ambiguous on their own. So to match the ramp schema the ":portable" subkey has to be added in between. Otherwise it is unclear to which ramp type the features belong.

Even though the slightly modified keys aren't particularly approved, they are more in line with the already existing schema in opposite to the originally proposed keys. Therefore we don't think a second vote needs to be done. Maybe a hint can be added to the proposal, to avoid confusion. --OPENER (talk) 16:13, 13 March 2024 (UTC)