Talk:Key:tactile paving

use british English

"Curb" is AE, in BE use "kerb". Please change this in the whole wiki where you can find it for consistency reasons. -- Dieterdreist 12:16, 21 September 2010 (BST)

Needs further clarification

I couldn't understand how to tag a street (e.g. highway=primary). Do I really need to map the sidewalk as a separate way to tag it as tactile_paving? If not, then how can I specify the left sidewalk has tactile paving, while the right one does not? --Jgpacker (talk) 11:26, 10 February 2014 (UTC)

Update: I'm using tactile_paving:left=yes and similar to do this. --Jgpacker (talk) 18:44, 9 September 2014 (UTC)

tactile paving only on one side

If the crossing only has tactile paving on one side, how should this be tagged? `no`, `incorrect` or even something different?

--Westnordost (talk) 12:28, 28 October 2017 (UTC)

I also have this problem. The wiki only says "This is set separately for each side of the road, because it can be different!" But how? With tactile_paving:left and tactile_paving:right on the crossing point or with a separate point on the footway leading to the crossing (but what if only a crossing is tagged on a road with sidewalk=* or similar?). It could really be more precise in the wiki. I decided now to use tactile_paving:left=yes (and tactile_paving:right=no) or tactile_paving:right=yes (and tactile_paving:left=no) on the crossing point – although this breaks the rule for "Use on ways": "On a pedestrian crossing highway=crossing, when the tactile paving is used in a line all across the crossing". So what should be the correct and best solution for any case which can also be used by blindmaps in a reasonable way? --Goodidea (talk) 12:29, 7 May 2018 (UTC)

@Westnordost: https://wiki.openstreetmap.org/wiki/Key:tactile_paving requests since 2010 to tag such cases with tactile_paving=incorrect. It seems strongly preferable to tactile_paving=no - lets imagine actual use. Blind person is navigating and gets info that the upcoming crossing has no tactile paving - and they encounter tactile paving from one side. It would be preferable to get info that tactile paving is incorrect. (I even started opening a new issue on StreetComplete tracker, then discovered https://github.com/streetcomplete/StreetComplete/issues/547 - I think that SC should provide =incorrect as answer available from "tactile paving on one side only". This situation is quite common in my area) Mateusz Konieczny (talk) 11:14, 10 August 2021 (UTC)

Tactile paving on crossings

The page suggests to use tactile_paving=* with crossings as ways whenever the tactile paving extends across the complete road widths. First of all, I am bit puzzled that hw=crossing is not mentioned under the heading 'use on nodes'. As Tag:highway=crossing tells us hw=crossing should only be applied to nodes not ways and taginfo confirms that that is by far the prevalent usage. So I suggest to encourage tagging hw=crossing nodes with tactile_paving, too. Secondly, I'd like to challenge the statement that tactile paving should only be tagged yes if it extends across the complete road widths, i. e. also on the carriageway. I have never seen such crossing around here but there are many that have a shorter or longer tactile paving across the sidewalk on both sides of the street and also on the island if one exists. Even if such paving is not the most practical for the blind I cannot imagine it is utterly useless. So why not tag it anyway? Maybe we just can add a tactile_paving=* qualifier for such case? When sidewalks are not mapped separately the method to mark "dangerous spots" cannot be applied either. What are your thoughts? -- TZorn (talk) 16:36, 13 September 2018 (UTC)

Hi, mapping for blind persons does not make any sense on nodes at all, except for spots that need attention, like fountains that might start to shoot water out of the flat ground. If there is tactile paving, it is always in the sense of helping to find a way. If the way is not mapped, that's the first thing to do. Talking navigation software can not help at all, if there is an information that there is any kind of unknown tactile paving anywhere on a crossing. A specific mapping of each small area of tactile paving is needed, to distinguish correct tactile paving from irritating wrong tactile paving. If you feel you want to put a tactile paving tag on a node, do it an add a "FIXME=Make a way out of the node for tactile paving". --Lulu-Ann (talk) 11:32, 7 October 2018 (UTC)

I don't follow you. A hw=crossing node represents a real life way. Where the to be crossed road is mapped as a two dimensional feature (including sidewalks) it does not make sense at all to map a crossing as another two dimensional feature that does not connect to anything. In this situation the node exactly conveys the information: "You can get from one side of the street to the other here". If the highway is mapped with sidewalk information the node might even say: "You can get from one sidewalk to the other here". So I don't see any reason not to ad the tactile paving information to that node. In cases where sidewalks and carriageway are mapped separately any crossing should not be mapped as hw=crossing anyway. The encouraged style of mapping is hw=footway + footway crossing in that case.

You did not answer to my second question: Why shouldn't a tactile paving that is clearly marking the start and end of a crossing but does not extend all the way across the carriageway be marked at all? -- TZorn (talk) 06:54, 19 October 2018 (UTC)

If you can tell the direction of a way that is tagged as a node you are not blind. If your navigation software knows nodes on a way you have a very interesting navigation software that either

• uses much time on preprocessing
• uses endless amounts of storage space
• can still not point a direction to a blind person from a node.

There are pedestrian crossings with and without tactile paving that are not rectangular at all to the street. "Tactile_paving" on nodes is useful. In exactly one way: Run a robot to add a FIXME. We don't map to add dangerous bad information for blind persons. We map to make ways less dangerous. --Lulu-Ann (talk) 15:25, 10 January 2019 (UTC)

In Portland, OR, most of our tactile paving is rectangular sections as the sidewalk slopes down to the street. It doesn't extend across the street. From this discussion, it seems like tactile_paving=* should only be used when the sidewalk is mapped separately from the roadway, as nodes on the footway=crossing that connects two sidewalks and crosses a road. It shouldn't be used when the crossing is represented as a node on the roadway. Is that correct? If so, we should update the main wiki page to say that. --Jeffrey Yasskin (talk) 02:02, 9 July 2021 (UTC)

Should pedestrian crossing studs be tagged as tactile paving on the way?

In the UK most traffic light controlled and marked crossings have raised studs lining the left and right of the footway=crossing as shown on Wikipedia and here. Should these ways be tagged as tactile_paving=yes? If so it would be useful to add another image to the wiki page. --TrekClimbing (talk) 22:10, 13 August 2021 (UTC)

They should best be marked on kerb=* nodes (which are themselves part of footway=crossing way). I'd only map a tactile_paving=* on a way, if the full length of a way itself contains tactile paving, e.g. this --mnalis (talk) 10:44, 23 February 2023 (UTC)

@mnalis not sure if it was clear from the pictures, I don't mean tactile paving at the kerb but these lines of studs either side of the crossing - they aren't continuous but are there for tactile and visual feedback, particularly for guide cane users. --TrekClimbing (talk) 23:34, 23 February 2023 (UTC)

Minimum contrast

@J-Louis ZIMMERMANN: Thanks for documenting tactile_paving=contrasted. Can you clarify where the 70% minimum contrast threshold comes from? Is it specific to a French or EU standard? In the U.S., the relevant law requires a specific dome size and spacing and also requires visual contrast, but it doesn't say how much. I don't think most mappers would know how to measure the level of contrast to such a fine degree, even during field surveys. – Minh Nguyễn ^💬 05:30, 28 July 2022 (UTC)

Personally used it for a short while before realizing it's deficient, felt slightly misled by wiki. Although there are citizen science apps for measuring eg water quality by phone camera, I had not found comparable methods of ease for contrast, especially when color and lighting is involved, raising the question of calibration. Using colour=* plus something for pavement would be better. Yellow may often be deemed contrasting enough. --- Kovposch (talk) 06:55, 28 July 2022 (UTC)

Hello @Minh Nguyen: here you should find french accessibility standard and a picture showing how to see the optimal contrast. Regards --JLZ (talk) 12:44, 4 August 2022 (UTC)

@J-Louis ZIMMERMANN: Thanks, I assume you mean this table, which the article presents as an alternative to having to measure light reflectance values in the field. However, it's an oversimplification for our purposes: it only considers the standard colors used in France, whereas the colors standard in markings in the U.S. are distinct hues. It also seems to be focused on indoor lighting and flooring; the specific LRVs would differ significantly with outdoor materials and lighting conditions. It's for the same reason that any hexadecimal colour=* value in the database is essentially unverifiable on the ground.

I don't think there should be such a specific global definition of primitive. The definition can give some examples of colors that contrast well and point to sources like this as justification, and local communities could determine the standard colors that meet their countries' accessibility standards for contrast. But I don't think we should constrain mappers beyond that. We just don't have the tools to do it well, and a standard specific to one country is not necessarily relevant to a user of tactile paving in another country.

 – Minh Nguyễn ^💬 20:29, 4 August 2022 (UTC)

@Minh Nguyen:, in fact the article mentions also hue difference: "contraste chromatique" : so luminance or hue contrast. --Nospam2005 (talk) 11:43, 19 November 2024 (UTC)

@Nospam2005: My point stands: the global definition should not incorporate a 70% minimum contrast. This overly specific definition does little to help mappers identify accessible tactile paving or help data consumers make use of the data. If measuring contrast is such a good idea, then we should either tag the node with hue_contrast=* or tag both the node and parent way with colour=*, letting the data consumer calculate the contrast. Regardless, I'd assert that the current definition is pure wiki fiction; no one is actually considering the 70% threshold when surveying in the field. – Minh Nguyễn ^💬 06:09, 20 November 2024 (UTC)

Example for tactile_paving=primitive?

Would something like this be tactile_paving=primitive? Most of these were built in the US before the Disabilities Act, and don't appear to be built for the blind, but rather to increase grip on kerb ramps:

—Preceding unsigned comment added by Popball (talk • contribs) 10:45, 28 July 2022‎ (UTC)

High contrast lanes

I don't seem to find a way to tag high contrast lanes suitable for visually impaired people but not for completely blind. In other words safe lanes marked with contrasting colors but lacking any tactile paving. --VileGecko (talk) 10:52, 30 August 2022 (UTC)

Tactile paving on a way?

I am confused as to how to mark some crossings with tactile paving. What counts as tactile paving on a way exactly? In the UK there is no standard tactile paving used across pedestrian crossings - only the markers on either side to flag the crossing on the pavement. So is it ambiguous what counts as tactile paving for the crossing way? For example, if a pedestrian crossing is marked out across a road by a slightly raised brick path (1-2 cm), should that crossing way have tactile_paving=yes? A second example is a traffic light controlled pedestrian crossing where the crossing is marked out by two solid lines of bricks. Again, should that crossing way have tactile_paving=yes? Nathan A RF (talk) 22:33, 8 January 2023 (UTC)

Good questions. Studs is asked above #Should pedestrian crossing studs be tagged as tactile paving on the way? , and there is discussion for Proposed features/detailed tactile paving to differentiate sidewalk, kerb , and roadway.
Can you point to example locations or photos of the bricks? May or may not be tactile_paving=primitive. But they could be crossing:markings=surface (2.1) + surface=paving_stones / crossing:markings=lines (2.2) + Unclear if you have brick edge but different crossing surfacing.
--- Kovposch (talk) 09:29, 29 January 2023 (UTC)

how to mark on steps?

Tactile paving is often present at bottom and top of the highway=steps. However, how should it be mapped in OSM? It seems to me tactile_paving=* would be best added at a start and end node of that steps way (i.e. similar to how it is mapped on kerb=* for crossings) as it is most precise, but there seems to be some 28k+ uses of marking it at the steps way itself. It is certainly easier, but is somewhat incorrect (as the tactile paving does not follow that way). Which is to be preferred? (note: also discussed in tagging ML and forum and SC issue #3534 --mnalis (talk) 11:08, 23 February 2023 (UTC)

"but is somewhat incorrect (as the tactile paving does not follow that way)" - in some cases it is actually on the every single step, but if people mark top/bottom one on entire way then this info is lost anyway... I would put tactile_paving=yes/tactile_paving=yes at the start and at the end - where they would be expected or where they actually are to make it at least potentially useful for blind people Mateusz Konieczny (talk) 13:40, 23 February 2023 (UTC)

The advatntage of putting tactile_paving=yes/tactile_paving=yes at the start and at the end of the steps way would also have the advantage, that you can determine whether stair landings (if mapped individually, otherwise create a point within the highway=steps way) also have tactile_paving or not.
However, I have to admit that I've always just put tactile_paving on the steps-way. ID has this also so in its preset. --Lukas458 (talk) 17:59, 23 February 2023 (UTC)