In last months I spend a lot of my hobby free time on iD tagging schema presets. Mostly helping with review and triage of submitted pull requests.
For 2026 I am planning to continue this. But I plan to also implement also some improvements myself. And for obvious reasons I prefer to focus on useful noncontroversial ones.
So I listed some of my ideas for 2026 - 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.
review and triage of pull requests submitted by others
Note that I am not promising that I will implement any or all of ones listed below. “all” is especially unlikely. Unless something very unexpected happens and I somehow get a financial support. That would allowing me to treat it as a job and spend far more time on it.
But either way I want to implement at least some of this ideas. And I am currently interested in all listed, and will focus on ones with more votes from community.
Also, if anyone is interested in implementing any of ideas below - please, feel free to get inspired and make a pull request!
I cannot promise in advance that your work will be merged - I cannot do it even for my own patched. 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.
IMHO the main thing to fix over anything else is to get rid of as many cases of iD relying on querying taginfo for tag values as possible.
The system made sense for Mapbox as a quick fix to their competitive issues at the time, but it has been, and continues to be, a constant source of problems and likely has more influence on actual tagging than any voting here.
A ballpark number* is that there are 180 keys/fields in the iD presets that get their values from taginfo.Some of them are quite surprising given that they are important tags with very high use, for example building.
* I haven’t checked if my preset mangling stuff is totally up to date with new iD field types, so this is a lower bound.
And I worried that 20 choice poll would be too much :)
this is unimportant enough to make ranking vote definitely not worth it, if it requires going to another page
not like I am is obligated to strictly follow the list, if anyone else would be interested they also can take any issue to work on (and please, in unlikely case of other people causing me to run out of the list here I can easily produce 20 more entries that seem worth doing and should not cause not needed controversy)
I fully agree that some focus on Car park tagging could be improved, even if it means adding a wide variety of search terms to catch.
I have no data, but surely “surface parking / car parks / parking” lots are the most common, yet i regularly struggle to find the correct details for them.
Certainly id-tagging-schema has room to curate more field values, but I’d think localization would be a more urgent reason than undue influence on tagging. After all, not everyone speaks OSM English. With some exceptions, the fields that still rely on taginfo mostly relate to “de facto” keys or open-ended tagging schemes, that is, the ones that say “user-defined” at the end of a long table on the wiki. It’s a lot less extensive than it used to be, as the codebase has matured.[1]
Does this figure count any field for which id-tagging-schema uses taginfo to discover popular values? In many cases, the field definition also provides a curated selection of values (which are also translatable). These values have an appearance that steers unfamiliar users toward them, while preserving the ability for the user to choose or type an unrecognized value. This type of field is appropriate for any key whose values are difficult to form a closed set around, such as model=* or genus=*. id-tagging-schema regularly accepts pull requests to add translatable strings for known values.
It’s a moot point for keys like building=*, as all the popular values have dedicated support anyways. iD may still surface an unforeseen value if the user starts typing its prefix, but in recent years, iD has filtered the taginfo suggestions to only surface values that have a significant share of usage, not just a high rank. Therefore, the main risk is that someone does a mass edit, causing a new value to percolate up to the top of this list, but it appears in monospace as a caveat.
iD uses taginfo more extensively for dropdown suggestions when entering a raw key or value manually in the Tags section. In this context, it probably has significant benefit in helping users avoid coining new keys and values by accident, for example by making a typo.
there is some pushback there, so if anyone has opinion on this topic feel free to join discussion (or make a pull request, especially if it also enables translations)
If you’ve signed up to help translate iD, you can correct the translation in the German localization, or override it for the Austrian German localization if the correct term differs between dialects. This will benefit all the projects that use id-tagging-schema. Otherwise, please report an issue in the id-tagging-schema repository with more details. Thank you.
That number is solely those that do not have any pre-defined values in the preset at all (as said I’m probably not catching all of these as I haven’t tracked schema changes over the last year or so).
As you point out, supporting translationsnon-OSM-speak value labels is a good idea and would be a useful side effect of curation.
I’ll leave spotting the obvious problem with that to the reader.
I’ve pointed this out many many times, I’m not against querying taginfo for suggestions (Vespucci has for a very long time had functionality to generate a complete preset that way, though it is somewhat hampered by wiki inconsistencies). I just don’t believe they are presented in a fashion to the, potentially newbie, user that lets them understand what they are doing (monospace font, seriously?).
if you have fact-based comment to add there I think it would be likely to be treated more seriously than factless ones, but obviously it is your own decision whether it is useful to participate
When essentially the 1st comment is that there is no problem obviously the participants are not actually interested in the matter, so why would I waste my time on something you started.
first comment is one that I made that is about technicalities, first comment made by someone else is also about technicalities, next is also about internal iD tagging schema syntax, next one is about technical stuff, next is ALSO about technical stuff…
which comment you meant?
And well, “someone disagreed with me so I will refuse to comment” is a possible strategy, but I suspect is not the optimal one.
I opened issue about the problem, did investigation a bit and convinced others to looks into it, someone made small script to detect related fields. From that you conclude that I am not actually interested in the matter.
As errata I want to note that I am in fact interested.
You are not obligated to participate, but if you want to state what others are interested in, probably more careful reading of discussion would be useful.
And really, if I am claiming that I believe A that means I am believing A, it is not some false flag operation to discredit A and push B in ploy to ensure that C will lose.
I have created this issue because you convinced me that it is a problem, though I am not convinced that it is the largest one.
this goes over my too small peasant head - is there problem or not? If yes, what is exactly the problem, at least as far as iD presets are concerned?
in this case iD suggestion powered by taginfo seems reasonable, I am (and others in the thread) confused by claim that man_made=guy_wires is in iD presets - as far as I can see it is not
Some of these ideas are just one example of a larger missing feature. For example, the “parking lot” search would ideally be fixed by improvements to the search function as discussed on that issue. Also, this:
While I think that is worth supporting those keys, it would be much better to support the conditional restrictions standard in a generic fashion.
Basically, mark a base key such as “maxspeed” as supporting conditional restrictions, and have some UI which lets you apply all the different conditions to such keys. Whether that’s forward/backward, vehicle type, user groups, time-dependent values, any other condition or any combination thereof.
Of course, that’s then a coding change rather than something that can be done just in presets.
