Oh yeah, good catch @SK53
This is like #5438 / #5570

iD tries too hard to parse the numeric fields as numbers.

I think we probably need to take a first pass with a regex to decide whether the field is strictly numeric before trying to parse it.

Entering "561 ft" in the ele field is a tagging mistake. ele:imperial is used only once on the map - ele:ft is the more widely used tag (2k+).

It would be good if that could be picked up by iD - highlighting the field with a red border or similar if it's not strictly numeric. Basically input type="number" but without the browser's up/down controls, like the website field with type="url":

Entering "561 ft" in the ele field is a tagging mistake

Nope. Space-separated units have been used in OSM since time immemorial and most major clients parse them, such as osm2pgsql, mkgmap, OSRM, Graphhopper etc.

Right, regardless of whether it happens to be a "tagging mistake" in the "ele" field - this is something iD needs to support in all the numeric fields.

I've actually been thinking of adding a "default units" property to each field that can have such a thing. There are a lot of them. But right now we include the default unit in the field label sometimes, and in the placeholder sometimes, but none of this is done consistently, and I'm sure it makes a mess for translators.

https://github.com/openstreetmap/iD/blob/master/data/presets/fields/fire_hydrant/pressure.json
https://github.com/openstreetmap/iD/blob/master/data/presets/fields/generator/output/electricity.json

The ele key dates back to a simpler time when a lot of people thought the 123 unit format would be too unstructured for data consumers to be willing to parse. But that was before a whole host of keys started expecting that format, not to mention ref on ways and mini languages like opening_hours and turn:lanes. As things stand, ele stands out as a rare key that doesn’t accept units. I think that should change, but there should be some wider discussion so that data consumers aren’t caught unawares. It’s entirely possible that some renderers have implemented the same number parsing as iD and would misleadingly interpret 561 ft as 561 meters.

ideditor/schema-builder#15 requests a new field type for measured values, so that the Elevation field could display a dropdown menu for selecting meters or feet-and-inches.

As things stand, ele stands out as a rare key that doesn’t accept units. I think that should change, but there should be some wider discussion so that data consumers aren’t caught unawares.

https://wiki.openstreetmap.org/wiki/Proposed_features/ele_with_units

“(Meters)” was appended to the field name in openstreetmap/id-tagging-schema#95, which may decrease the likelihood of a user accidentally running into this trap, but regardless the field remains somewhat unintuitive in the United States.