migrate 48 fields to type=measurement by k-yle · Pull Request #1988 · openstreetmap/id-tagging-schema

k-yle · 2026-03-05T13:57:08Z

This is a showcase of how the proposed measurement field could work.

The preview will be broken, and the CI will fail until ideditor/schema-builder#198 is merged & released.

My observations:

charge can't be supported, because it allows {currency} and {currency}/{time}
fire_hydrant:diameter can't be supported, because it allows unitless values, as well as m and in
incline, can't be supported, because it uses % which is dimensionless / unitless, it's not dimension=angle. Also, this tag frequently uses non-numeric values such as up/down/yes/steep

matkoniecz · 2026-03-05T15:42:35Z

+                ""
+            ],
+            "mile-per-hour": [
+                "mph"


maybe it would make sense to contain it to areas where mph are a thing?

currently iD offers both km/h and mph everywhere in the world, but the default option is chosen by country-coder.

So I think it would still be the responsibility of downstream apps to decide how they choose the default unit.

For example, some StreetComplete changesets contain a BCP47 extension like -u-mu-celsius, suggesting that SC already knows the users's unit preferences

This is a good argument for keeping usage in the schema. I don’t think it makes sense to keep bloating country-coder with redundant measurement properties by usage.

is gain from magic matches from usage is really worth specifying it over and over again and extra complexity?

In theory, dimension and usage mean that this PR shouldn’t need to repeat "inch: ["in"] in each preset that accepts inches.

If we omit dimension and usage, then id-tagging-schema will need to enumerate not only the allowable units but also the default unit by country. That would be much more verbose. The only exception is the combination of length and vehicle, because rapideditor/country-coder#30 implemented roadheight as a stopgap. It was tricky to implement. I don’t look forward to doing that a few more times over for the differences in ideditor/schema-builder#15 (comment).

My main worry is that relying on magic providing of "best" unit may end with ones not preferred for osm tagging, with this happening in way that will not be noticeable and may change as upstream package changes

Would there be at least way to see what is the outcome of that automatching?

I am worrying less about actual bugs and more where CLDR reasonably lists X first while for OSM tagging Y should be used.

This PR and ideditor/schema-builder#198 use units to enumerate the allowable units. Another possible interpretation is that they restrict the units from an external source such as CLDR to just the enumerated units. However, this PR does not address the default choice of unit when a user goes to tag something that hasn’t been tagged yet. It leaves the choice up to the client implementation. In order for the client implementation to choose correctly, it could:

Use country-coder to find the preferred unit by coordinate. This library is not specifically about OSM tagging conventions and has generally declined to duplicate CLDR locale data. It made an exception for roadheight but probably would not attempt to replicate CLDR’s entire unit preference table. It’s just too difficult to manage in a single GeoJSON file.

Use country-coder to find the country code, then look up the country code in CLDR based on dimension and usage. On Android and iOS, this second step would use a simple method call built into the platform’s standard library. For now, a Web application needs to use a library provided by Unicode, but a proposal to standardize dimension and usage lookups is on the standards track behind another proposal for unit conversion.

Use country-coder to find the country code, then look up the country code in a hard-coded table specific to that client. Every client would need to implement this lookup table separately.

Only a hard-coded heuristic could possibly account for an idiosyncratic choice by a local OSM community to tag in a unit that differs from real-world custom. Let’s say the Canadian community decides to tag maxspeed=* in kilometers per hour on railways, despite miles per hour being standard in the real world. In this case, option (B) would require an override, but it would be relatively rare and easier to maintain than a full implementation of (C).

Nothing is magical about this part of CLDR. In principle, id-tagging-schema could define a full lookup table for (C) so that clients wouldn’t have to maintain it themselves. If so, each field would still need to specify a dimension and usage, referring to a centralized unit-territory file under data/. Otherwise, these unit-territory preferences would bloat each field redundantly.

There's no harm in adding a field for ūsage, but i want to clarify some things:

#1988 (comment)
This is a good argument for keeping usage in the schema. I don’t think it makes sense to keep bloating country-coder with redundant measurement properties by usage.

The problem is, CLDR's ūsage data is very limited. So even if we add it, the regional defaults often wouldn’t make sense. For example:

dimension=length + ūsage=default says that 001
uses kilometres to measure length. CLDR has no ūsage for the circumference of a tree, depth of the ocean, elevation, track-gauge of a railway, height of a building, etc. All of these examples would not use kilometers.

In some cases, OSM tags map to multiple CLDR ūsages, For example, minheight is both person-height and ??? (there is no usage value that makes sense for building height)

In theory, dimension and usage mean that this PR shouldn’t need to repeat "inch: ["in"] in each preset that accepts inches.

#1988 (comment)
These unit symbols are getting repeated all over. Can we centralize them in a new JSON file under data/? It shouldn’t ever be the case that some unit symbol is acceptable in one key but not another.

Sure. But even if we define a mapping of CLDR units --> OSM units in a single global file, each field will still need to define:

the plausible units for that tag. For maxheight: meter, centimeter, foot-and-inch, yard. This is to exclude illogical values like nanometer and light-year.

the unit which does not require a suffix in the OSM tag. For maxheight: meter

some way to indicate whether the default value can be determined from CLDR data, to workaround the issue described above. For tags where CLDR's data is not sufficient, I guess data consumers have to use OSM's default unit and not support regional-specific defaults? :/

I was under the impression that the person-height usage was intended to mean “things of a human scale”, the kind of thing that gets measured in meter-and-centimeter in many metric countries and feet and inches in some metric countries (but not vehicle dimensions that are only ever in meters). In other words, I think they only split out a new usage when needed for a regional distinction.

My suggestion of a central units file is based on the fact that we have a single units article on the wiki. Some individual tagging schemes specify which units are acceptable or implied, but no tagging scheme comes with its own unique unit symbol. The individual field JSONs can continue to specify acceptable units that reference entries in the central units JSON.

i see, then I think #1988 (comment) (specifically ideditor/schema-builder@1611122) addresses most of these issues.

units defined in a single global file.

each field must define a usage

each field can optionally further limit the allowed fields

each field can define the unit which is implied by default

both PRs updated

1ec5 · 2026-03-11T14:51:04Z

I’m surprised we aren’t already reusing this field for rollercoasters (“You must be yea tall to ride”). I think the usage would differ in that case.

yeah, if we add this field to amusement park features in the future, we will need to split it into 2 JSON files. so no action required right now imo

1ec5 · 2026-03-11T15:00:55Z

+                ""
+            ],
+            "mile-per-hour": [
+                "mph"


This is a good argument for keeping usage in the schema. I don’t think it makes sense to keep bloating country-coder with redundant measurement properties by usage.

matkoniecz · 2026-03-11T15:55:39Z

(somehow I cannot rely inline)

This is a good argument for keeping usage in the schema. I don’t think it makes sense to keep bloating country-coder with redundant measurement properties by usage.

is gain from magic matches from usage is really worth specifying it over and over again and extra complexity?

1ec5

Some more fields to migrate over:

id-tagging-schema/data/fields/distance.json

Lines 2 to 3 in 93113ec

    
           "key": "distance", 
        
           "type": "text",

id-tagging-schema/data/fields/frequency.json

Lines 2 to 3 in 93113ec

    
           "key": "frequency", 
        
           "type": "combo",

id-tagging-schema/data/fields/frequency_electrified.json

Lines 2 to 3 in 93113ec

    
           "key": "frequency", 
        
           "type": "combo",

id-tagging-schema/data/fields/incline.json

Lines 2 to 3 in 93113ec

    
           "key": "incline", 
        
           "type": "combo",

id-tagging-schema/data/fields/gauge.json

Lines 2 to 3 in 93113ec

    
           "key": "gauge", 
        
           "type": "combo",

id-tagging-schema/data/fields/voltage.json

Lines 2 to 3 in 93113ec

    
           "key": "voltage", 
        
           "type": "combo",

id-tagging-schema/data/fields/voltage_electrified.json

Lines 2 to 3 in 93113ec

    
           "key": "voltage", 
        
           "type": "combo",

id-tagging-schema/data/fields/maxweight.json

Lines 2 to 3 in 93113ec

    
           "key": "maxweight", 
        
           "type": "combo",

id-tagging-schema/data/fields/maxweight_bridge.json

Lines 2 to 3 in 93113ec

    
           "key": "maxweight", 
        
           "type": "combo",

id-tagging-schema/data/fields/maxaxleload_bridge.json

Lines 2 to 3 in 93113ec

    
           "key": "maxaxleload", 
        
           "type": "combo",

(somehow I cannot rely inline)

(It’s because I responded to another comment as part of a larger review. You can click on the permalink for my comment to navigate to the original thread.)

1ec5 · 2026-03-11T21:42:52Z

+                ""
+            ],
+            "mile-per-hour": [
+                "mph"


is gain from magic matches from usage is really worth specifying it over and over again and extra complexity?

In theory, dimension and usage mean that this PR shouldn’t need to repeat "inch: ["in"] in each preset that accepts inches.

If we omit dimension and usage, then id-tagging-schema will need to enumerate not only the allowable units but also the default unit by country. That would be much more verbose. The only exception is the combination of length and vehicle, because rapideditor/country-coder#30 implemented roadheight as a stopgap. It was tricky to implement. I don’t look forward to doing that a few more times over for the differences in ideditor/schema-builder#15 (comment).

1ec5 · 2026-03-11T22:18:38Z

+        "units": {
+            "meter": [
+                ""
+            ],
+            "centimeter": [
+                "cm"
+            ],
+            "millimeter": [
+                "mm"
+            ],
+            "foot": [
+                "'"
+            ],
+            "inch": [
+                "in"
+            ],
+            "yard": [
+                "yd"
+            ]
+        }


These unit symbols are getting repeated all over. Can we centralize them in a new JSON file under data/? It shouldn’t ever be the case that some unit symbol is acceptable in one key but not another. (Some duration fields like maxstay=* use calendar units. They need a field type other than measurement but could potentially be powered by CLDR too.) We could go further and centralize most of these units specifications. The list of allowable units is generally determined by the dimension, not the individual key. units would only be necessary for overriding the usual list with some key-specific quirks, like ele only accepting meters.

done, unit suffixes are defined in a new file now.

If a unit is not defined in the global unit.json file, then it can't be used in any fields. for example we wouldn't include lightyears or imperial teaspoons since no OSM tag would ever want those values.

fields that have strict rules like ele can still further constrain the list of allowed units.

k-yle · 2026-03-19T13:15:34Z

#1988 (review)
Some more fields to migrate over:
[...]

Added all of them except incline, which won't work because:

% is dimensionless / unitless, it's not dimension=angle.
this tag frequently uses non-numeric values such as up/down/yes/steep

matkoniecz · 2026-04-01T20:43:44Z

+    },
    "minValue": 0,
-    "label": "Duration (minutes)",
+    "label": "{duration}",


I am not sure whether we want to remove hint

are we assuming that iD and other will add it back, somehow, using impliedUnit

but then we have maxspeed where we have impliedUnit but it should be pushed far less strongly

matkoniecz · 2026-04-01T20:45:09Z

+    },
    "minValue": 0,
-    "label": "Duration (minutes)",
+    "label": "{duration}",


but then we have maxspeed where we have impliedUnit but it should be pushed far less strongly

matkoniecz · 2026-04-01T20:46:02Z

+    "type": "measurement",
+    "measurement": {
+        "dimension": "speed",
+        "usage": "default",


maybe we should not need to state default and default to default as value?

matkoniecz · 2026-04-01T20:59:46Z

+    "type": "measurement",
+    "measurement": {
+        "dimension": "power",
+        "usage": "default"


is there reason to not specify here and similar MW as preferred? Is placeholder enough?

I am not sure how it will work in iD in practice, I guess it can be tweaked later?

matkoniecz · 2026-04-01T21:30:43Z

+    "type": "measurement",
+    "measurement": {
+        "dimension": "volume",
+        "usage": "fluid",


what is the benefit of specifying it here? (I am still confused by that entire usage thingy, and trying educate myself via https://cldr.unicode.org/ )

k-yle · 2026-04-07T11:37:37Z

i just learned that railway:position and railway:position:exact use mi:12.3 instead of 12.3 mi 😭

and that tag uses a "fake" unit called pkm in argentina. i guess we can't support that field

k-yle added waiting-for-schema-builder-change waitfor-other This issue or PR is blocked by something that is not covered by other waitfor-* labels labels Mar 5, 2026

k-yle marked this pull request as draft March 5, 2026 13:57

k-yle mentioned this pull request Mar 5, 2026

Implement a schema for the measurement field ideditor/schema-builder#198

Open

matkoniecz reviewed Mar 5, 2026

View reviewed changes

Comment thread data/fields/ele.json Outdated

matkoniecz reviewed Mar 5, 2026

View reviewed changes

Comment thread data/fields/ele.json

matkoniecz reviewed Mar 5, 2026

View reviewed changes

Comment thread data/fields/maxheight.json Outdated

matkoniecz reviewed Mar 5, 2026

View reviewed changes

k-yle force-pushed the kh/measurement branch from f06fc7d to d907cd5 Compare March 10, 2026 10:44

matkoniecz reviewed Mar 11, 2026

View reviewed changes

Comment thread data/fields/diameter.json Outdated

matkoniecz reviewed Mar 11, 2026

View reviewed changes

Comment thread data/fields/ele.json Outdated

matkoniecz reviewed Mar 11, 2026

View reviewed changes

Comment thread data/fields/ele_node.json Outdated

1ec5 reviewed Mar 11, 2026

View reviewed changes

k-yle mentioned this pull request Mar 18, 2026

[Planning] Major release version 7 with breaking changes ideditor/schema-builder#196

Open

34 tasks

k-yle force-pushed the kh/measurement branch from d907cd5 to 5848919 Compare March 19, 2026 13:16

k-yle changed the title ~~migrate 39 fields to type=measurement~~ migrate 48 fields to type=measurement Mar 19, 2026

migrate to the measurement field

8994827

k-yle force-pushed the kh/measurement branch from 5848919 to 8994827 Compare March 27, 2026 09:03

matkoniecz reviewed Apr 1, 2026

View reviewed changes

k-yle commented Apr 7, 2026

View reviewed changes

Conversation

k-yle commented Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

1ec5 Mar 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

k-yle Mar 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

matkoniecz commented Mar 11, 2026

Uh oh!

1ec5 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

k-yle commented Mar 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

k-yle Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

k-yle commented Mar 5, 2026 •

edited

Loading

1ec5 Mar 12, 2026 •

edited

Loading

k-yle Mar 19, 2026 •

edited

Loading

k-yle commented Mar 19, 2026 •

edited

Loading

k-yle Apr 7, 2026 •

edited

Loading