On platforms, highway=platform or man_made=pier. If the platform or pier is mapped as an area, only if you draw a separate way for the tactile lines. If the platform or pier is small and mapped as a way, add tactile_paving=yes to the way.
[…]
Use on areas
tactile_paving=yes is not used on areas.
So as I interpret it, not apply tactile_paving=yes to an object with area=yes, e.h. highway=platform with area=yes.
And finally, the app “Street Complete enhanced edition” (SCEE) also asks me about the tactile paving on the platform: I just removed the tag from this platform (it is mapped as a separate way as well in this particular case (but the discrepancy I ask about here is also about cases where there is no separate mapping), but with no logical relation to the platform except that it lies within) in accordance with the wiki page Key:tactile_paving, and promptly SCEE asks me “Does this stop have tactile paving?” for this platform. ( Raised this issue here at StreetComplete, too.)
I’m not one of the authors of the proposal, but for background, I voluntarily worked in a blind school for 3 years in the past.
My assumption is that the reason, not to put tactile_paving=* on areas, is that the information is only really useful on ways, and the only interpretative information would be “there is some sort of tactile paving, somewhere here”, but now exactly showing where.
For platforms mapped as an area, I’d say the best option would be to have a highway=footway way in addition to the platform area, that can then be used for routing, both blind and non-blind people, much like it’s common for pedestrian roads mapped as areas.
I think both options (tactile_paving=yes on railway platform / tactile_paving on a separate way) have their benefits and should not be considered mutually exclusive.
Surveying whether a public transport platform has tactile paving is pretty basic and easy (that’s why it is included in StreetComplete). This tag is already helpful on its own, for instance, to help a visually impaired person plan a public transport route. The information whether tactile paving is present at a platform is easy to evaluate and render on a map. It may even be sufficient for this person to navigate the surroundings on their own (that’s why we put tactile elements on the floor, ultimately). More detailed tagging of the exact location of those tactile elements may be even better, and can help to support more demanding applications like a specialized router for blind people (as mentioned above)
I think it is great to have specific information in OSM, but this should not come at the “expense” of basic tagging that is simple to understand, survey, and use. So, in general, I’d say: Always tag tactile_paving on the platform, and if you like, also add more specific information to separate ways. (This is similar to how detailed mapping of building:parts also preserves a simple building outline, or why we tag bench=* on a public transport stops while also allowing for more detailed separate amenity=bench nodes.)
I feel like it mostly boils down to the fact that it’s a property of public_transport=platform which on its own is quite generic since it can appear as a node, way and area and doing allows data consumers to easily see which platforms have tactile paving and which don’t. It’s particularly notable when you consider that you can use it to denote that tactile paving exists on the platform but not at its edge e.g. a bus stop has some tactile paving installed but only among the way; the barrier=kerb at the bus stop has a smooth surface instead.
Especially, for railway/bus platforms where it is being asked and tagged by StreetComplete, it is often the case that those are long thing areas (E.g. overpass turbo) so they are usable even for direct blind navigation (GPS error in urban areas is unfortunately often worse than those 2-3m which is how wide those areas often are, so they often can be considered lines for practical purposes)
Of course, if we were talking about much larger areas like marketplaces (like earlier revisions of wiki did e.g. “If you have a large area (like a market place) with indicator lines across, draw separate ways for the tactile paving and map on ways”), then it it less usable for such purpose.
But note that direct on-the-ground router for blind persons is not the only consumer of tactile_paving data. As noted above, it can be used for planning purposes, but it also interesting for e.g. evaluations how accessible transport network is in certain cities, where improvements are needed etc.
All that being said, yes, as I noted in SC #6232, I would definitely encourage to add specific highway=footway + tactile_paving=yes where there are missing.
But that need not came at the expense of having it on public transport platforms too. (and if the specific data consumer of tactile_paving does not handle areas, it is no worse than if the data was not tagged at all).
I’ve tried to summarize and clarify in the wiki, linking to this discussion. Feel free to further improve on it!
Raised this issue here at StreetComplete, too.)