[Accessibility] Import stop signs for blind persons in Katowice, Poland
Łukasz Taraszka
luktar at gmail.com
Sat Aug 29 17:22:08 UTC 2020
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.
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> 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> 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>
>> napisał(a):
>>
>>>
>>>
>>>
>>>
>>> sent from a phone
>>> > On 25. Aug 2020, at 09:43, Alessandro Sarretta <
>>> 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
>>> https://lists.openstreetmap.org/listinfo/accessibility
>>>
>>> To unsubscribe from this mailing list send an empty email to
>>> accessibility-unsubscribe at openstreetmap.org
>>>
>>
>>
>> --
>> Pozdrawiam
>> Taraszka Łukasz
>> tel. 668 462 791
>> _______________________________________________
>> Accessibility mailing list
>> 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
>>
> _______________________________________________
> Accessibility mailing list
> 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
>
--
Pozdrawiam
Taraszka Łukasz
tel. 668 462 791
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/accessibility/attachments/20200829/be59f70e/attachment-0001.htm>
More information about the Accessibility
mailing list