Show and edit related subtags in the inspector (check_date, note/description, source, conditional, numeric, other)

[tordans]

This is a draft to experiment with a UI that will allow us to expose related tags next to their field.
I did not review the code in details, yet. This PR is meant to be used to see if this is a good idea in terms of UX, UI and in general.

Related issues

Directly

• Please support check_date:opening_hours and check_date:collection_times #8884
• Fields should indicate that related conditional tags are present #9679
• Introduce colonCombo field type ideditor/schema-builder#180 (comment)

Indirectly

• Ask for smoothness:check_date when adding/changing the smoothness value of a highway=* way #8548
• Warn users when editing a tag that has a source #9453
• Proposal to add field groups in presets (How to start iterating on more detailed OSM data) id-tagging-schema#1202

Screenshots

TODOs:

• The icons are placeholder; I did not look for good icons, yet
• The Box of related tags is not properly styled, yet

Tags for testing

check_date:surface=2026-03-12
highway=motorway
maxspeed:conditional=60 @ wet
note:surface=bar
source:maxspeed=test
source:width=w foo
surface=stone
width=10
width:source=w bar
panoramax=123
panoramax:3=345
panoramax:99=nonono
panoramax:2=234
maxspeed=100

source:tagname

• 

• 

tagname:1, tagname:2

• 

• 

check_date:tagname

• 

• 

tagname:conditional

• 

• 

Other related tags

• 

• 

  This is buggy still, but the idea is to expose the "cycleway:left:surface" tag; the code about this is very rough but the idea would be to allow to give visibility to the tags in those more complex schema like the parking:* schema.

The general idea is that we always use the label of the field to show the indicator-buttons. For preset types that handle multiple key, the indicator would search for related tags for all those keys and just list them all.

The buttons are only there, when there are tags, so their presence in itself is an indicator.

They render in tree preset-fields: text, check-date-text, textarea which I think will be enough for the cases we will likely see.

---

What I like about this is, that it will allow use to give more visibility to some related tags without the need to do a bigger update like openstreetmap/id-tagging-schema#1202

Possible simpler version: We could boil this down to something simpler first, which only shows indicator icons and not button in the label bar. The indicator icons could then have a tooltip that just informs users that there are related tags.

[mfuhrmann]

This looks really promising. Is there some kind of test instance where this change could be applied?

[tordans]

Is there some kind of test instance where this change could be applied?

Yes, it is at https://pr-12005--ideditor.netlify.app/#disable_features=boundaries&map=20.33/52.45677/13.44966&background=Bing&id=w1126644207

This road segment shows the UI for parking and cycleway tags, for example.

[mfuhrmann]

@tordans Where do I need to sign the contract? 😂 But seriously, this is a nice improvement.

[matkoniecz]

I did not review the code in details, yet.

Is it LLM-generated or obtained in some other way?

[tordans]

Is it LLM-generated or obtained in some other way?

@matkoniecz I tried to be very clear in my description that this PR is not yet about the code, but to discuss a UI and UX direction. This is further indicated by the draft state of this PR which is also a signal that the code is not ready for review, yet. – To answer your question: Yes it is. (As will be all my code in the future.) Before I submit the code for review I will have reviewed each line myself and tested the PR meticulously which I will document in the PR.

[tordans]

A thought about the UI:

Thinking about this further, I think the button position and style in this draft are not good enough. This section is about the tag itself (delete, info) and the related get kind of hidden. I also clicked delete by accident so it needs some kind of separation at the very least (which is hard to style).

Maybe moving the options down into a small (in text and style) line below the field will be better.

Fieldlabel       [D] [i]
[______]
Related fields: _Check date_, _Note_, _Conditions_, Subtags

Where _Note_ and so on is a link that will show the fields below.

A thought about the sub-fields:

I was hoping we can get away with just the three fields types (text, text+today, multiline text) that I used above. This will be enough for the subfield-groups Checkdate, Note, Source, and most likely Number-Subtags Also the condtional tags at the current state (because we render them as text if at all). However, for the related tags like bicycle:* eg bicycle:surface we would want the specific preset field the way we specify it in the schema…

So either we reduce this PR to just show the tags and link to the "Tags" section for editing.
Or the PR needs to be able to pick the right schema field based on an cleaned subtag-tag (eg. show the surface field for bicycle:surface).

Info-i:

Right now the sub-fields don't have the info-i and delete buttons, but they should have.

[1ec5]

If you haven’t already, check out what OpenHistoricalMap did with subfields in OpenHistoricalMap#187 and OpenHistoricalMap#217. It involved more DOM-building code than I would’ve liked, but users have taken to these features quite well over the past couple years. (JOSM users have been clamoring for these iD features, fancy that.) The key to making this design work is predictability: the EDTF subfield is activated by a ➕ button within the date field’s body, because it’s only available on date fields. (It’s based on the Multilingual Name subfields.) By contrast, the source subfield is activated by a @ button within the field’s header, because it’s available on every field.

I’m not sure that either design will scale to more than a couple possible subfields in a given field. Already I frequently mix up the ➕ and @ buttons before the EDTF validator catches me. Sided and lane-based fields potentially complicate the UI beyond intuitiveness. Basically I expect to end up with a visual representation of this eye-glazing table. Given the limitations of this approach, we could use it for a few basic attributes, then turn the focus to more specialized field designs like #387 and #974.

[matkoniecz]

Overall it is really great interface!

Could also cycleway:surface and footway:surface be made to fit in?

Do we want to support adding these associated tags? Probably no

tagname:1, tagname:2

Interface for those was really, really confusing

[1ec5]

tagname:1, tagname:2

Interface for those was really, really confusing

OpenHistoricalMap#223 implements this differently by leveraging the existing Add Field menu. As soon as you fill in the Source field, “Source 1” appears in the Add Field menu. If you select that and fill in Source 1, “Source 2” appears in the Add Field menu, and so on. The numbered Source fields are all sorted numerically next to each other. We avoided nesting them under the original field, so that it doesn’t look like one is more important than all the others. This design avoids cluttering the field’s mini toolbar with yet another control that the user has to distinguish. It also has the side benefit of subtly telling you there’s already a source when you go to add another one.

[matkoniecz]

How long this test/demonstration PR should be open?

[RudyTheDev]

Leaving some of my thoughts as per request coming from #12332.

I think it's a good proof-of-concept long-term proposal that could by default support all (or an easily-maintainable list of) sub-keyed fields without any knowledge about specifics. Personally, I am strongly in favour of showing more fields, especially for subkeys.

It has been my experience that mappers often omit or don't notice/fix subkeys (e.g. maxspeed:type as a quick example), so anything to display at least what's already tagged is an improvement in my book. It's also my experience that a big part of why mappers don't tag common "easy" subkeys (like the cycleway:surface case) is because iD does not have these and entering them in raw tag editor is a comparatively tedious process. Most of the time, I have to search for the actual syntax, as I can never remember whether it's surface:cycleway or cycleway:surface.

Overall, this feels very much like a long-term design and implementation feature. In general, I would not expect this to get implemented quickly, nor immediately support certain things in a general way that something like directionalCombo can already do. Then there are things like life-cycle prefixes, which need their own special handling. Or things like lane editor. Those aren't even generic tag features, but they haven't been implemented (yet).

In other words, I don't think it should limit or replace custom fields for specific tags like the #12332 or existing directionalCombo plus any other custom fields that might have dedicated custom presentation like some of the examples 1ec5 mentions. You know, perfect is the enemy of good and all that. In fact, I would see custom fields as improvements to those cases where the generic version cannot do something.

I also think this would work really well in addition to custom fields (without needing replace or be replaced by them) like the "bike lanes" example, as one could incorporate "additional fields/subkeys" toggles and display extra fields that aren't already shown by the custom field, but the whole left/right/both key update logic is preserved.

One concern of mine would be how this would support many of such OSM key peculiarities without the code just becoming a long list of hardcoded cases. Even in something as simple as the cycleway:surface I found multiple edge cases that I never even thought about. I imagine there are many things that would need to be considered for this. In other words, it seems that there is a significant distance going from "this works for these cases" to "this works for all cases nicely" and "this doesn't break for all these exceptions". It would certainly help others to see some sort of implementation plan and timeline.

In that vein, one thing I do not like is the direction of field_subtag_preset_config.js and parts of subtags.ts. As the core of the feature, these should be well-designed and seperate logic from data. I realize it's proof-of-concept and LLMed, but (barring any mention otherwise) this currently feels like taking the direction of creating a parallel field configuration scheme to tagging repo, but hard-coding it all in iD code. In my opinion, for a general solution like this, the goal should be the opposite - allow tagging maintainers and proposers to discuss and fully-utilize the subtag functionality in the best way for each key, while the iD provides the general functionality - like it is now for most of other fields. The code of those files should be addressed for long-term maintainability. Especially for iD forks that may not actually want (or have) such hard-coded fields.

As already mentioned, this also has extra complexity of what input field type to show for sub-keys, like the bicycle:surface needing surface field as base example - all of which again needs to have some sort of way to be specified generically. I think this is an important point because a user should never be presented with inconsistent inputs (i.e. surface works here, but not here).

I think the UI is heading roughly in the right direction by "nesting" subkeys visually. I do however think it needs to be more compact. Again, I realize it's proof-of-concept, so criticizing it feels unfair, but the UX is basically the strength of iD and half the purpose of this feature, so proposing a strong visual solution sounds like the main priority.

I really like the idea of additional icons for specific subkeys (I also agree they should be placed under the inputs, so they do not mix with the "action buttons" especially as those change as you edit). Ideally, the icons would also appear next to the fields they reveal, so the user learns what they mean, but I digress into specifics. Although, I again have to point out how this (currently) ends up hard-coding much of this instead of being available via tagging.

I also see mentioned above concerns of scale - like what if there is a subtag of a subtag of a subtag and such. I think it's worth considering, but I also think that for common usable fields such precision is likely an overkill and in many cases it's better solved by custom fields if truly needed. My only suggestion would be to provide some sort of visual indication that there are more subkeys, so the user is at least aware.

Anyway, in short, I think this is as a good core improvement direction and an essential feature for iD. I think it's great that it solves a large bulk of missing subtagging display. I think UX and a generic support of subkeys are the obvious strong parts of this, but my current early reservations are about hard-coding and maintainability.

If there's one broad observation I would mention, then it's that there is no clear "approved for implementation" status for this repo. It's a lot of work to build something like this, so as an outsider I would hope maintainers would indicate whether this would even ever get integrated.

Please be aware that I am approaching this feedback more as a picky user rather than a developer, so please read my criticism as constructive.