maxspeed="30mph" -> maxspeed="30 mph" (see Wiki)
See also https://wiki.openstreetmap.org/wiki/Automated_edits/LeTopographeFou#.23004_-_Typos
Thinking afterwards, this edit may have been too agressive... I hope it will not be perceived this way.
I wouldn't say "aggressive", but I would say "irrelevant" - anything that parses mph speed limits is going to parse "30mph".
Also, this change is making the tidying up of some earlier problem edits much, much harder.
Yes I agree with your second sentence to better answer your first point: "30 mph" is different from "30mph" exactly because parsing (and regular expressions) can't save everyone, everywhere and everytime. This is why this is relevant at the end. Having a consistent data set helps improving quality and good habits while reducing opportunities for future errors.
Saying that I'm not happy if I make work harder for others... Data are evolving everyday so I hope you have already considered that other maxspeeds are adopting/leaving/changing the "space notation" daily without my help even if I've drastically (and suddenly... thus aggressively) fixed the landscape for this speed limit.
(PS: I don't forget your request on real estates)
The idea that by editing tags to some kind of common format will somehow make it easier for data consumers is a pernicious fallacy.
Any use of a speed limit with or without "mph" in the tag will require some form of parsing, error detection and data wrangling. For instance the 11th commonest value is "RO:urban". Other values which need to be deciphered include "none (autobahns in DE I presume), "signals" (M25 etc). Plus the usual tag issues of trailing spaces etc.
As @SomeoneElse says each such edit which adds little to the data and does not really help data consumers makes it harder to deal with genuinely problematic edits.
Before making such changes I would recommend checking against the code base of routers such as Graphhopper, OSRM & mkgmap to see if they have problems with such values. Even then the main place to resolve such problems is in code for consuming the data.
The second problem with changing such values is that you are not addressing issue at source. It is users creating these tags and without persuading the users who are used to tagging it this way, then such tags will continually appear in OSM. Closing the loop involves talking to users, only that will actually improve consistency of tagging in OSM. Even then with free-format tags one always has to anticipate the unexpected.
Patching tags in this way to "make it easier for data consumers" may only encourage some such consumers in unrealistic expectations of OSM data. When their programs fail because of unusual values they'll blame OSM. If they plan around the realities of OSM & program defensively (as anyone who builds DBs from multiple source needs to do) they get the benefits & no surprises.
OpenStreetMap is a map of the world, created by people like you and free to use under an open license.
Hosting is supported by UCL, Bytemark Hosting, and other partners.