matkoniecz
commented
4 years ago The tricky part is that GPS based elevation (and even location) is often extremely inaccurate. I never tested barometer but accuracy would likely be even worse.
Closed RubenKelevra closed 4 years ago
matkoniecz
commented
4 years ago The tricky part is that GPS based elevation (and even location) is often extremely inaccurate. I never tested barometer but accuracy would likely be even worse.
FloEdelmann
commented
4 years ago Why not simply make a normal quest out of this? That'd then be similar to the AddStepsIncline quest.
HolgerJeromin
commented
4 years ago I do not want to add incline=no at EVERY highway in my quite flat surrounding.
https://www.geoawesomeness.com/accurate-altimeter-gps-watch/
The general rule of the thumb is that vertical error is three times the horizontal error. If a decent signal reception is available, a modern GPS receiver should be able to give elevation data accurate to a range of 10 to 20 meters (35 to 70 feet) post correction.
With an 100 meter long osm way you do not want to analyse the incline with +/-15% which is about the data range you want to gather.
westnordost
commented
4 years ago Well, it could be quite accurately measured with the rotation sensor. But that would require the user to shortly put his smartphone on the floor. I don't really want to require this of the users. I also suspect that people would tend to not put it on the floor but tilt their smartphone how they believe the incline is where they are and thus only recording quite inaccurate data. Also, that wouldn't really work for steps unless they have a handrail or ramp.
RubenKelevra
commented
4 years ago I do not want to add
incline=noat EVERY highway in my quite flat surrounding.
Noone suggested that you need to do this 🤔
The tricky part is that GPS based elevation (and even location) is often extremely inaccurate.
Agreed. The absolute elevation isn't accurate, but the relative is - when comparing two points with good reception in short succession.
The gathering of 3 points will additionally eliminate any linear drift up and down.
I never tested barometer but accuracy would likely be even worse.
Barometer drift very very slowly, only your mapping in a thunderstorm this might be different.
A good barometer is probably accurate to a degree that we would need to ask the user to hold the phone on the same height.
Barometers are not absolutely accurate, since the weather changes the pressure. If you have either a known pressure or a known height you can calibrate it.
Well, it could be quite accurately measured with the rotation sensor. But that would require the user to shortly put his smartphone on the floor. I don't really want to require this of the users. I also suspect that people would tend to not put it on the floor but tilt their smartphone how they believe the incline is where they are and thus only recording quite inaccurate data. Also, that wouldn't really work for steps unless they have a handrail or ramp.
That's an interesting idea, but you would multiply any error by a large number... since just a small bump in the road would change the results.
Since there's doubt that this could be accurate I gonna test this, I got 3 devices with GPS, so I'll try if they lead to the same results on a stretch of road :)
A third method would be to do it visually - if we use a distinctive point on the map for the measurements the user could point a crosshair on his camera view on it. After entering the height of the user we can calculate the angle.
This also works for steps: The user need to bring the edge of the first step with the last step on the same height by tilting his phone, when looking down the steps.
When the edges align we can use the angle directly for the steps.
matkoniecz
commented
4 years ago I do not want to add incline=no at EVERY highway in my quite flat surrounding.
Noone suggested that you need to do this thinking
How SC would detect where this quest is worth asking?
RubenKelevra
commented
4 years ago I do not want to add incline=no at EVERY highway in my quite flat surrounding.
Noone suggested that you need to do this thinking
How SC would detect where this quest is worth asking?
Well, the idea is to detect the incline on ways which are currently tagged with incline=up/down. That's what I meant with:
Affected tag(s) to be modified/added: incline=up / incline=down
Sorry if this wasn't enough of an explanation.
I tag ways when I know they are on a hill with the direction of their inclination. But this is hardly useful, as it is just a binary value.
Sure, there are elevation models, but this doesn't really help, they are extremely low in resolution, smoothed and thus doesn't work in canyons which appear much shallower.
Additionally a way might have some kind of embarkment, making it flatter or steeper than the surroundings.
A somewhat exact value would help to route bicyclists the most efficient route, to avoid steep grades and choose less steep ones to or circumnavigate a hill this way.
Here's an example:
https://www.openstreetmap.org/way/155649367
This way has supposedly 18% incline. Not sure if there's now a sign, but when they opened there was none. Never such a steep cycleway made for fast traveling.
Some people might want to avoid it and since that's basically on the side of an embarkment made for train tracks the embarkment actually makes it more steep.
Here's how Komoot shows a route over this paths.
Either Komoot ignores the incline, or doesn't read it at all. The graph shows definitely not a sharp dip somewhere, so digital elevation data is used.
westnordost
commented
4 years ago Though, "Please walk down this street to record the elevation data", even it is accurate enough (@HolgerJeromin says it is not) is not really something that would fit into the StreetComplete format. This is not a question that is answered by the surveyor, it is... something else. I think requiring the user to walk up/down each road while having this one quest open (and not be allowed to solve other quests while doing that) is too much to ask of the user.
Gathering of elevation (=> incline) is data that can better be recorded automatically in the background rather than requiring an active action from a surveyor. And it is already possible to contribute this way. The "upload GPX trace" feature on osm.org. Elevation data is usually included in the GPX trace. This touches upon this point in the guidelines:
💵 Valuable Surveyors: Surveyor time is valuable, they shouldn't be asked to complete data that does not require a survey and can more efficiently be done remotely.
Remote mappers can then load the collected GPS data into JOSM and tag the ways accordingly. Using hundreds of GPS traces also smoothens out any error/inaccuracy mentioned by @HolgerJeromin. To summarize, this way of contributing this data is more efficient and more accurate.
What's still a bit missing is a tool with which one can display the aggregated GPS data in a reasonable way. JOSM currently just dumps all GPS traces as indistinguishable lines onto display, this is not very helpful. With a more smart display (with graphs like the one you posted and stuff), the following characteristics of a road could be derived from the traces:
So maybe open a feature request at JOSM to extend support on displaying GPS trace data. Currently, it is only really used in aligning imagery.
(Grab already creates dumps of such analyzation results of their (private GPS traces) data here https://grab.community.improve-osm.org/dumps/ , some of that data is used to create quests in STreetComplete)
RubenKelevra
commented
4 years ago Yeah, I get your point.
On the other hand this only applies to GPS measurements. The discussions opened some more options which maybe worth exploring.
I did some testing how the different methods stack against each other.
Google has 3D photometric images, so the incline should be pretty accurate in this case.
While this isn't any data we could actually use, it should give us an indication how accurate different methods are.
So I used a simple app, which combines the tilt of the phone as an overlay to the image. This obviously only works when you can aim at something, so road segments on OSM are rather bad for this.
I've aimed between two points which are 78m apart in OSM which gave me visually a height difference of 6.6m while Google shows 7m difference.
This method would be also interesting for steps, since you can aim down the top of the steps to get the incline.
Visual 8.44%
Ground level: 7%
Google Earth: 8.97% +/- 0.6
GPS: 10.13%Note: The inaccuracy on Google maps is due that the height is only available in integers.
Visually aiming at points would allow us to do quests, since the user just need to point the camera to a point he marked on the map, and enter his height. We could then fill in the incline to the quest and let the user confirm.
westnordost
commented
4 years ago Related: #2249
General
Affected tag(s) to be modified/added: incline=up / incline=down Question asked: Do you want to walk this way forth and back to discover the average incline?
Checklist
Checklist for quest suggestions (see guidelines):
Ideas for implementation
When the GPS fix is 3D with enough accuracy (or if there's a baro available) a phone could pretty accurately be used to discover the average incline of a way previously only tagged with up or down.
If only GPS is available the user should be asked to walk once in both directions, while with a baro sensor this isn't necessary.
If the user has chosen yes, one end of the way will light up and if the user reached this point he is asked to stand still for some seconds. After that the GPS accuracy is measured - if it's high enough the user will be asked to walk to the other end and this process repeats until 3 measurements are taken (two at the start point and one on the end point).
If the difference is below a threshold like 15% the average is taken and tagged as a percentage.
Element selection:
Any way with up/down which is longer than say 15 meters (and is not a stairway) - since on very short distances this measuring method will lead to too much noise.