Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Quest: Incline of short pedestrian ramps #2249

Open
5 tasks done
DerDings opened this issue Nov 7, 2020 · 13 comments
Open
5 tasks done

New Quest: Incline of short pedestrian ramps #2249

DerDings opened this issue Nov 7, 2020 · 13 comments
Labels
new quest accepted new quest proposal (if marked as blocked, it may require upstream work first)

Comments

@DerDings
Copy link

DerDings commented Nov 7, 2020

General

Affected tag(s) to be modified/added: incline
Question asked: How steep is the incline of this ramp?
Answer: a numeric value that can be either entered manually or measured with the device's accelerometer.

Rationale: The inclines of ways are crucial for wheelchair routing. This was already mentioned in #1978 as a general question, but didn't spawn a detailed quest suggestion.
There are already some good approaches to include this information:

Both are good for a most of situations. But they're not sufficient for ramps in urban context.

  • the resolution of DTMs often are not dense enough for very short ways.
  • DTMs often don't cover all man-made modifications like embankments.
  • GNSS accuracy is not sufficient for short ways (see below).

Checklist

Checklist for quest suggestions (see guidelines):

  • 🚧 To be added tag is established and has a useful purpose: incline is very important for accessibility.
  • 🤔 Any answer the user can give must have an equivalent tagging (Quest should not reappear to other users when solved by one)
  • 🐿️ Easily answerable by everyone from the outside but a survey is necessary: I don't know any Android smartphone without an accelerometer, and they show reliable results after one second.
  • 💤 Not an overwhelming percentage of elements have the same answer (No spam)
  • 🕓 Applies to a reasonable number of elements (Worth the effort): lots of public transport platforms, entrances, … are accessible via ramps

Ideas for implementation

Element selection:
highway=footway/pedestrian OR highway=path + foot=yes/designated/official
AND
incline=up/down
AND
surface=ANYTHING_PAVED (because we search for built ramps not beaten paths. Also, one would not want to put the phone in the dirt.)
AND
length of way <= let's say 100 m(*)

This way will maybe also show some inclined ways which are not ramps in literal sense. But accidentally specifying the incline of a way which is not a ramp does no harm. Most reasons for specifying a ramp's incline will apply here, too.

To specify this further, one could also only select ways with any railway=* or building=* object nearer than 100 m, because these indicate that ways don't just follow the terrain but are some kind of modeled. But in my opinion, this is not necessary and only makes the quest load longer.

(*) why 100m?
Two reasons:

  • For accessibility, inclines need to be very exact. 7 % is already considered inaccessible for regular armmuscle-driven wheelchairs, while 6 % are default for public ramps in the European Union. If you want to tag a correct value rounded to a reliable precision of 1 % incline, you need to measure/calculate the incline with a precision of 0.1 % first. Assuming you use a GNSS which shows height with an fidelity of 0.1 m, you need a minimum distance of 100 m (0.1 m GNSS height inaccuracy / 100 m length of ramp = 0.1 % incline inaccuracy) for sufficient accuracy. The shorter the distance, the higher the inaccuracy of the incline.
  • A lot or ramps are built to access railroad embankments (like this ramp). If the railroad flies over a road with a headroom of 4 m + 1.5 m constructional height of the bridge itself = 6 m difference in altitude. Assuming inclines > 6 % to be critical for accessibility, we need to check ramps which are up to 100 m long to find all ramps with an incline of 6 % or more.

Surely the maximum length could be made shorter to find less elements, or longer to also find ramps which are climbing up even higher embankments. But 100 m is a good starting point for further discourse.

Metadata needed:
In most countries, including the European Union, the standardized incline of ramps is declared in %. So StreetComplete should show and tag inclines this way.
If there are countries where degree (°) is used for standards, this unit should be used instead in those countries.
Also see what the wiki says on that topic

Proposed GUI:
Text "if there is no sign, lay your phone's back surface on the steepest part of the ramp. Then press 'measure'".
below:
A text field on the left, big enough for three digits on the left. Inside the unit "%" is shown. On the right, there is a "Measure"-button.
As soon as something is entered in the input field, a "ok" button (like in the housenumber quest) shows up.
Hitting the measure-button shows an activity inicator on the button for ~1 second. Then the inputfield is filled with the measured incline, the "ok"-button shows up, and the text on the measure-button changes to "measure again"

Users shall only enter positive values. If the user input starts with a "-", a warning is shown. As this quest is only asked for ways that are already tagged with incline=up/down, users don't need to figure out the direction again. StreetComplete should internally add the "-" to ways which were tagged with incline=down before.

"More anwers.." includes:

  • differs along the way (-> split up)
  • I don't want to put my phone here (-> ask: Is the surface >SURFACE< correct for this way? -> Yes, just hide / No, leave note) this is just an optional idea
  • Can't say (ask: leave a note instead? -> No, just hide / ok)

Incline Quest

@westnordost
Copy link
Member

I see no problem with this quest other than that people may not be inclined (haha) to put their smartphone in the dirt. So maybe it would need to be disabled by default with the description that you need to put your smartphone on the ground).

Maybe the hint should encourage splitting the way if the incline is different along the way. (Your suggestion seems to indicate that it doesn't matter).

Maybe, the button should open a dialog in which the current % is displayed while the dialog is open.

@westnordost westnordost added the new quest accepted new quest proposal (if marked as blocked, it may require upstream work first) label Nov 7, 2020
@DerDings
Copy link
Author

DerDings commented Nov 7, 2020

Maybe the hint should encourage splitting the way if the incline is different along the way. (Your suggestion seems to indicate that it doesn't matter).

What I had in mind when writing this were very short (~5 m) ramps that are a bit hunchbacked. I don't see a sense in further fragmenting them just because they're not perfectly flat.

So maybe the hint should be extended by "if the incline varies much, you can also split the way up" only for ways longer than 6 m. (why 6 m? Because according to EU standards, a ramp designed for accessibility should not be longer than 6 m. If it needs to be longer, platforms must be added in between. So at least in the EU it is very likely that a ramp longer than 6 m is divided in two or more parts)

@DerDings
Copy link
Author

DerDings commented Nov 7, 2020

Additional thought: The wiki encourages mappers to estimate inclines and add the tag fixme=check incline. Since this scheme is documented so well, ways tagged like that could be included in the quest.

On the downside, there are only 115 ways whith the tag fixme=check incline and 87 FIXME=check incline on Taginfo. I don't know how much longer the quest will load if extended like this, so I can't decide whether it is worth being implemented.

@RubenKelevra
Copy link
Contributor

As long as the ramp has a very even incline this is obviously the most accurate way to measure it.

If the incline changes, like on a paved road often does, this isn't very accurate anymore, since you only measure a single point.

Doing this visually would average out the incline and give more accurate results, while using the same sensor on the smartphone.

Have a look:

#2222 (comment)

@DerDings
Copy link
Author

DerDings commented Nov 8, 2020

As long as the ramp has a very even incline this is obviously the most accurate way to measure it.

If the incline changes, like on a paved road often does, this isn't very accurate anymore, since you only measure a single point.

Doing this visually would average out the incline and give more accurate results, while using the same sensor on the smartphone.

This is the reason why I proposed to say "lay your phone[…] on the steepest part of the ramp" in the hint text. For accessibility, it is not the average incline that matters, but the part with the highest incline.

See what the wiki says (here):
» The value should be given for the practical maximum incline on the steep section (i.e., the maximum incline that a vehicle/primary user could achieve), and not for the average incline between the nodes. See Talk:Key:incline. «

@westnordost
Copy link
Member

@RubenKelevra : The measurement you took with the photo is not that precise though. you measured the angle from your breast-height to the ground height of the end of the way. Would you would need to measure it correctly is to either hold your smartphone very close to the ground or aim at a point at the end of the way that is in the same height as you hold the smartphone in your hand. Which is difficult to estimate correctly.

@RubenKelevra
Copy link
Contributor

@RubenKelevra : The measurement you took with the photo is not that precise though. you measured the angle from your breast-height to the ground height of the end of the way. Would you would need to measure it correctly is to either hold your smartphone very close to the ground or aim at a point at the end of the way that is in the same height as you hold the smartphone in your hand. Which is difficult to estimate correctly.

This was shot at eye height, so you can use trigonometry to remove the height of the user. Thats why I said we need to ask for the user height for this calculation.

@RubenKelevra
Copy link
Contributor

As long as the ramp has a very even incline this is obviously the most accurate way to measure it.

If the incline changes, like on a paved road often does, this isn't very accurate anymore, since you only measure a single point.

Doing this visually would average out the incline and give more accurate results, while using the same sensor on the smartphone.

This is the reason why I proposed to say "lay your phone[…] on the steepest part of the ramp" in the hint text. For accessibility, it is not the average incline that matters, but the part with the highest incline.

See what the wiki says (here):
» The value should be given for the practical maximum incline on the steep section (i.e., the maximum incline that a vehicle/primary user could achieve), and not for the average incline between the nodes. See Talk:Key:incline. «

Well, yes I was talking about bumps in the road not changing grades. In my test today the incline is very steady - I couldn't tell if there's any part steeper than another one.

But laying the phone down on the surface was actually the most inaccurate measurement I took.

@rhhsm
Copy link

rhhsm commented Nov 9, 2020

Interesting. It could also be added to the ramp quest, so mappers who are not sure if a ramp is a stroller ramp or a wheelchair ramp can measure the slope.

@DerDings
Copy link
Author

DerDings commented Nov 9, 2020

Well, yes I was talking about bumps in the road not changing grades. In my test today the incline is very steady - I couldn't tell if there's any part steeper than another one.

But laying the phone down on the surface was actually the most inaccurate measurement I took.

Okay, now I understand.

I often use Phyphox. At first, I always took three or more measures at different spots (steepest part, one in the middle and one on each side of the ramp), but in my experience, for paved ways the values didn't vary much. So now I only measure once in the lateral middle.
Maybe the quest hint should say:

"If there is no sign, lay your phone's back surface on a smooth spot at the steepest section of the ramp. Then press 'measure'.
If the incline varies much, you can also answer 'differs along the way'".
This is quite a long hint, but imo still simpler than requiring a user to enter one's height

However, your approach seems interesting as well, since it has other strengths and flaws. The decision what better fits the SC concept can only be made by @westnordost.

@DerDings
Copy link
Author

DerDings commented Nov 9, 2020

Interesting. It could also be added to the ramp quest, so mappers who are not sure if a ramp is a stroller ramp or a wheelchair ramp can measure the slope.

I think it is quite difficult to add this to to the existing quest in a feasible way, or do you have an idea how it could be done in detail?

I initially thought to add a similar quest: "what is the incline of the wheelchair ramp here?" for ways with ramp:wheelchair=yes.
But this would require a tag like ramp:wheelchair:incline, because the ramp may have a different incline than the steps themselves. Sadly, a tag like this doesn't exist yet.

@rhhsm
Copy link

rhhsm commented Nov 9, 2020

Interesting. It could also be added to the ramp quest, so mappers who are not sure if a ramp is a stroller ramp or a wheelchair ramp can measure the slope.

I think it is quite difficult to add this to to the existing quest in a feasible way, or do you have an idea how it could be done in detail?

Maybe by adding an option "not sure if it's a stroller or a wheelchair ramp" at other answers that opens the measurement dialogue?

@grafst
Copy link

grafst commented Jan 26, 2021

I like the playfull nature of this, but at the same time its usefull information that is gathered.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new quest accepted new quest proposal (if marked as blocked, it may require upstream work first)
Projects
None yet
Development

No branches or pull requests

5 participants