While overall traffic sign detection works quite well, unfortunately there are still some outlying traffic sings. Especially, the yellow give way or sign, like the in Sweden or in Poland are still detected as false negatives. White give way signs seem to be of no issue. Since this is a right of way sign, the lack of this sign could be considered more than just an annoyance.
Furthermore, the no traffic or sign also seems to suffer proper detection, especially when inside another sign.
In my opinion traffic signs should be limited or prioritized by country.
For example, in Germany we do not have this kind of yellow signs at all.
But on my tracks, I do have a lot of such incorrectly detected signs.
It would be nice, to allow correction of such incorrect signs via web frontend.
Thank you for the feedback. We’d like to improve detections over time. Right now we are working on some infrastructure pieces that will make this easier to accomplish later on. Thank you for your patience with the current detection models in the meantime.
This is what I’ve meant: German traffic signs with white background (50) and non German traffic signs with yellow background (70) in the same German area.
No updates yet, but we appreciate the examples. This is something we’d like to improve over time (but likely won’t be able to in the immediate future unfortunately).
Hi everyone - From our side we are debating/planning on developing a Qgis plugin that could help streamline the correction process of wrongly detected signs, with a special focus on speed limit traffic signs:
Identify duplicated traffic signs and de-duplicated them.
Allow visual verification of detected traffic signs, marking them as correct or wrong, and if wrong entering the correct value.
Two few examples of wrongly identified speed limit traffic signs in Brazil and Mexico:
Do you know of any existing Qgis plugin that allows doing something along these lines to avoid duplicating work? We have already identified the deprecated go2mapillary plugin and try to rescue as much as possible, but wondering if there is anything else out there.
Would this be of any value or should we instead wait to see the improvements Mapillary will launch (hopefully in the the short term) to correct wrongly detected traffic signs?
Perhaps, I should have given further background to our specific use case and what we are planning to do given the data and tools we have at our disposal.
My organization will be working with a few Latam cities, where we will be creating a road network database with speed limits both for internal and public consumption. An important aspect of gathering speed limits at the road segment level, will come from speed traffic signs (explicit speed limits), thus our emphasis on speed limit traffic signs.
We want to use the data from the speed limit traffic signs detected by Mapillary’s object detection algorithm for these cities and have it in our hosted database, but as I pointed out before, we have identified many case where the algorithm incorrectly detected traffic signs and we would need to fix these somewhere.
We obviously prefer if Mapillary would provide a way to correct these signs directly in their platform or alternatively improve their detection algorithm, by using different training datasets (perhaps at the country level), as opposed to us fixing them in our hosted database. However, given that we need to deliver this work during 2024, unless Mapillary could share a tentative timeline for this work, we would not be able to wait for it, as it could take 1 or 2 years (this feature request of flagging incorrect traffic sign detection is from 2017 and still nothing). @boris is there any timeline you could provide or perhaps tell us if it would be done during 2024?
The alternative we identified is to create a Qgis plugin, where we could clean this data in a semi-automatic fashion. We would apply it to speed limits, but ultimately it could work for any type of traffic sign.
Hi @canales - I think this is unfortunately not likely for 2024 for Mapillary - so given your timeline I think it makes sense to look at alternative approaches.