11th edition of the MUTCD

[Minh_Nguyen (Minh Nguyễn)]

@yopaseopor

@Minh_Nguyen

tagging scheme assumes that sign codes are constant, but what should we do when they aren’t?

I better said edition in OSM (except intermittent=yes) assumes that almost everything is constant. What should we do? Changing it. How? With a little help from my friends…

I’d encourage you to check out this correspondence table between the 2009 and 11th editions. Of course we can always retag traffic signs, but the question was more about what to do when a sign from the 2009 standard still sticks around even though it has been deleted as of the 11th edition. The sign doesn’t magically go poof. If a city has left up its signs and they’re currently mapped as traffic_sign=US:R7-21, could we retag them as one of the following for now?

• traffic_sign=US:R7-21:2009
• traffic_sign=US:2009:R7-21
• traffic_sign=US:R7-21(2009)

Or should we treat them as nonstandard signs (which they are as of last Wednesday)?

• traffic_sign=regulatory parking:fee=yes parking:maxstay=1 hour mutcd_compliant=no

@yopaseopor

@Minh_Nguyen

These 168 traffic_sign=* nodes suddenly became outdated overnight. Since some of the signs don’t have a clean one-to-one replacement, maybe someone can design a MapRoulette challenge to make it easy to retag them?

I can help you if you guide me exactly what you want. Probably a complex overpass query would be the best option to assure you next days or months you can reupdate the mission in MapRoulette with new results.

It probably only needs to be a one-time cleanup. It looks like we can create a quick fix tag fix challenge using a command-line tool. The challenge can suggest a replacement tag for each individual node that the mapper can approve or reject.