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.