[Accessibility] Import stop signs for blind persons in Katowice, Poland

Sun Aug 30 11:07:21 UTC 2020

Hey Lukasz

i'm  interested in your work and looking at http://anyplace.cs.ucy.ac.cy/ for indoor mapping (can do ~2m accuracy indoors) for the blind since it does not require beacons - an issue i see from looking at your website (which is easy to read in google translate)

i'm working with Dr. Dianne Pawluk https://egr.vcu.edu/directory/diannepawluk/  and Dr. Peggy Fields of the Virginia dept of the blind - as well as local blind and vision impaired users.

here's a project we're working on to identify stairs and elevators inside buildings https://guides.hsl.virginia.edu/it-services-blog/zoombites/Open-location-mapping-for-ada-wayfinding

If you could give me instructions for how you gathered data i will try to duplicate your work here in Charlottesville and then we can work together on the imports in to open street map

this looks like a great project & i hope we can work together to improve wayfinding for the blind :)

All the best,
Anson

________________________________________
From: Łukasz Taraszka <luktar at gmail.com>
Sent: Saturday, August 29, 2020 1:22 PM
To: Accessibility
Subject: Re: [Accessibility] Import stop signs for blind persons in Katowice, Poland

Hello Anat,

I would like to point you to an existing consortium of many people developing GTFS_Pathways which is standardizing these very attributes in a GTFS feed.
Some of the tags you are suggesting are divergent with the GTFS_Pathways<https://docs.google.com/document/d/1qJOTe4m_a4dcJnvXYt4smYj4QQ1ejZ8CvLBYzDM5IyM/edit> and we should be sure to make them seamless.

This document is quite big and I couldn't find matching tags. Would you point me to these tags?
Polish local community said that better than stop_id and stop_no would be gtfs_id and local_ref but I could find these tags in the mentioned document neither.

The second thing I wanted to mention is that  I would strongly urge against using
blind:
as a namespace.
While the primary use case for these tags may be blind navigation, it is not the only one (as you can see from GTFS_Pathways). Moreover, in OSM, we don't place other sub-populations as a namespace category. If I was to suggest  heterosexual: as a namespace I would be hounded by hundreds of mappers, and justifiably so! People with disabilities are people first, their disability is just an attribute, or in some cases, cultural affiliation (like capital D Deaf). Let's not inadvertently use OSM as a platform to promulgate really backward cultural and societal patterns that have stigmatized people with disabilities in society...

Well, I agree with that but I'm not quite sure why did you mention that? Did I use a tag "blind" anywhere on my wiki page?

As for the proposal itself:
1) Quality of data: How do you know that the transit authority/agency from which you are importing is accurate enough?
Example: we have tried to do this with the King County Metro listed transit bus stops and they were not always within the 5m range we considered to be sufficiently accurate. The way we tested this was by sampling 100 stops in King County from both Automated Vehicle Locations (9 weeks of data, so that errors in AVL should be notable from these) as well as GPS traces contributed by individuals. It would be a shame to import a bunch of bad data. Check first!

i'm sure that the data will not be accurate. Because of that I plan to import data with smaller parts and fix the position together with the local community - probably scouts.
6500 stops is not so much.

2) Integrity of tags: If you're really doing this work for social good, please be sure to involve people with disabilities in your work. Specifically, ask someone who is blind how they want the information represented to them. If you're unable to do that, at least inform your work by research others have done. For your particular problem, you may want to look up studies by Michele Williams and Cindy Bennet. I'm happy to send you these works if you don't have access to the relevant journals.

This idea came from my blind friends. I'm cooperating with the local blind community and organizing several projects. This is my webpage: https://rozwiazaniadlaniewidomych.org/. Unfortunately it's not translated to English. The domain name means solutionsforblinds.org<http://solutionsforblinds.org>.
I'll be glad for sending me the mentioned studies. I will compare them to the local publications.

--
Best regards,
Tarraszka Łukasz

pt., 28 sie 2020 o 03:10 Taskar Center <uwtcat at uw.edu<mailto:uwtcat at uw.edu>> napisał(a):
Hi,

I would like to point you to an existing consortium of many people developing GTFS_Pathways which is standardizing these very attributes in a GTFS feed.
Some of the tags you are suggesting are divergent with the GTFS_Pathways<https://docs.google.com/document/d/1qJOTe4m_a4dcJnvXYt4smYj4QQ1ejZ8CvLBYzDM5IyM/edit> and we should be sure to make them seamless.

The second thing I wanted to mention is that  I would strongly urge against using
blind:
as a namespace.
While the primary use case for these tags may be blind navigation, it is not the only one (as you can see from GTFS_Pathways). Moreover, in OSM, we don't place other sub-populations as a namespace category. If I was to suggest  heterosexual: as a namespace I would be hounded by hundreds of mappers, and justifiably so! People with disabilities are people first, their disability is just an attribute, or in some cases, cultural affiliation (like capital D Deaf). Let's not inadvertently use OSM as a platform to promulgate really backward cultural and societal patterns that have stigmatized people with disabilities in society...

As for the proposal itself:
1) Quality of data: How do you know that the transit authority/agency from which you are importing is accurate enough?
Example: we have tried to do this with the King County Metro listed transit bus stops and they were not always within the 5m range we considered to be sufficiently accurate. The way we tested this was by sampling 100 stops in King County from both Automated Vehicle Locations (9 weeks of data, so that errors in AVL should be notable from these) as well as GPS traces contributed by individuals. It would be a shame to import a bunch of bad data. Check first!
2) Integrity of tags: If you're really doing this work for social good, please be sure to involve people with disabilities in your work. Specifically, ask someone who is blind how they want the information represented to them. If you're unable to do that, at least inform your work by research others have done. For your particular problem, you may want to look up studies by Michele Williams and Cindy Bennet. I'm happy to send you these works if you don't have access to the relevant journals.

All the best,

Anat

Sent from my mobile. Please excuse brevity and typos.

Sent from my mobile. Please excuse brevity and typos.
On Wed, Aug 26, 2020 at 10:08 AM Łukasz Taraszka <luktar at gmail.com<mailto:luktar at gmail.com>> wrote:
Hello,

Thanks for your responses!

It's quite hard to respond to all of the messages in order. I've placed the citations and responses below.

Martin Koppenhoefer
thank you for notifying this list. Please be sure to also follow the import guidelines and discuss your plan on the imports list and with the Polish list.
https://wiki.openstreetmap.org/wiki/Import/Guidelines
I tried but I've some small problems because of my alias mail but I plan to do this today.

is this explicitly signposted (door position of the vehicle)? Generally we have stop positions for public transport route relations (on the road) and/or the highway=bus_stop node (and similar for trams) should be at the stop position (both are indicating the front of the vehicle, not necessarily identical to the door position)
These positions are not good enough for blind because of two reasons:
1. The application is guiding blind people to the place on a street, where a bus or tram stops. This position could be slightly different than the place where are the doors of a bus are and in some cases could be dangerous (blind people could go on a street or rails in case of flat sidewalk).
2. Transportation companies (GTFS providers) are sharing stop signs positions and they provide the most updated and reliable data. Uploading this data to OSM would be very simple.

my suggestion would be „ref“ or maybe „ref:<shortname of your dataset/external source>=*“ if these should be imported at all
So for example ref:ztm
I plan to create a procedure and the software to import data to other cities. I think the name should be more universal than the local db name. What do you think?
What about blind:stop_numer and blind:stop_id?

Alessandro Sarretta

  *   you say (https://wiki.openstreetmap.org/wiki/Automated_edits/luktar/Stop_signs_for_blind#Missing_stop_signs) that current objects in OSM are not enough for blind people, but in the examples  (https://wiki.openstreetmap.org/wiki/Automated_edits/luktar/Stop_signs_for_blind#Tagging_Plans) you're reusing those tags. Are you proposing just to add the new tags stop_no and stop_id to the existing ones?

Good point. I wrote here (https://wiki.openstreetmap.org/wiki/Automated_edits/luktar/Stop_signs_for_blind#Solution) that: "The idea is to add stop signs where they don’t exist or add required tags to existing stop signs."
In most of the places there are notstop_signs - instead of that there are only stop_positions - places on a street/rails where the bus/tram will stop. In this case new object should be added.
But there are places where there are stop_positions and stop_signs. In this case the stop_sign should be updated with additional tags.
Example: Rybnik - Kościuszki: https://www.openstreetmap.org/edit#map=20/50.09197/18.54794

  *   regarding stop_no, I would suggest something different (stop_n or simply stop_number) because stop_no seems to me that there is no stop :-)

stop_number is convincing me :)

Fundacion TODOS PODEMOS AYUDAR
Sorry, im. Not blind OR an expert, when  you ha e your app. Developed i can sjare ir
Sorry, I don't understand :(

--
Best regards,
Taraszka Łukasz

wt., 25 sie 2020 o 11:43 Martin Koppenhoefer <dieterdreist at gmail.com<mailto:dieterdreist at gmail.com>> napisał(a):

sent from a phone
> On 25. Aug 2020, at 09:43, Alessandro Sarretta <alessandro.sarretta at gmail.com<mailto:alessandro.sarretta at gmail.com>> wrote:
>
> regarding stop_no, I would suggest something different (stop_n or simply stop_number) because stop_no seems to me that there is no stop :-)

my suggestion would be „ref“ or maybe „ref:<shortname of your dataset/external source>=*“ if these should be imported at all

Cheers Martin
_______________________________________________
Accessibility mailing list
Accessibility at openstreetmap.org<mailto:Accessibility at openstreetmap.org>
https://lists.openstreetmap.org/listinfo/accessibility

To unsubscribe from this mailing list send an empty email to accessibility-unsubscribe at openstreetmap.org<mailto:accessibility-unsubscribe at openstreetmap.org>

--
Pozdrawiam
Taraszka Łukasz
tel. 668 462 791
_______________________________________________
Accessibility mailing list
Accessibility at openstreetmap.org<mailto:Accessibility at openstreetmap.org>
https://lists.openstreetmap.org/listinfo/accessibility

To unsubscribe from this mailing list send an empty email to accessibility-unsubscribe at openstreetmap.org<mailto:accessibility-unsubscribe at openstreetmap.org>
_______________________________________________
Accessibility mailing list
Accessibility at openstreetmap.org<mailto:Accessibility at openstreetmap.org>
https://lists.openstreetmap.org/listinfo/accessibility

To unsubscribe from this mailing list send an empty email to accessibility-unsubscribe at openstreetmap.org<mailto:accessibility-unsubscribe at openstreetmap.org>

--
Pozdrawiam
Taraszka Łukasz
tel. 668 462 791