OpenStreetMap
Is editing config files very scary for you? If not, you can help with iD tagging schema
Posted by Mateusz Konieczny on 1 June 2026 in English.iD tagging schema is a recording of various information about OpenStreetMap tagging. It is done in format allowing it to be both machine-readable and human-readable.
There are various ways how it can be improved, some relatively complex, some very easy.
We have list of things that should be fairly easy to implement
If anyone is interested in contributing - it could be a good start and I can promise quick review, if they would be implemented by someone.
This changes will be quite easy to write, it is not a programming - it is rather editing a relatively simple config file. But they still need to be tested, which actually takes most of the time. And if editing config file is not a very scary task and https://en.wikipedia.org/wiki/JSON#Syntax is not terrifying, then you have a good chance to be able to do it.
Review afterwards should be quick like for another group of simple tasks
If you would be interested in helping with iD tagging schema, and you have any amount of technical ability… But this supposedly simple tasks are not obvious, feel free to ask here for help and I can guide you to your first PR.
Even if you never did anything with git/github etc, this could be a good start. And maybe you would later implement a more complex task
Discussion
Comment from imagico on 3 June 2026 at 12:44
But what if it is? (referring to the question in your diary title)
Or let me phrase it in a question back:
If you want people to contribute to the project and value their contributions why do you require them to provide their contributions the the form of hand editing JSON files?
I kind of already know the answer to that question: Because that happens to be a convenient form for the software developers to write a reader for. But is that a wise prioritization?
Personally, i am not scared by complex file formats. But every time i see a project maintaining information that is to be curated by humans in a format like JSON i primarily sense a statement of their priorities which implicitly states that - even if they would like my contribution - they don’t value it. Because if they did they would have made a different choice.
I know i am kind of barking up the wrong tree here since this was not your choice. But anyway…
Comment from Mateusz Konieczny on 4 June 2026 at 09:13
Because if someone is not capable of doing this, they are unlikely to be able to test changes either.
In theory it would be possible to write some tool allowing editing it in a different way but it would take a lot of effort and I am dubious is it lowering threshold much.
If someone is able to contribute by reporting issues - it is also welcome, but it is not a bottleneck at all right now. Still ideas are welcome.
which one?
Comment from imagico on 4 June 2026 at 13:08
What you mean by testing here is testing within the programmer centered testing framework currently in use. But having that as the only available way of testing is - again - a deliberate choice setting certain priorities.
I don’t think much is neceesary from the editing side in terms of writing new tools. There are plenty of well established tools on that front - for humans writing and editing structured text. Where more work would be required is processing that information from the data user side because you would not have cheap human workers pre-chewing it into a convenient JSON structure. But that i already mentioned.
Yes, as i said - i understand the prioritization that has led to how things are. I am just questioning that this is a wise prioritization.
But i am also curious where you think the bottleneck is. You seem to imply that you think it is technically skilled contributors in some form. But i am not sure if you think this is a scarcity in volunteering (i.e. working for free) or a scarcity in people having the necessary technical skills in general.
I find this interesting in particular because from my perspective the task of developing and maintaining a tagging schema for use in OSM editors would be a project that barely requires any technical skills at all, where the main qualifications you’d need are familiarity with mapping practice in OSM and with the world wide geography OpenStreetMap tries to document. Plus - since the concept of tagging schema here includes verbal and symbolic representation of the tags - verbal and symbol design skills in that context.
Comment from Mateusz Konieczny on 5 June 2026 at 07:08
You mentioned “project maintaining information that is to be curated by humans in a format like JSON i primarily sense a statement of their priorities which implicitly states that - even if they would like my contribution - they don’t value it”
Do you have a specific idea how tagging schema would be maintained in way that would reduce this problem?
Comment from Mateusz Konieczny on 5 June 2026 at 07:18
I think it is in large part true already, some changes can be easily made with little technical skills required. This post is attempt to make people aware of it.
in the end tagging schema is machine-readable configuration for editing software, so software testing is impossible to be entirely avoided as far as I can see
Comment from imagico on 5 June 2026 at 10:27
Huh? I thought our discussion so far clearly established that technical skills are a fundamental prerequisite for active contribution at the moment. That everyone who is not able or willing to edit JSON or to test their changes within your framework is practically limited to petition others to do changes for them.
That makes it much clearer - thanks.
So the primary goal of the project is to technically provide and maintain the tagging schema in a form optimized for ingestion by the software that uses it and decidedly not to cooperatively develop and maintain the schema on the semantic, non-technical level.
The problem i see with that approach is that it is not sustainable because there is no separate project for developing and maintaining the schema on the semantic level - you essentially have this as a footnote to a project with purely technical goals while the main level of added value human work needs to go into for sustainability is the non-technical level.
But this is, of course, just how i see it and you indicated you perceive the bottleneck to be somewhere else. I am still interested in learning where you exactly see the bottleneck.
I am hesitant to make specific suggestions. What i would and could recommend would be under the goals i see - which, as established above, are different from the actual ones. That is to rethink both the structure and the low level format in which the information is maintained and edited.
Under the premise that a text based format suitable for managing in a VCS is needed a natural choice of low level format optimized for intuitive editing by humans as drop-in replacement for JSON would be Markdown. But i lack the full understanding of the overall scope of structural information in the project to give a concrete recommendation on the structural level. It is likely that for a contributor centered approach substantially changing the structure is advisable.
Comment from Mateusz Konieczny on 5 June 2026 at 14:42
yes, that is purpose of iD tagging schema project
that is done at OSM Wiki, tagging forums, tagging mailing list
Comment from Mateusz Konieczny on 5 June 2026 at 15:23
and few other places where OSM mappers communicate
but if we want to support in editors things beyond “now edit raw key-value pairs” this info needs to be recorded in machine-readable form somehow, and obviously this form needs to be also human-readable and human-editable
I do not expect it to be any better for structured data expected to support info such as https://github.com/ideditor/schema-builder does
Comment from imagico on 5 June 2026 at 15:37
Does not seem like that to me. Example:
https://github.com/openstreetmap/id-tagging-schema/blob/main/data/presets/amenity/monastery.json
osm.wiki/Tag:amenity%3Dmonastery
osm.wiki/Proposal:Monastery
https://lists.openstreetmap.org/pipermail/tagging/2022-June/thread.html#64968
https://community.openstreetmap.org/search?q=monastery
Very little in that JSON file can be traced to either the Wiki or various discussion channels. There are, however, plenty of specific secondary tags mentioned on the wiki that do not turn up there. Very few of the terms listed in the JSON file can be found anywhere on the wiki or past discussions while plenty of dedicated terms for specific types of monasteries exist (and some are mentioned on the wiki) that are not listed. The symbol referenced was - from what i know - never discussed on community channels.
And this example is not an outlier, many of the files i casually looked at in the repository seem to have a rather dubious provenance of the content they contain.
Needless to say that wiki and tagging discussion channels are not generally a very reliable source of information regarding the tagging consensus among mappers.
Bottom line for me: I feel very much confirmed in my impression that the main bottleneck of the iD tagging schema is non-technical editorial work.
Comment from mnalis ALTernative on 8 June 2026 at 08:22
@imagico those are two different things…
One, which you seems to care about, is COLLECTING IDEAS about extra search terms, icons, better translations, extra tags etc. Those are certainly important!
They can currently be contributed via writing in freeform plain English by creating GitHub issue at https://github.com/openstreetmap/id-tagging-schema/issues
While creating GitHub account may present some difficulty (and speaking English even bigger one), it is what is already currently available.
If you think that is the high bar, suggestions on alternative (including manpower to manage them) would be welcome.
What @Mateusz is talking about is manpower needed to convert those already existing (in form of GitHub issues) ideas into JSON format usable by id-tagging-schema so users can actually use them (i.e. creating GutHub PRs from GitHub issues).
And it is bottleneck, because more issues get created each month then the pull requests that resolve them. Which means: good ideas are not being implemented, which is a loss.
TL;DR: In other words, creating more ideas without more manpower to implement them is only going to create more frustration from users who get ignored for longer and longer periods of time, and not help at all.
So, yes – both are needed; but the issues without the PRs are useless. Thus, the idea of this particular diary entry seems to be to engage users who are capable to help with PRs.
There are infinitely more problems related to tags in OSM (from discussions, cultural differences, decision making, implementing data consumer support for them, project “kings”, etc. to the fact that we have at least 3 competing machine-readable “standards”: id-tagging-schema /JOSM presets /Vespucci presets, so improvementa in one is wasted effort on others).
But each of them is worthy its own diary entry (and much more) - there is no need that they all be comments on this particular one which tries to make actionable improvement on a small piece of the whole puzzle.
Comment from imagico on 8 June 2026 at 11:18
Emphatically no!
I get the appeal of delineating the inner world of a project that is essentially self sufficient intellectually and where everything can be dealt with based on the competency set of the peer group and everything else is the outside world out of scope of the project itself and is only considered at the discretion of the insiders.
But this is not a sustainable approach for this kind of work.
Frankly - if you don’t realize from looking at my monastery example that there is a substantial editorial deficit in the project that is not going to be solved by more idea collection outside of it i am at a loss here.
The problem you have is that the vast majority of people who have the background to contribute on a non-technical level, who are knowlegeable in tagging practice, global geography etc. are not going to be motivated to contribute their skills by petitioning to technical gatekeepers. And to be fair: You are not alone with this problem, there are plenty of other technical projects that suffer from the same issue.
And the mirror side to that problem is that many non-technical community members experience a lack of self-efficacy in the community and quite a few of them act this out by trying to push their views on the wiki or becoming aggressive/derailing in communication. Which is counterproductive, of course, since it re-affirms the tech projects to self-isolate.
That is exactly what did not make sense to me from the start. If - as you say - the only competency required to fill the bottleneck is technical in nature then the solution is to create the technical means to allow those having the good ideas to actually implement them without the need for a human technician to hand chisel them into JSON.
But if the work on which you have capacity issues is actually editorial work rather than technical work of dumbly chiseling the JSON and formally testing it then the attempt to solve this by adding purely technical work power is going to be completely counterproductive, because - if you are successful - you are mainly going to increase the accumulated editorial deficits.
I have had this discussion plenty of times. Diversity in tools and independent approaches to address a need is an asset for the community, not a waste of ressources. In practically all fields of work, technical or other, the OSM community does not have a manpower problem, it has a deficit in creating suitable and appealing conditions for people to contribute, learn and grow. We don’t need less tagging present projects, we need more - not more of the same but more diverse approaches in the way this matter is practically worked on.
In non-technical work different people working on the same thing from different perspectives is almost universally considered a good thing. Five different books being available on the same subject is something most people consider a good thing. Five different painters painting the same thing most consider a cultural enrichment. Considering such things wasteful usually stems from looking at matters as a zero sum game where one party’s gain is inherently another party’s loss. Don’t make the mistake of buying into that glass half empty world view.
If you want a concrete recommendation how to stand out from the other tagging schema projects it is as follows:
But i am realistic and do not expect these ideas to change things here in substance - the economic interests in favour of the status quo are strong and i don’t have the capacity to fight them. The mains reason why i am commenting is to attempt to widen the perspective of people reading here - and my own.
Comment from Mateusz Konieczny on 8 June 2026 at 12:21
it applies to narrow, but existing slice of ideas
it is not the only and sole bottleneck
Comment from Mateusz Konieczny on 8 June 2026 at 13:12
oh, that is my second recent attempt to achieve this
previous attempt more or less failed with reaction that I would summarize as “make this decisions yourself rather than bothering us”
links to this attempt (feel free to judge yourself whether this summary is accurate): https://community.openstreetmap.org/t/new-presets-entries-proposed-to-be-added-to-id-tagging-schema-list-feedback-request/142303 and https://community.openstreetmap.org/t/likely-upcoming-tags-in-id-review-welcome-food-old-name-piercing-indoor-seating-yes-no/142495
I have plans how to retry in way that would be more likely to work.
In meanwhile this is an attempt to involve some new people. Yes, some minimal tech competence is required here but it is vastly lower than many people expect. So I hope that maybe someone will appear and give feedback also on other proposed changes.
I plan to try in future to get more people involved if I will see a good opportunity. Hopefully in wider way involving also lower technical competence to be required.
Note: as entire point of this small project is machine-readable information for editing software, at least on some aspects decisions must be taken by people understanding how to keep things working.
It would be a problem to have a new release cannot be parsed by editing software and breaks iD.
And to resolve technical limitations requires technical work than in some aspects cannot be judged without some expert knowledge.
Comment from Mateusz Konieczny on 8 June 2026 at 13:19
there is some technical skill required to form this good ideas into machine-readable form and they will stay no matter whether product is in XML, Markdown, JSON, hex-encoded binary or other method
if work is of any noticeable complexity and it must be machine readable then making it is inherently a technical skill
more specifically it is impossible to entirely remove technical skill required, as being able to make something machine-readable and working as intended and being able to test and confirm it and fix found issues is a technical skill
it may be possible to lower annoyance (that is part of reason why iD tagging schema is using JSON rather than XML) but it is impossible to remove it entirely
to preempt possible suggestion: no, LLMs are not solving it. Having prose as input and LLM producing tagging schema based on that was not working as of April 2026. And I see no indicators of it being possible with any reliability now or any time soon.
Comment from Mateusz Konieczny on 8 June 2026 at 13:21
to preempt another possible suggestion: no, GUI tools are not solving it either
you just move config from JSON into diagram with many coloured boxes or other complex GUI. It would take a lot of effort to create and will lower threshold only a bit. Or testing work would remain.
Comment from Mateusz Konieczny on 8 June 2026 at 13:46
for icons at least I was doing petitioning, with some positive reactions
Comment from imagico on 8 June 2026 at 17:28
To avoid misunderstandings: I am not here to tell anyone how to manage their projects, i am just trying to offer an outside perspective that might be helpful and try to better understand the inside perspective of your project.
On a few points you mention: