Accessibility issues
← Older revision
Revision as of 00:38, 14 July 2016
(13 intermediate revisions by the same user not shown)
Line 14:
Line 14:
:: Yes, you're right. We updated it to be {{tag|kerb|*}} because all of those values might be meaningful. Thanks! --[[User:Mdrouhard|Mdrouhard]] ([[User talk:Mdrouhard|talk]]) 17:37, 8 July 2016 (UTC)
:: Yes, you're right. We updated it to be {{tag|kerb|*}} because all of those values might be meaningful. Thanks! --[[User:Mdrouhard|Mdrouhard]] ([[User talk:Mdrouhard|talk]]) 17:37, 8 July 2016 (UTC)
+
+
== Mapping Issues ==
+
+
''This discussion has been transposed from a series of emails, initiated after our proposal was presented to the accessibility listserv''
+
+
a) there has to be something visible to be used by the community. This would be achieved in parts with your rendering, but that's not enough. If something tends to be abstract and is not visible in the common editors (JOSM and iD) it's hard to get it mapped by any user. --''Peter'' 6 July 2016 (UTC)
+
: We agree, we are interested in proposing a sidewalk layer that will highlight the proposed schema, and would be visible in the primary editor. --{{user|Jesshami}} 8 July 2016 (UTC)
+
+
b) What is a proposed crossing? For different disabilities different features are relevant. Wheelchair users need lower up to no kerbs, depending on their individual fitness, and especially upwards (downwards slightly higher kerbs might be acceptable). On the other hand, blind people want crossings they can detect, so lowered kerbs are okay, no kerbs at all without accessibility marks attached are quite dangerous. --''Peter'' 6 July 2016 (UTC)
+
:Our proposed crossing is in line with the highway=crossing that already exists, it has features for wheelchair accessible, and tactile paving. We treated kerbs as separate points. Are you proposing additionally accessibility features for people with low vision? The way we treat crossings as ways, would be visible to routing algorithms, and could notify people, but there is definitely space for additional tags. --{{user|Jesshami}} 8 July 2016 (UTC)
+
:: I don't have an idea here, and I don't think it' that relevant for the map data. Where low vision becomes an issue is the mapping itself (how to edit the map with low vision). But: For low vision zero-height-kerbs are particularly important, as they are a potentially dangerous thing. --''Peter'' 8 July 2016 (UTC)
+
+
c) How to detect/provide the connection between sidewalk and street? Does the sidewalk get the name of the street as well? Tagged as "name=..." or differently? Or is there any other way to connect the two? Your proposal mentions a relation as "To be done". IMHO that's a bad idea. Relations are hard to maintain at all. Adding relations to core features like streets leads to (i) many broken ones, as people don't maintain the relation while editing the street, and (ii) bad coverage of the relation. Therefore the relation linking street and sidewalk would have to be detected by some automatic heuristic for the badly mapped cases - and if that works sufficiently the relation is not needed at all. --''Peter'' 6 July 2016 (UTC)
+
:I don't think this is totally resolved, but from other proposals we've seen relations seem to be the preferred choice. Naming sidewalks is probably not appropriate unless there is already a common name associated with the pedestrian way, it seems they probably wouldn't be maintained. Libraries exist to do this conversion, (https://pypi.python.org/pypi/Skeletron) but there is no agreement that, that is the correct way to do it.--{{user|Jesshami}} 8 July 2016 (UTC)
+
:: If sidewalks are not named, but mapped as separate ways, the routing algorithm is quite challenged to provide a useful routing description. Sure: As long as you stick to a printed map everything is fine, the user sees what's the street next to the sidewalk and can determine it, but what about blind people, or those who are not able to read a map? Something like "go straight on 'unnamed sidewalk'", "go left on 'unnamed sidewalk'"... is quite useless, even when augmented with rough distances or intersection counts. The named link is missing here, and it feels much more safe to be able to cross check with the street sign.
+
:: tldr: If the sidewalk has neither a name nor a relation connecting it to a named street, you have to put much work into implementing automatic mapping to the street, just by using the geometric shapes and by detecting something like "roughly along...".
+
+
::Skeletron - according to the description, does the other way around: it generalizes parallel lines to a single one for labelling, but as you propose (in your mail) to leave out the duplication of the name, you have to find the parallel way to name it afterwards. What about streets roughly in parallel and nearby, where one has a sidewalk towards the other side - what name do you give to the sidewalk when doing that by an algorithm?
+
::Example in Paderborn, Germany: http://www.openstreetmap.org/#map=19/51.74765/8.75638 - the footway between Schwabenweg and the Top-Zoo shop is a sidewalk. Is it the sidewalk of Schwabenweg or the one to the service road west of it? (and I'm sure there are cases where that is not a service road).
+
+
::Example in Bergen, Norway: http://www.openstreetmap.org/#map=19/60.40300/5.32083 - Sjogaten and Nordre Skuteviksveien are two sidewalks (both not mapped in OSM), but imagine the Sjogaten would not have one, and there were a single one in between. even though it might be closer to the center line of Nordre Skuteviksveien (a small street, perhaps 6 meters wide), it would probabbly be attached to the Sjogaten, which has 10 meters width for sure, so that even the mapping geometry more towards Norder Skuteviksveien might be correct). Automatic mapping to the nearest street along would fail here without additional hinting. --''Peter'' 8 July 2016 (UTC)
+
+
:::Your concerns over naming make a lot of sense. We are still sorting out exactly how this will work, but after some discussion it seems our best options are:
+
:::A. Recommend people manually name sidewalks with cardinal direction as they are being added
+
:::B. Push forward with the sidewalks as relations approach, and develop a way to assign cardinal directions to the sidewalk names.
+
:::Both of these could be enforced / human verified in our import tool, however unfortunately as with everything we can not mandate compliance in manual contributions. --{{user|Jesshami}} 13 July 2016 (UTC)
+
+
== Accessibility issues ==
+
+
''This discussion has been transposed from a series of emails, initiated after our proposal was presented to the accessibility listserv''
+
+
a) Dependent on traffic conditions, an unmarked crossing on a slow moving road in the middle between two intersections can be seen as more secure for blind people than a marked one directly at the intersection. One reason for that is, that audible detection of traffic is easier when there's less traffic along your route.--''Peter'' 6 July 2016 (UTC)
+
:OSM generally excludes traffic because of the transience, so that is probably something that is better addressed through routing algorithms, but it is something we are considering in our application.--{{user|Jesshami}} 8 July 2016 (UTC)
+
::I don't think there is any data set a routing algorithm could use that can determine the right crossing according to traffic conditions at all - even when using live data. But even when that would be used, the proposal to map the "preferred" crossing is insufficient as the mapper decides what's the preferred crossing at all.--''Peter'' 8 July 2016 (UTC)
+
:::This still seems to fall outside of the domain of our OSM spec and more a routing issue. There appears to be external traffic information available from projects like [[http://opentraffic.io/]] or alternatively people could reference speed limits to get a sense of traffic conditions. We have been thinking about different cost functions identifying "preferred crossings" for different users, based on user preferences --{{user|Jesshami}} 13 July 2016 (UTC)
+
+
b) How to deal with missing data? The effort to create global coverage might be worth it, but in OSM any application has to deal with missing data in some way. A map rendering is easy: If you show any object, that's fine, and where no data exists, nothing is shown. But what about routing? If you fall back to "no sidewalk exists" and want to provide a secure route for blind people, you would have to omit streets that have no sidewalk mapped - so routing get's unuseable while the data isn't complete enouogh. But nobody maps data in OSM as long as it's not useful/used by someone.--''Peter'' 6 July 2016 (UTC)
+
:We are working on tools to facilitate the import of municipal data, but ultimately routing software has to handle missing data and our proposal of standardizing conventions alleviate the problem.--{{user|Jesshami}} 8 July 2016 (UTC)
+
+
c) Sidewalk width: something not reflected in your proposal yet, but very important e.g. for wheelchair users, when sidewalks of e.g. 50cm width are mapped as sidewalk: Far too small for any wheelchair, but a sidewalk.--''Peter'' 6 July 2016 (UTC)
+
:We are proposing sidewalks use the existing highway=footway the width attribute exists already, are you suggesting we include it in our core features? That makes sense, we will update that. --{{user|Jesshami}} 8 July 2016 (UTC)
+
:: I think, attributes like width should be referred to as useful additions, it doesn't has to be part of the proposal as there's nothing new about it. --''Peter'' 6 July 2016 (UTC)
+
::: A lot of the tags outlined in the proposal already exist, we are highlighting them for relevance in the pedestrian layer. We will work on clarifying the spec with diagrams and additional notation, keeping your comments in mind --{{user|Jesshami}} 13 July 2016 (UTC)
+
+
d) when suggested kerbs should be marked explicitly - what if there is no "best fit" kerb? How should some fit walker with normal sight determine what's the best fit, if there's no lowered kerb at all at a block (yes, stuff like that exists)? Should there be any crossing mapped at all in that case? If so, where? If not: what's the proposed fallback for routing?--''Peter'' 6 July 2016 (UTC)
+
:Crossings are not dependent on kerbs, they can be wheelchair=yes/no, marked, unmarked, signaled, have kerbs or not, routing software is also free to infer crossings for individuals depending on their needs.--{{user|Jesshami}} 8 July 2016 (UTC)
+
:: I don't think we disagree here, I just wanted to highlight the term "recommended crossings" is not very clear. You can interpret it as "well, recommended crossing is always the one with kerb at the intersection, so the other ones should not be mapped" - which is sometimes wrong.--''Peter'' 6 July 2016 (UTC)
+
+
On top of that there are the many many corner cases not (yet) included of course: (especially wide) stairs, elevator mapping (where are exits, where are none?), multi-level mapping (bridges on bridges, ways or stairs in parallel on top of each other and many more.--''Peter'' 6 July 2016 (UTC)
+
:Descriptions of crossings, and many other features should be available through the attributes already established.--{{user|Jesshami}} 8 July 2016 (UTC)
+
+
In Phase 2 the project aims to build import tools, but data without usage is worse than no data at all. Routing for blind people needs different routing descriptions and has to be accessible without a graphical map representation at all. SO what about routing with announcement of side-of-the-street, description of crossing types and stuff like that?--''Peter'' 6 July 2016 (UTC)
+
:What do you mean by side-of-the-street? Do you mean shoulders that are not sidewalks? Descriptions of crossings, and many other features should be available through the attributes already established. --{{user|Jesshami}} 8 July 2016 (UTC)
+
::In both cases the street serves both as a tactile (by kerb or strip of grass) and audible (by cars sounds) landmark, so it's useful to announce the side, like "go along Main street, you're on the left sidewalk". In my tests with a blind co-student he mentioned that as relevant information as the alternative sometimes is to walk straight until the GPS tells you to turn around.--''Peter'' 8 July 2016 (UTC)
+
:::Correct me if I am wrong, you are pointing out the importance, for people with low vision, of indicating which side the street lies on in relation to the direction they are moving. We have not totally sorted this out, however one way we are thinking about it is: If we have a sidewalk with related street, then based on the street and direction our route is moving this user, we should be able to reveal which side of the user the street is on. --{{user|Jesshami}} 13 July 2016 (UTC)