Proposal talk:DisabilityDescription

Some comments: 1) No reason that wheelchair access should "not [be] displayed in ordinary maps" - a wheelchair, or crossed out wheelchair symbol would be fine.

Icons for the blind are not rendered. Where do you want the wheelchair icon? Instead of the restaurant icon, next to it? On which maps are they rendered? I only know http://www.accessiblemaps.org and Rollstuhl-Routing

2) Suggest making the language code optional, so "wheelchair:Poor access" would be valid.

Usually English speaking mappers ignore the lg tag anyway. Is OK to me, but causes extra work at rendering.

3) Suggest proposing a lot more standard tags, rather than relying on free text. Induction loops for deaf people, ramps for wheelchairs etc, are all standard concepts, hence use standard tags. Surprised there aren't any already? 4

Surprised you did not find them - they do exist. See Category:Disabilities

4) I'd try a bit harder to integrate some of these concepts with other standard tags. For example, a bike path is probably wheelchair accessible, stairs are not, etc. Stevage 10:44, 2 January 2010 (UTC)

See stairs, see wheelchair - Everything is answered on the according pages. --Lulu-Ann 11:18, 2 January 2010 (UTC)

Attempt to change the status to "abandoned"

 Abandoned

I changed the status to abandoned because:

   * although this key is a subkey set of "description", the format of it is plainly wrong,
   * it is completely unused,
   * nobody cared to widespread the knowledge of the tag. 

Searching with osmdoc, I found a similar key, used only once, which is "description:DE:blind" which is a more sensible format. So I suggest to create a new proposal for description:blind/wheelchair/deaf:language or description:language:blind/wheelchair/deaf, that would end with the inclusion of the approved key in the feature page. (Unsigned by Gwilbor)

I undid your changes.

If you dislike the format, why didn't you vote against?

This key is not unused, you are only not able to query it correctly.

This key is spread on the accessibility mailing list and was requested for comments on talk mailing list.

The similar key was an old try and will be converted as soon as I have time.

It does not make sense at all to have a language abbreviation in the middle of a tag, it needs to be at the end for easy query.

Sign your contributions!

--Lulu-Ann 22:29, 10 March 2010 (UTC)

I didn't vote against, because I started to follow the proposals and the international mailing list just a month ago.

You're right about the query, I should have searched better.

A mailing list is not a good reference guide. Any approved feature should be added as soon as possible to the map feature page, so everyone can acknowledge it, anytime.

About the language abbreviation in the middle, I understand your point, therefore I will support a description:<disability>:<language>=* key. When I'll have some time, I will submit the proposal myself (which will make this proposal obsolete). --Gwilbor 11:23, 16 March 2010 (UTC)

description:<disability>:<language>=* does not make sense. Think of the usecase: A user wanting a description does not want descriptions for all cases. A software offering descriptions will annoy seeing users with descriptions for the blind. This will end in seeing users manipulating descriptions for disabled persons.

A disabled user needs informations of different kinds for his disability. The software wants to query all tags with blind: at the beginning, not all descriptions!

I had it that way before and it did not work. Lulu-Ann

Try to make some of the information more machine readable

For the data to be most useful (first for the machine and then the generated product for the human), you should try to group this free text proposal into more specific and relevant tags for all disability groups. There is a german discussion related to this here. --Fabi2 21:55, 24 March 2010 (UTC)

This tag is for individual humans with individual disabilities. I don't care for machine readability. This is exactly the fallback tag for failing machine readable tags like tactile_paving=incorrect. Btw, I can't finde what you mentioned at the opening_hours talk page. Lulu-Ann

Maybe it is not so clear in the discussion there, but I mean that you have to find a good balance between machine- and human readability. Which map renders description=* in some kind? OK, e.g. you can put it in the POI information box on your Garmin, but the space there is also very limited for such long decriptions and in charset. You should ask the different groups of diasabled people which information on a map where most helpful for them and then create tags for the most named items (e.g. braille=yes for the blind, ..). So, I created the centralkey-proposal after I read about the problem to find the toilet key fast enough and met some wheelchair affected people. If I had used a free-text-field for centralkey=, then you have to click on all toilets in the city and so you better go to the next wheelchair=yes toilet and try to find the key as usual. I thought about an additional indoor tag, but as the objects should be represented by themself, I think it is not really needed. --Fabi2 20:30, 30 March 2010 (UTC)