Further thoughts on gathering Road Surface information
Posted by chris_debian on 3 April 2023 in English. Last updated on 4 April 2023.Ok, following on from my earlier writing, I can confirm that I have installed and tried capturing data with both the SmartRoadSense and Roadroid Android applications, on my Pixel 6. Both apps had good points, and ‘areas for development’. I was only able to capture data, submit it, and see it on a map, with Roadroid. My understanding is that I can’t do this with SmartRoadSense, because the app infrastructure is currently dormant, due to EU funding coming to an end, but I understand from the devs, that they are about to reinvigorate the project.
Lars Forslof (Roadroid) is doing some excellent work with his propriety solution, but I think the nature of his objectives, are business oriented, and enables a ‘customer’ to request survey coverage for a defined area, which is then coordinated, at a financial cost.
My main questions/ thoughts now, are:
- Is road surface data useful to anyone? I would suggest it is useful for deciding on routing, and can be used under open source terms, to enable interested bodies, such as highway/ local authorities to have an initial understanding of where surfaces don’t meet a required standard.
- Is OSM the right place to record the values?
- Can the open source community encourage the good people at SmartRoadSense to work with us, or do we need to create a new app, with infrastructure? The algorithm used to process the data is currently closed source. My preference would be to work with SmartRoadSense, and have a backlog of potential improvements, hosted on GitHub https://github.com/SmartRoadSense
- Encourage interested users to install the SmartRoadSense APK, and to give feedback at the GitHub address. The app didn’t appear in Play Store, in the UK on a Pixel 6, so I’ve used APK https://m.apkpure.com/smartroadsense/it.uniurb.smartroadsense
- I will write to the SmartRoadSense devs, to highlight these thoughts.
What is needed (Requirements capture)? (MoSCoW)
M= Must Have S= Should Have C= Could Have W= Won’t Have
-
Updated with initial triage thoughts.
- Open Source (Must Have)
- Push Reporting (Must Have)
- Volunteers (Must Have)
- Map to indicate surfaces not already mapped (like OpenStreetCam/ Kartaview does (and Mapillary, which I believe is now closed source (Facebook. Meta)) and to indicate current position. (Should Have)
- Colour scheme showing age of last survey (Eg, if mapped in 6 months, one colour, if never mapped, or older than 6 months, then another, or no colour.). Do we need to aggregate the last 3 surveys, for better results? (Should Have)
- Suitable for different vehicles, eg car/ truck/ bike (Should Have)
- Supported platforms/ repositories: Play Store/ F:Droid, IOS? (Should Have)
- Do we need to re-invent the wheel, or can we build on existing code?
- API: Roadroid have already written an API, but this may not be released as Open Source (CHECK) and SmartRoadSense (Could Have)
- Github or other central repository to publish code? (Must Have)
- Technical debt/ backlog? (Must Have)
- What features exist in software, already? Are they important to us; should we plan to implement them?
- Where will any data be hosted? GDPR, etc.
- Agreed format for reporting (Must Have)- How do we make captured data into a format that works with osm.wiki/Key:smoothness ? SmartRoadSense have already done some work on values to capture: • LATITUDE, the latitude coordinate at the centre of the section of the road where the roughness value has been estimated • LONGITUDE, the longitude coordinate at the centre of the section of the road where the roughness value has been estimated, IRI International Roughness Index • PPE, the average roughness level of the road section • OSM_ID, the ID of the road in the OpenStreetMap dataset • HIGHWAY, the road category according to the OpenStreetMap classification • UPDATED_AT, the last update of the data for that particular road section Periodic updates- Both maps and Open Data are updated every 6 hours. Each new update differs from the previous one just by the data points associated with roads that have been travelled in the last 6 hours. The remaining part of the dataset stays the same.
Discussion
Comment from vincentxavier on 4 April 2023 at 18:58
This culd target road cyclist as they want to know how smooth is the road.
Comment from chris_debian on 4 April 2023 at 19:08
I agree, Vincent.
Chris
Comment from osmuser63783 on 10 April 2023 at 08:04
Re questions 1 and 2: I think it would be great if we had an app to systematically add smoothness data to OSM, if it can be confirmed that the accelerometer measurements correlate well with OSM’s definition of the smoothness tag. This data is missing from many ways and adding it could benefit a lot of users: I know GraphHopper and OSRM already take this tag into account, as do CycleStreets and some Brouter profiles.
StreetComplete has a quest for adding it, but in my experience it’s hard to make the correct decision when walking, because the tag is about movement on wheels. When cycling or driving, you eventually develop an intuitive understanding of how the different values feel. A well working app could average observations (while still making sure that every change is reviewed and attributed to one user), improve objectivity, and help beginners make the decision between similar values.