Again, the restriction here is far more likely to be height rather than width. Contact local mappers to find the exact value, though - don't just remove a value you don't understand. It's near a major freeway junction - I'm sure someone's familiar with it.

... and (re the MGW) note that most UK weight limits are actually MGW limits. It's rare to see _actual_ wieght limits (though they do exist, over weak bridges etc.).

I'd have thought that maxheight was more likely here. From memory none of the bits of El Camino here are particularly narrow. Best to ask local mappers.

Please don't just _remove_ data that you don't understand such as "maxweight=7ft6in" on way/130645490/history . Presumably either something here is maxheight 7'6" or there's a maxweight of (some value). The best way to find out what the previous mapper meant is to ask them.

Also, just in case you're not aware, OSM has a policy in place for under what circumstances automated edits should take place. In particular it says osm.wiki/Automated_Edits_code_of_conduct#Document_and_discuss_your_plans "you should discuss and document your plans beforehand". I'd suggest that all of your units changes (and also key changes such as maxweight to maxaxleload) deserve to be discussed - if only in the latter case to make data contributors and other data consumers aware that "maxaxleload" is an OSM tag that is already in use.

It would appear that you've made some maxweight values in the US incorrect here. For example, way/32719427/history was previously "maxweight=5 tons" and you changed it to "maxweight=5". 5 tons in the US is not the same as 5 metric tons.

An an aside, the reason why I suspect you found few US specific values is that previous recording had been tagfiddled away. For example, way/32719427/history (changed 3 years ago by a different mapper) now shows an incorrect value.

Firstly, show me the sign that says "13.607" - I'm guessing that it won't exist. What exactly is a local supposed to do when they see this value in an OSM tag? They will have no idea what it means.

If "consuming values like this is very confusing" then bluntly, you're doing it wrong. For many years I worked on large statistical systems that dealt with thousands or millions of data points. Always there will be outliers - stuff you can't trust because it "makes no sense in context". With user-contributed freeform data you get exactly the same problem. it's your job (as it was mine), when writing software that deals those values to handle "things that can't be understood" or "are probably wrong" to do the best you can with such data - ignore it, convert it, whatever. Just changing a few values in OSM will achieve nothing - if mappers don't know any different they'll add "15 US tons" next time too, and you'll have the same problem again

"The wiki" is not "OpenStreetMap". The most scarce resource we have is mappers. Anything that we do to persuade mappers (especially in the US) to stay away is counterproductive to the project. Please do not make US data harder to use for map consumers and mappers alike.

If you've got software that can't handle OSM values with units it sounds like a bug in the software to me. Please don't change OSM data when you should be fixing broken software.

Hi,
Just noticed way/332915516/history and way/332910596 here (while I was looking at something else). It seems odd that the footpath joins the road, runs parallel with it for a while, and then leaves again. I'm guessing in reality that actually the footpath runs along the service road for a bit, so splitting the service road and adding "foot=yes" to that bit would make sense, if that's the case.
Also, is the footpath here a signed "public footpath"? If so, adding "designation=public_footpath" would make sense, so that maps displaying that and people extracting that information for e.g. Garmin handhelds would know about it.
Cheers,
Andy

I genuinely have no idea what way/356368085 is supposed to be, and I was there only a few months ago.

I meant "revert your changes in which you changed them to bridleway". Sorry I didn't make it clear (English clauses can be ambiguous enough at the best of times).

I'd definitely revert the changes here and in Yorkshire to "bridleway" - it'll need a bit of investigation into "what do people map horse gallops as" (in the UK and elsewhere). The Yorkshire one's further complicated by the fact that it was mapped ages ago, and grass gallops can get moved around to wear out a different bit of field, so what's there now might not match what was mapped.

A horse gallop isn't really a bridleway though, is it? (at least, the ones I'm familiar with, in Notts and Yorkshire, aren't).

FWIW I've tended to map them as tracks, but made sure that access and surface are mapped properly, but having them as a distinct highway type isn't a problem as they are very much "their own thing".

Just checking - are you sure that way/146497638 and way/146497642 really are separate roads here? My recollection* is that what's marked as a B road between the eastbound and westbound sections of the A158 doesn't actually exist - it's just a turn lane on the A158.

* It was a few years ago I was last here, but I'd be surprised if it had changed that much. Certainly the underlying Bing imagery matches my recollection.

Perhaps "tourism=information; information=guidepost" like information=guidepost ?

Or if it's just something that points in a certain way for a long distance path, perhaps "tourism=information; information=route_marker"?

Based on is location, I wonder if it's a hospital entrance door that's only open during the week?

Thanks - looks good to me!

@urbanrambler1 OpenStreetMap is a collaborative project - we have to work together to try and create the best map. It's far better that someone asks about a tag value that they don't understand than they just change it to something that doesn't represent what's on the ground. If the current tagging of way/268273937/history (as a highway=path) is wrong, say so.