# Extremely low detection rates of some important traffic signs **URL:** \ **Category:** Map data and detections\ **Created:** [July 24, 2023, 11:01am UTC](https://forum.mapillary.com/t/extremely-low-detection-rates-of-some-important-traffic-signs/7215 "2023-07-24T11:01:48Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![GITNE](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/gitne/32/70659_2.png) [@GITNE](https://forum.mapillary.com/u/GITNE)\ **Post date:** [July 24, 2023, 11:01am UTC](https://forum.mapillary.com/t/extremely-low-detection-rates-of-some-important-traffic-signs/7215/1 "2023-07-24T11:01:48Z")
While overall traffic sign detection works quite well, unfortunately there are still some outlying traffic sings. Especially, the yellow give way or ![regulatory--yield--g1](https://raw.githubusercontent.com/mapillary/mapillary_sprite_source/1465defa53e47e24b4cfb49e03288cc38652407b/package_signs/regulatory--yield--g1.svg "regulatory--yield--g1") sign, like the ![SE:B1](https://upload.wikimedia.org/wikipedia/commons/e/e0/Sweden_road_sign_B1.svg "SE:B1") in Sweden or ![PL:A-7](https://upload.wikimedia.org/wikipedia/commons/7/74/PL_road_sign_A-7.svg "PL:A-7") 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 ![regulatory--road-closed-to-vehicles--g3](https://raw.githubusercontent.com/mapillary/mapillary_sprite_source/master/package_signs/regulatory--road-closed-to-vehicles--g3.svg "regulatory--road-closed-to-vehicles--g3") sign also seems to suffer proper detection, especially when inside another sign. ---
**Author:** ![rnissl](https://avatars.discourse-cdn.com/v4/letter/r/f0a364/32.png) [@rnissl](https://forum.mapillary.com/u/rnissl)\ **Post date:** [November 1, 2023, 7:39am UTC](https://forum.mapillary.com/t/extremely-low-detection-rates-of-some-important-traffic-signs/7215/2 "2023-11-01T07:39:49Z")
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. ---
**Author:** ![boris](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/boris/32/71767_2.png) [@boris](https://forum.mapillary.com/u/boris)\ **Post date:** [November 1, 2023, 10:03am UTC](https://forum.mapillary.com/t/extremely-low-detection-rates-of-some-important-traffic-signs/7215/3 "2023-11-01T10:03:32Z")
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. ---
**Author:** ![rnissl](https://avatars.discourse-cdn.com/v4/letter/r/f0a364/32.png) [@rnissl](https://forum.mapillary.com/u/rnissl)\ **Post date:** [March 19, 2024, 7:00am UTC](https://forum.mapillary.com/t/extremely-low-detection-rates-of-some-important-traffic-signs/7215/4 "2024-03-19T07:00:14Z")
Hi Boris, has there been any progress regarding this issue 🤔 > **[Mapillary](https://www.mapillary.com/app/?lat=49.32377678998719&lng=12.213297312958503&z=15.84572519102522&trafficSign%5B%5D=all&pKey=803923741554229&focus=map)** > > Street-level imagery, powered by collaboration and computer vision. 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. Bye. ---
**Author:** ![boris](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/boris/32/71767_2.png) [@boris](https://forum.mapillary.com/u/boris)\ **Post date:** [March 27, 2024, 10:28am UTC](https://forum.mapillary.com/t/extremely-low-detection-rates-of-some-important-traffic-signs/7215/5 "2024-03-27T10:28:39Z")
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). ---
**Author:** ![canales](https://avatars.discourse-cdn.com/v4/letter/c/dfb087/32.png) [@canales](https://forum.mapillary.com/u/canales)\ **Post date:** [April 8, 2024, 2:31pm UTC](https://forum.mapillary.com/t/extremely-low-detection-rates-of-some-important-traffic-signs/7215/6 "2024-04-08T14:31:28Z")
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: - [A 60km/h speed limit sign](https://www.mapillary.com/app/?pKey=273625854520369) tagged as a 20 km zone - [A no trash sign](https://www.mapillary.com/app/?pKey=324512902533648), tagged as a 20 km zone A question to Boris and others in the thread: - 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? - Any feedback is welcomed. Thanks Diego ---
**Author:** ![canales](https://avatars.discourse-cdn.com/v4/letter/c/dfb087/32.png) [@canales](https://forum.mapillary.com/u/canales)\ **Post date:** [April 10, 2024, 10:58am UTC](https://forum.mapillary.com/t/extremely-low-detection-rates-of-some-important-traffic-signs/7215/8 "2024-04-10T10:58:00Z")
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](https://forum.mapillary.com/t/feature-request-flag-incorrect-traffic-sign-detection/1240) 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. ---
**Author:** ![boris](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/boris/32/71767_2.png) [@boris](https://forum.mapillary.com/u/boris)\ **Post date:** [April 10, 2024, 11:17am UTC](https://forum.mapillary.com/t/extremely-low-detection-rates-of-some-important-traffic-signs/7215/9 "2024-04-10T11:17:03Z")
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.