Tags editor

[deevroman]

Implements #3611

Description

first vesrion

2026-01-29.16.22.37-optimised.mp4

2026-01-30.04.02.25-optimised.mp4

The interface now replicates https://github.com/Zverik/osmtags-editor

This is still a draft (it's fully functional, but the code could use some polishing here and there), so I invite you to test it and share your impressions.

Do we need such an editor?

Yes. See the issue's likes and popularity in the osmtags-editor community.

Are we lowering the barrier to entry too much?

We'll likely only find out about this once this feature is rolled out. Currently, the button only appears for authorized users.

I see risks in making it easier to vandalize important objects (for example, those with Wikidata), which iD only allows editing in the tag editor.

Well, I think if the situation gets out of control, we can check the walkthrough_progress value that the iD sets in Local Storage, or check the user's registration date on the server. I think we can find the optimal limitation.

After all, we don't know how many users click Edit on the object page. The new button is less noticeable and is located at the bottom of the page.

Maybe make it in the form of a table?

Possibly, at least there won't be any unexpected = symbols for newbies. But I don't think this is a blocker to implementing the editor.

created_by=?

I'm waiting for your suggestions. Now I have put "Tags editor on osm.org"

What's wrong with iD?

He's slow and has a slow workflow for simple fixes. It's also terrible for mobile devices.

Tests?

It seems that writing unit tests is problematic in the current repository, but it is probably possible to write E2E tests.

[1ec5]

This is indeed something many mappers have asked for. Hopefully we can strike a good balance between convenience for experienced mappers and intuitiveness and safety for less experienced mappers.

[1ec5]

The big question: should this be a simple text area or something more structured? If it’s a simple text area that depends on a format of some sort, we need to provide hard-to-miss access to documentation about the format. It isn’t quite Level0L, it’s the multiline key-value syntax that iD exposes in its text view.

Most of the mappers you know already know the syntax by heart or will it figure on their own, but this PR would put “Edit Tags” in front of a broader user base, including users who’ve never edited the map before. Maybe this text area could be a steppingstone to something more structured like iD’s default raw tags view, a table of editable fields. After all, unlike Level0 (#2391), this inline text editor doesn’t really need to serve a mail-merge-like use case where you copy-paste the result of some text processing on the command line.

[deevroman]

A text field definitely has advantages over something like a table (it's not for nothing that iD has two editing modes)

We might need something like a Help button with a tooltip

[1ec5]

it's not for nothing that iD has two editing modes

Right, the main motivation was to enable mappers to copy-paste tags between elements: openstreetmap/iD#6302. A JOSM-like UI for that would’ve been inconvenient because the sidebar doesn’t have a custom context menu. As a side benefit, the single text area makes it easier to copy-paste tag combinations from the wiki or nsi.guide.

I wouldn’t say the single text area is a showstopper, but it would be pretty explicitly an advanced thing that we wouldn’t want newer users to think of as the main tool for editing tags. It’s essentially a code editor (which I guess implies a future enhancement for syntax highlighting).

[deevroman]

Maybe the motivation was really like that, but in my practice there are still a few advantages:

1. A wider field. There are no additional buttons, and the keys column does not take up a fixed width
2. Works arrow navigation on the keyboard

future enhancement for syntax highlighting

well, so far there is no CodeMirror even in the iD :)

[1ec5]

A wider field. There are no additional buttons, and the keys column does not take up a fixed width

Yeah, the sidebar width can be constraining since it isn’t resizable: #1254.

Works arrow navigation on the keyboard

Personally I am worried that, the third time I use this feature, I’m going to press the adjacent ↑ and ⇧ buttons on my laptop keyboard and eject a tag by accident. But I probably should be more worried about what’ll happen when I use this editor on my phone, since you mentioned that as a motivating factor. MediaWiki presents mobile users with an extra mandatory preview due to all the possible accidents that can occur, like accidentally tapping on the Save button while trying to select text. Maybe that confirmation screen isn’t such a bad idea after all.

[deevroman]

Yeah, the sidebar width can be constraining since it isn’t resizable

In fact, it's high time we increased the width of the sidebar. And you can make it dynamic with a single line in CSS. But this is a separate discussion.

[tomhughes]

The big question: should this be a simple text area or something more structured? If it’s a simple text area that depends on a format of some sort, we need to provide hard-to-miss access to documentation about the format. It isn’t quite Level0L, it’s the multiline key-value syntax that iD exposes in its text view.

Even if we do offer a simple text area (and I suspect we shouldn't) then it definitely shouldn't be the default.

[1ec5]

From my perspective as an iD developer, I’d expect some volume of well-meaning but misguided contributions from people who don’t speak English or OSM English, as well as even messier contributions from SEOs. Think whole sentences as keys, that sort of thing.

If we’re concerned about this possibility, we could make inline editing an option alongside the Preferred Editor preference. It would still be more discoverable than the current browser extension, but just high enough of a hurdle that we’d have a better idea of who’s using the feature initially.

[deevroman]

Think whole sentences as keys, that sort of thing.

If we look at keys specifically, we can implement strict validation and prohibit spaces in keys. Or even prohibit adding anything but 0-9a-zA-Z:_ to a new keys.

[deevroman]

Moreover, it is not difficult to implement autocomplete and validation based on Taginfo, but we can think about this later.

[tomhughes]

Well, I think if the situation gets out of control, we can check the walkthrough_progress value that the iD sets in Local Storage, or check the user's registration date on the server. I think we can find the optimal limitation.

I'm not sure what that would have to do with anything? I don't think we can condition features on the main web site on user's having used iD.

[deevroman]

I don't think we can condition features on the main web site on user's having used iD.

It could be logic like this: we show the button, either if the user is more than a week old, or they were trained in iD. Yes, there is an undesirable connection between components, and I hope we don't need it. But as an option, if it turns out to be something like MAPS.ME 2.0, we can think about it.

[deevroman]

Okay, I threw it away automatic comment generation. Now everything is much simpler:

2026-01-30.04.02.25-optimised.mp4

Also added key validation for allowed characters and error translations
p.s. I won't forget to squash commits

[HolgerJeromin]

It could be logic like this: we show the button, either if the user is more than a week old

I would go for: needs contribution of more than x edits.

[pablobm]

I agree with @tomhughes (#6758 (comment)) that this should be moved to Rails views as much as possible. The code that puts together the content using jQuery can be implemented with a template. Not sure about Turbo purely because I don't know what the current situation is and how complex it would be to use for sidebar content (is there any prior art?), but at the very least integrated with the current JS router (see for example how the sidebar is loaded for map elements).

There's also the validation, which here is happening fully on the client side. Ideally this should happen in the backend... but from what I'm seeing there's no validation applied to tags anywhere at the moment? So I don't know what the expectations are here.

[simonpoole]

• How does this handle tag changes with geometry impact/ties?
• How does it handle relation memberships (changing a tag might make the element in question an invalid member)?

More general observation: it has never been as easy to edit OSM as right now, however that development has not had any noticeable impact on sign-ups, editor activity and retention. There is no reason to believe that adding this facility will have any other effect that to cannibalise edits from existing tools with (currently, see below) better safeguards and user support.

And while I realise that everybody reading this already knows it: in the long run you are essentially adding yet another fully fledged editor with all the work and issues that implies. I'm sure that everybody has the good intention of limiting the scope, but irl that just isn't a thing.

[simonpoole]

There's also the validation, which here is happening fully on the client side. Ideally this should happen in the backend... but from what I'm seeing there's no validation applied to tags anywhere at the moment? So I don't know what the expectations are here.

Maybe https://youtu.be/3wg0P32QhO4?si=tUww0jdExqbWsk6Y is of interest.

[pablobm]

Thank you @simonpoole, that was illuminating.

So any editor, including this one, is responsible for validation. The API won't do it as it can't be an arbiter of the evolving conventions and schemas in the community. This leads to complications even in cases like this one, as certain tags can have complex effects.

Now, as for this PR, I see the following:

1. Explicit validation of the format of any new keys introduced in the object.
   • Is this established enough a convention that could be implemented in the backend?
   • In particular I wonder if any local communities maintain tags whose keys have non-latin characters. I'm no expert in any of the many tools that could answer this, so no idea.
2. A check that the submission has any changes at all.
   • Makes sense to keep in the frontend.
3. A lack of validation for unique keys.
   • Currently this code parses tags in order, stuffing them in a Map as they come. This means that the last tag will win in case of duplication.
   • Makes sense to implement in the frontend.

[1ec5]

In particular I wonder if any local communities maintain tags whose keys have non-latin characters. I'm no expert in any of the many tools that could answer this, so no idea.

I’m unaware of any tagging convention that explicitly calls for non-Latin characters in keys, but some tagging schemes technically allow relatively freeform names as subkeys, such as payment:*=* and ref:*=*. This report shows that non-ASCII keys are relatively rare, the most common being agglomération=* (8,814 occurrences) and railway:position:exact:京通 (120).

Formalizing a character set requirement would make the API more opinionated about tagging schemes than it usually is. Mappers using QA tools have historically been responsible for cleaning up exotic characters in keys. It’s quite easy to introduce them intentionally using other mainstream editors. The only difference here is that the text box is so accessible that a cat on the keyboard could plausibly mess up a feature directly on the homepage.

[tomhughes]

At the end of the day even iD and JOSM will let you enter any tags you want - they will try and guide you to certain ways of tagging but they won't stop you entering raw values.

Other editors are probably do even less in the way of validation.

So you certainly could try and extend this to do some validation, but it would probably make this PR at least ten times bigger at a guess, and we'd basically be getting into the job of writing and maintaining a partial editor as part of the site which we've avoided until now.

[simonpoole]

At the end of the day even iD and JOSM will let you enter any tags you want - they will try and guide you to certain ways of tagging but they won't stop you entering raw values.

Other editors are probably do even less in the way of validation.

Both iD and JOSM do present warnings for problematic things, and more general nearly all editors employ a combination of not allowing an operation in the first place and after the fact validation that will display a warning in some form.

So you certainly could try and extend this to do some validation, but it would probably make this PR at least ten times bigger at a guess, and we'd basically be getting into the job of writing and maintaining a partial editor as part of the site which we've avoided until now.

Just wait for the first requests for adding a "simple button to reverse a way" and "I need to change this maxspeed tag, but just for part of the way, you already have a list of all the nodes displayed so you just need to add a button to split there" :-).