What’s the problem (Bottom Line Up Front (BLUF))?

See my original post, here: https://community.openstreetmap.org/t/lidar-mapping-of-roads/97100/14

Hi, everybody!

Motivated by the state of roads in the UK, I’m wondering if anyone is aware of any Open Source/ crowdsourced efforts to assess the condition of surfaces, and then to map them?

I’m aware of lower cost LIDAR equipment, and I believe that some Apple phones have a LIDAR capability.

I’m thinking of something like Mapillary/ Kartaview. Sensor imagery could be gathered, and then scored appropriately, so severity could be seen. I’m thinking that a 100mm pothole on an unclassified and little used road/ lane, would potentially be of less interest/ lower priority than a 50mm pothole on a major motorway/ autobahn/ freeway.

Obviously, potholes are just one example, other immediate possibilities are subsidence, wear and tear, accident damage.

I’d be keen to hear any thoughts/ feedback. Please add to this page, if you can.

Many thanks, Chris chris_debian UK

What can we do about this?

Road damages create comfort-, environmental- and security problems. Existing measurement technologies are very expensive and can only be used rarely. With smartphones you can measure often or in remote areas.

Regarding ‘mapping potholes’, I expect this to be a layer applied to OSM, not data contained within OSM. It will be open source information, for people that can use it. My thinking being that OSM isn’t a repository for other data, but it can help us gather data, and we may be able to give back to OSM.

What has already been done, by whom?

SmartRoadSense info@smartroadsense.it (seems to be broken), github and APK

• “Open Data” under the Open Data Commons Open Database License (OdbL)
• Map= https://smartroadsense.it/data/map/
• Privacy= https://smartroadsense.it/data/privacy/

Roadroid map

Kucai noted: “There was a blog post featured in weeklyOSM a while ago about measuring surface smoothness with a smartphone attached to a bicycle, using the vibration sensor. German post: Supaplex030’s Diary | Smoothness-Ermittlung über Vibrationsmessung mit Smartphone und Fahrrad | OpenStreetMap 1 English translation: https://translate.google.com/translate?sl=auto&tl=EN&u=https://www.openstreetmap.org/user/Supaplex030/diary/393565 1 I’d love to see this in an app”

How can OSM benefit form this?

IRI (International Roughness Index) Road quality/ smoothness index info can be used ‘Smoothness’ tag. Possibly ‘Surface’ tag?

StreetComplete https://translate.google.com/website?sl=auto&tl=EN&hl=en-GB&u=https://github.com/westnordost/StreetComplete/issues/1630

Other Beneficiaries?

hfs noted https://www.fixmystreet.com/ crowd-sources all kinds of problems. Potholes is one of the categories.

Where do we go from here?

• No further action, archive only.
• Capture requirement; prioritize MoSCoW; does a solution already exist? (I haven’t got one)
• Something else.

What is needed (Requirements capture)? (MoSCoW)

1. Open Source
2. Push Reporting
3. Volunteers?
4. 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.
5. 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?
6. Suitable for different vehicles, eg car/ truck/ bike
7. Supported platforms/ repositories: Play Store/ F:Droid, IOS?
8. Do we need to re-invent the wheel, or can we build on existing code?
9. API: Roadroid have already written an API, but this may not be released as Open Source (CHECK) and SmartRoadSense
10. Github?
11. Technical debt/ backlog?
12. What features exist in software, already? Are they important to us; should we plan to implement them?
13. Where will any data be hosted? GDPR, etc.
14. Agreed format for reporting- SmartRoadSense have already done some work on this

• LATITUDE, the latitude coordinate at the center of the section of the road where the roughness value has been estimated
• LONGITUDE, the longitude coordinate at the center 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 traveled in the last 6 hours. The remaining part of the dataset stays the same.

Supporting Information

Sample rates? Simon270 speculated- What sampling rate is required/frequency range is of interest? It would be nice to not have to log vast amounts of data but instead do FFTs of a suitable duration (e.g. 1s) and log the relevant spectral content.

Matheus Gomes

IRI International Roughness Index

I was a co-founder of a start-up that does something similar as Roadroid. Basically we can get accelerometer data from a smartphone to convert to IRI (~road quality index), so road managers can plan maintenance accordingly. I don’t work there anymore and I don’t know the current state-of-the-art on this matter, but what I do know from experience is that these values are not perfect, but it does work nicely providing an overall of road quality (excellent, good, bad, extremely bad). Some road agencies were (2 years ago) using this kind of technology, on a pilot basis. I am not aware on any road agency using this as a replacement of traditional surveys, nor letting their contractors do that. On the OSM side, while this excellent/good/bad/extremely bad information can be directly related to the smoothness=* tag, I am not sure if this info can be maintained on a regular basis. For example, on these apps their usually divide the surveys into segments (like 20 m/100 m/1 km segments), so one has to group or split (unlikely) that to fit the OSM road segments. Probably it can be done programmatically, trying to create something that matches OSM data, and feed it constantly. Not sure what you guys think about it, but this is something that cannot be easily done on my point-of-view.

-

dieterdreist

For example, on these apps their usually divide the surveys into segments (like 20 m/100 m/1 km segments), ideally they would align to OpenStreetMap way divisions so that we don’t have to split but it still would be a burden for mappers mapping “manually” because they would not know how to deal with it on way splits –