iD tagging schema improvements - which would be especially worth doing? Which should be avoided?

Mateusz_Konieczny · August 22, 2026, 4:18pm

Over last months I spend a lot of my time on iD tagging schema presets.

I am planning to continue this. Including implementing some improvements myself. And for obvious reasons I prefer to focus on useful noncontroversial ones.

So I listed some of my upcoming ideas for end of 2026 and beginning of 2027 - feel free to mark ones that you would especially want..

Also, are you aware of any problems with any of ideas listed below? If yes, it is the best moment to complain now - rather than after change is implemented and released. You can do this in this thread or - even better - in a linked issue.

0 voters

There are also other improvements that I am planning to do, mostly more hidden and technical but also needed. Part of it will not have any user-visible effects but will enable new improvements.

I also have not listed in-progress tasks that I am definitely planning to complete.

Also, if anyone is interested in implementing any of ideas below - please, feel free to get inspired and make a pull request! I have not claimed this tasks for myself, and I am definitely not running out of ideas.
I cannot promise in advance that your work will be merged - I cannot do it even for my own patches. But I can promise that created pull requests will be reviewed.

BTW, if you are not a programmer: iD preset is a large configuration file rather than code. Changing it is relatively easy, far easier than for example improving iD or JOSM editors.
It is not so easy to make unsupervised LLM capable of making useful pull requests, but it is much easier than coding.
And takes more OpenStreetMap expertise than coding expertise. If someone wanted to do something technical it may be potentially a good start.

PS Yes, I know that improving iD presets is not the maximally effective thing that I can do. But if someone has list of more useful things to code/program/configure in OpenStreetMap I would be happy to take inspiration from there. Especially if project is not already bottlenecked on reviewing incoming pull requests.
Note that I have zero experience with RoR and low expertise in C/C++, and limited interest to learn them as a hobby.

previous poll: (2025) iD tagging schema improvements - which would be especially worth doing? Which should be avoided? (old 2025 poll, 2026 one was posted)

fate of choices from the previous poll: (2025) iD tagging schema improvements - which would be especially worth doing? Which should be avoided? (old 2025 poll, 2026 one was posted) - #21 by Mateusz_Konieczny

VictorIE · August 22, 2026, 8:18pm

In this case, nobody needs to know the collection time.

Some sort of custom / seasonal opening hours (November-March; when ice / snow forecast; etc.) might be more appropriate here:

In both cases, colour=* is much more important. Red is typical for dog excrement, yellow for grit.

One way of doing this somewhat scientifically would be to go to pages like building | Keys | OpenStreetMap Taginfo and comparing the actual list of combinations that people use and cross-reference it with the “Fields” and “Add field”. This would indicate what fields / tags / keys that people have to hand-type (admittedly, people will have their own pre-sets for the things they normally map).

Repeat for as many keys as makes sense (20-50).

The “Add field” lists need to be sorted better.

On any road, after name=?, there should be surface=? and lanes=? before anything else.

On any road motorway>road>service, there should be sidewalk=? in the “Fields” list, not the “Add field” list.

If I populate sidewalk=?, then sidewalk:surface=? should appear.

On any road >service, there should be cycleway=? at least in the “Add field” list.

If I populate cycleway=?, then cycleway:surface=? should appear.

On any road >tertiary, there should be shoulder=?

On any highway way, there should be lit=?

On any highway way, there should be incline=?

On any highway=service, there should be lanes=? Roads in the highway=service category can vary hugely in width, e.g. lanes=22 Way: 137362964 | OpenStreetMap

In the UK, highway=trunk is interpreted as any main, long-distance road, a sub-category of A-roads. In Germany, it is interpreted as a motorway-like road that isn’t a motorway (for whatever reason) where pedestrians, cyclists and horses are typically banned.

On highway=trunk (only) bicycle=?, foot=? and horse=? need to be highlighted especially, in a way that is different to other roads.

Add a button so you can add / change / remove lifecycle tag prefixes from the currently selecteed object all in one click.

In one click, this:

description = Proposed gas-fired OCGT peaking plant.
name = Proposed Cashla Peaker Plant
power = proposed
proposed:operator = Bord Gáis Energy
proposed:operator:wikidata = [Q23038143]
proposed:plant:method = combustion
proposed:plant:output:electricity = 334 MW
proposed:plant:source = gas
proposed:power = plant
website = https://www.cashlapeakerplant.ie/

could become this:

description = Proposed gas-fired OCGT peaking plant.
name = Proposed Cashla Peaker Plant
power = proposed
operator = Bord Gáis Energy
operator:wikidata = Q23038143
plant:method = combustion
plant:output:electricity = 334 MW
plant:source = gas
power = plant
website = https://www.cashlapeakerplant.ie/

The first 3 tags would need adjustment, although power = plant would over-write power = proposed.

Some people prefer that name=* is not subject to life-cycle prefixes. demolished:name=Smalltown Primary School might be unfindable in some searches, where is modestly important that people searching for it need to be told that it no longer exists.

Mateusz_Konieczny · August 22, 2026, 8:52pm

big thanks for this list!

For start, I solved one

See remove collection_times for Dog Excrement Bin by matkoniecz · Pull Request #2752 · openstreetmap/id-tagging-schema · GitHub for the first and easiest one

With which key these would be tagged?

is it really useful if all have given colour in one area?

I am curious how useful such report would be

is it missing on any? Which?

is it missing on any?

this is broken tag it probably should not be supported at all, see also Key:shoulder - OpenStreetMap Wiki

is it missing on any?

it is shown already, right?

“In Germany, it is interpreted as a motorway-like road” local misinterpretation is not a strong reason to implement special features (also it would be probably editor change, not in iD tagging schema)

I know that this is annoying technical aside, but this would be implemented in iD and other editors, not iD tagging schema

(for ones I have not answered, I simply have no followup questions)

Dimitar155 · August 22, 2026, 10:58pm

It is quite a long list. Hopefully I haven’t added too many things in your todo list . I may go through some of them and make PRs/issues at some point but I will also take this opportunity to write them down for reference. Everything is up for grabs if anyone is interested in any of them.

I’ve marked some as low priority since they are mostly trivial UX things. Some require a lot of digging, possibly even community discussions and/or proposals. Those are marked as tedious.

There is no particular order, but still tried to keep them relatively connected.

name, service and usage on tram tracks (seems dubious)

some translation for frequency=0 on railway features (it means that it uses DC power but is not very obvious)

(low priority) units field on building=apartments can be in moreFields, not in fields

(low priority, could be very tedious) Align on a house tagging schema. Currently, iD has a generic building=house preset with a house=* field, hidden presets for specific types, and default presets using building=*_house (e.g., building=detached).

On top of that, there’s a third potential solution, using a key like building:type=detached/semidetached (example, not a suggestion). Resolving this fragmentation will definitely require broader discussion with the wider OSM community and other editor maintainers.

name on driveway, parking aisle, drive-through and emergency service is likely not needed

disused and/or abandoned school presets (unfortunately very common in small towns and villages in Bulgaria, likely elsewhere too)

Payment Types and Fee Amount on parking and charging stations (and possibly elsewhere) should appear only when fee=yes, not when it is empty - has issue

translatable values for denotation values (tree preset)

natural monument tree preset (a.k.a. centennial tree or “вековно дърво” in Bulgarian)

(low priority) material field for man_made=manhole (currently lacking)

(low priority) shape field for man_made=manhole (currently lacking)

(low priority) possibly count field for man_made=manhole? electric manholes can have multiple covers under which there is a wider hole.

(no clue why it is made like this but it exists, possibly the only linear manhole)

(low priority) table field for gazebos (there must be some tag for it, haven’t researched it)

(low priority) translatable values for club=* (possibly with some presets if there are popular values)

atm field for banks should also allow separate as value, not only yes/no.

(low priority) ref for billboards (and possibly other advertising features)

(low priority) faces field for billboard (just like clocks)

pumping station should also have field for substance (water, sewage, oil, etc.) (pipeline substation preset has such field)

depot type (on landuse=industrial + industrial=depot) should have translatable values (buses, trams, subway trains, trains, train passenger wagons, train cargo wagons, locomotives, garbage trucks, possibly other values). It should also allow more than 1 value.

on schools, denomination should show only if religion is present, religion should be hidden by default in most secular countries (if not all countries)

for religion field - on schools, `religion` field should not be shown by default in most countries (if not all countries) · Issue #2761 · openstreetmap/id-tagging-schema · GitHub
for denomination field - on schools, denomination should show only if religion is present · Issue #2755 · openstreetmap/id-tagging-schema · GitHub

(low priority) opening hours on parks is not needed in Bulgaria as a default field (possibly elsewhere)

(low priority) cinemas are missing 3D, 4D, IMAX tagging (cinema:3D, cinema:4D, cinema:IMAX)

crossing ways shouldn’t have traffic_calming - has PR

(low priority, likely tedious) hard to tag Wien-style tram stops. Trams run in the middle of the road, there is no platform. Instead the road lanes go up to the level of the sidewalk so passenger can enter safely. See this blogpost for photos. There is a variant for buses, where there is a cycleway on the road between the bus lane and the kerb.

(low priority, likely tedious) hard to tag raised junction (should it be on junction nodes or on affected parts of roads)? any tags for them? i’ve used traffic_calming=table on the junction node and the raised road segments. Can’t find any specific tag on taginfo.
Schema for illustration (usually the pedestrian crossings are also part of the raised segments):

destination on link roads lack translation ui (might’ve opened an issue, can’t remember)

public transit station nodes should be free floating, not vertexes

(low priority, likely tedious) missing preset for ventilation shafts (both general use and railway, possibly needs tagging schema refinement)

(low priority) street cabinet lacks translatable values for “utilities” field

(low priority) street lamps lack light:count field

(low priority, likely tedious) street lamps lack translations for lamp:type, mount and support

(low priority) hard to tag building passages (requires selecting foot path preset, tunnel, dropdown click, building passage). Not sure how it could be solved without a separate preset.

street fitness preset has blind person access field shown by default (likely not very common)

monument preset lacks subject:wikidata field

subject:wikidata fields adds subject:wikipedia (completely pointless, this information is already present in the referenced subject:wikidata item)

(low priority, likely tedious) The same thing applies to wikidata and other *:wikidata fields. Not having respective wikipedia tag could be controversiol for some of then but it should be researched at some point.

grave preset lacks buried:wikidata field. It should allow multiple values, since after the sanitary period another person can be buried in the same grave. The remains of the previous person are left in the feet of the newly buried person. The tombstone is usually updated to feature the newly buried person’s name.

(could be tedious) man_made=tomb lacks preset. Should have tomb and ref fields at the very least. tomb values are a complete mess, so descriptions are mandatory. Separate presets for the more popular ones would be welcome.

The currency field for ATMs should be shown by default in very few countries (if any) where more than 1 currency is being used

(low priority) natural=hill preset

dog park has address field (seems dubious)

(low priority, could be tedious) handrail field doesn’t handle handrail:left/center/right.

(low priority) historic locomotives, tanks, gun_carrieges (possibly others too) lack presets

(low priority) historic=monument/memorial for sculptures and busts (both presets are for artworks currently but busts and sculptures could be related historical figures and not just art). Might need forum discussion (there was one iirc)

(low priority, could be tedious) war memorial tagging (memorial=war_memorial vs war_memorial=yes). Once it is figured out, there should be some preset for them to allow easier tagging.

Mateusz_Konieczny · August 22, 2026, 11:32pm

in general, if there is no consensus on tagging it is too early for iD tagging schema

created subject:wikidata for monument in moreFields by matkoniecz · Pull Request #2753 · openstreetmap/id-tagging-schema · GitHub

AFAIK there is nothing wrong with say highway=bus_stop attached to highway=footway line, and it can be also placed as a free-floating node

which specific one is wrong? Or do you disagree with above?

this one is in poll! You can add it to your vote :) (“Make denomination field translatable”)

why service would be dubious, say service=yard?

for name - I opened named tracks are quite unusual by matkoniecz · Pull Request #2754 · openstreetmap/id-tagging-schema · GitHub (tram tracks inherit prominent name form light rail preset) as it seemingly obvious, maybe it will not vary across cultures and cities?

and it has a first protest, see named tracks are quite unusual by matkoniecz · Pull Request #2754 · openstreetmap/id-tagging-schema · GitHub (best reply there)

I really dislike this preset and I consider it as a big mistake adding extra complexity without good reasons, but maybe it sadly got accepted

created on schools, denomination should show only if religion is present · Issue #2755 · openstreetmap/id-tagging-schema · GitHub

Special message for frequency=0, for example on railway=rail (it is DC) · Issue #2756 · openstreetmap/id-tagging-schema · GitHub - I think there is no obvious way to do it right now

Maybe? List is fairly short there anyway

evil mode enabled

as soon as consensus is clear iD tagging schema will follow it

evil mode disabled

added to TODO ideas, will check

not sure is adding abandoned/disused variants for basically all presets a good idea, though I am also not having much better ideas (there was that ironically disused PR in iD repository that was working on lifecycle prefixes)

added to ideas file

is it established enough for inclusion? I have doubts.

(for some action to be taken is less obvious, I picked more actionable above I think - not sure about nanomappping for maholes and street lamps)

maybe it should go to moreFields?

Mateusz_Konieczny · August 22, 2026, 11:36pm

do you have examples of problems and how it could be better?

VictorIE · August 23, 2026, 12:57am

I will have to com back to you on the other comments.

The usual way things are sorted is:

Fields
Add field (main / important, sorted alphabetically)
Add field (everything else, sorted alphabetically)

Recently, I think I saw something with 3 lists of ‘Add field’ items. Maybe it was the heat, maybe the list was just too much for me. :)

At times, it can be difficult to find a particular key if the list is long; or the word I am expecting isn’t phrased the way I think it is; or I think it will be in one list, but is actually in one of the other lists.

With some tags, e.g. amenity=pub the ‘Add field’ list is rather long, with ~45 options to add. There I was looking for the ‘food’ key, but it’s called ‘Is food available?’

There are two options:

Only have one list of ‘Add field’ items, sorted alphabetically.
Have two or more lists and sort them into meaningful blocks, e.g. put all contact details, social media, etc. into one block. Put building appearance into one block (building:levels=, building:material=, roof:colour=*). Put wiki tags into one block (this is often the case anyway).

Mateusz_Konieczny · August 23, 2026, 1:25am

where you have seen more than one list of “Add field”?

Personally I am always using filter box (if I am not using raw tag editor)

VictorIE · August 23, 2026, 1:31am

Today, I learned something new. :( :)

Fizzie-DWG · August 23, 2026, 4:02am

Some shop / office / feature presets don’t include telephone, while others don’t give the option for a website

(& I can’t think of what some of them are just now!)

Mateusz_Konieczny · August 23, 2026, 5:38am

Do you mean including “Add field:” or just in main field listing where they show up even if empty?

Fizzie-DWG · August 23, 2026, 6:42am

This, thanks.

Some do appear in Add Field, some can only be added as phone= tags!

Dimitar155 · August 23, 2026, 6:56am

I meant station stations, not platforms or stop positions. Like train stations, subway stations and bus stations.

I meant denotation (urban, avenue, agricultural, natural_monument, etc.) for trees, not for religion.

60k uses, of which 30k were manual import/tag change. Even without the import/retagging, it seems to be established.

It is short when there isn’t much roof and facade tags. Furthermore, building:flats is used 2M times, while (the arguably more important) building:levels is used 42M times.

Mateusz_Konieczny · August 23, 2026, 7:45am

where they do not appear even in “Add tags”?

For main listings, see move phone= to more fields for shops in general by matkoniecz · Pull Request #2720 · openstreetmap/id-tagging-schema · GitHub that proposes removal of phone from main listing for shops in general and not yet released Add website field to standard preset for shops *help in testing and reviewing impact welcome* by matkoniecz · Pull Request #2669 · openstreetmap/id-tagging-schema · GitHub that added website there

here connection to highway=footway also appear legitimate to me

compared to over million of natural=peak | Tags | OpenStreetMap Taginfo

I guess it may be worth opening issue at Issues · openstreetmap/id-tagging-schema · GitHub if someone thinks it is established enough? No promises though at this stage

Dimitar155 · August 23, 2026, 8:53am

Pedestrian routing is handled via platforms (public_transport=platform) and footpaths.

Vehicle routing is handled via stop position (public_transport=stop_position) on roads/tracks and roads/tracks themselves.

Station nodes exist as some sort of centroid. They are often linked via type=public_transport relations to platforms and stop positions (see relation/11792856).

railway=station specifically requires floating node (or area). See Tag:railway=station - OpenStreetMap Wiki. I assume that this is the case for other station nodes, or at least it should be.

9_tab · August 23, 2026, 9:37am

Maybe a function to load a file with ones own preferred owns?

SimonPoole · August 23, 2026, 9:37am

IMHO both highway=scramble and highway=via_ferrata should be added.

Yes, the former is low use, but nearly anything is better than the current situation (highway=path being misused). Using this tagging is in itself not dangerous, it is actually the other was around, so iD should definitely include it and if it is only to nudge mappers to more appropriate tagging.

Mateusz_Konieczny · August 23, 2026, 10:07am

that would be editor work (like iD) by definition, changing tagging schema cannot modify editor

appears to be added without explanation to wiki some time ago, I opened Talk:Tag:railway=station - OpenStreetMap Wiki

Mateusz_Konieczny · August 23, 2026, 10:13am

highway=scramble sounds like natural=shrubbery but with much much lower adoption

not convinced that iD tagging schema should force this tagging through, despite very low usage etc.

(ironically last several times we had this discussion in opposite direction)

but via_ferrata seems like clearly worth supporting

9_tab · August 23, 2026, 10:30am

I’d probably remove “wifi” from most presets.

If there is a possibility to do region specific settings for shops, ref:FR:SIRET could be added for France.

The field for opening_hours should have more than 1 line. I don’t think the lookup function there helps, but I used it mainly to correct other mappers’ values.