Route relation labeling (again) by tyrasd · Pull Request #11052 · openstreetmap/iD

tyrasd · 2025-05-15T19:50:49Z

A slightly different approach for #8759 (and a bit beyond) to fix the issue with overly long NSI preset names for PT route relations. Supersedes #10583¹.

Uses the regular non-NSI base preset for the labeling in the relation membership (and relation members) editors
Shows the icon of the NSI preset next to the base preset name
Shows the route's ref tag in a (colored²) "shield"

Some before/after examples:

-

Different to the approach in Fix: Remove Disambiguators from Relation Names in Membership Editor. Fixes #8759 #10583, this is not relying on implicit assumptions about NSI's naming scheme and does not interfere with (translated) names of regular presets. ↩
If applicable, see also show (route) relation colours in lists and comboboxes #9424 ↩

fixes #8759, closes #10583

in case entries with long names (e.g. public transport route relations that have a NSI entry) can still be disambiguated from each other

…esults

1ec5 · 2025-05-15T20:23:08Z

+                const hasColor = d.entity.tags.colour && isColourValid(d.entity.tags.colour);
+                const hasRef = d.entity.tags.ref;
+                if (hasColor || hasRef) {
+                    const color = isColourValid(d.entity.tags.colour) ? d.entity.tags.colour : '#555';


Many recreational routes are associated with multiple colors, which could be tagged as a semicolon-delimited list in colour=* (regardless of any osmc:symbol=*).

Yeah, I was pondering about osmc:symbol for hiking routes (but only for a future iteration on top of this feature). Multi-value colour tags seem to exist (example), but are not very frequent outside of the Netherlands:

!

1ec5 · 2025-05-15T20:34:06Z


+            label.each(function(d) {
+                if (d.entity?.type !== 'relation') return;
+                const hasColor = d.entity.tags.colour && isColourValid(d.entity.tags.colour);


Recently on the forum we were discussing alternative keys that often associate routes with colors. colour=* is usually appropriate when a route is associated with a color. However, ref:colour=* is used in some places, particularly Spain, where they don’t attempt to uniquely color-code the routes in a network, but the color is still very important for recognizability. If iD uses the color as a background color for something that looks like a route marker, then this would be a good opportunity to use this key. Unfortunately, id-tagging-schema doesn’t have a ref:colour=* field yet. It’s a touchy subject, because people who don’t understand the Spanish system or others like it tend to rush to judgment about how they’re doing it wrong.

It’s a touchy subject, because people who don’t understand the Spanish system or others like it tend to rush to judgment about how they’re doing it wrong.

I have not rushed to yell "you are doing it wrong way" but I definitely had such thought. Is there write-up somewhere which explains why ref:colour rather than colour makes sense?

(if it makes sense it would make sense to support it, including iD presets)

The ref:colour=* documentation alludes to the situation. It’s primarily important in Spain, where colors on route shields apparently have political overtones. I’ve had someone explain the considerations there to me before, but it goes over my head. From my perspective as an OSM Americana developer, some of the distinctions seem like they could be represented by more specific network=* values instead, but other route colors seem to have no rhyme or reason to them, which would justify the presentational keys. Might be worth asking on the forum for a fuller explanation.

I am mostly confused why not use regular colour - I ma not asking why it gets tagged but why use different key than normal?

This highway route is colour=red because it’s known as the Red Route; one would identify it by color alone. This subway route is tagged (more or less) colour=green because it’s known as the Green Line and the branding is green through and through.

By contrast, AP-1 has (more or less) ref:colour=blue because the route markers are blue. That’s the only aspect of the route that’s blue. Normally we don’t tag this kind of detail, because all the routes in a given network share the same route marker style, but Spanish routes are more idiosyncratic.

and also render multiple ref shields in search results (if applicable) and drop some now unused imports

matkoniecz · 2026-02-24T23:07:57Z

+    margin-bottom: -4.5px;
+}
+.section-raw-membership-editor .member-row span.member-entity-ref-color,
+.section-raw-member-editor .member-row span.member-entity-ref-color,


section-raw-member-editor?

where it has effects?

The member editor is what appears at the bottom of the inspector when a relation is selected. The membership editor is what appears at the bottom of the inspector when a relation’s member is selected.

so raw-membership-editor is for membership editor?

There is no special raw membership editor?

Not sure what you’re asking, but the member and membership editors appear in the same location in the UI, in mutually exclusive situations. It does make sense to style them both consistently, as ref=* and network=* can both appear on relations and relation members, depending on the feature type.

but the member and membership editors appear in the same location in the UI, in mutually exclusive situations

it does not seem mutually exclusive?

what about relations that are having members (so member editor is appearing) and are also part of other relations (route master one for example) so membership editor is appearing.

In fact membership editor will appears always, I think to enable adding relation into another relation as member.

(I am not nitpicking for sake of nitpicking, I am trying to confirm that I understood what you wanted to express)

what about relations that are having members (so member editor is appearing) and are also part of other relations (route master one for example) so membership editor is appearing.

Yes, you would see both in that case.

matkoniecz · 2026-02-26T14:53:53Z

I asked on https://t.me/OSMes/175014 for feedback

Not sure is it necessary to supporti ref:colour_bg somehow.

Robot8A · 2026-02-26T21:41:21Z

It's something the Spanish community came with for road shields, but I see how it could be used beyond it too.

For example in Zaragoza, Spain, each public transport line has a specific visual representation:
https://detalier.com/portfolio/red-de-autobuses-de-zaragoza/ (this is the website of the designer studio who did the visual representation, as the official website of the bus company is inaccesible from a non-Spanish IP, but it can be seen there too)

Day lines are shown with a given background colour, with white text on stops. Night lines instead are dark blue background and a given text colour.

The question is whether that is interesting to show in iD or not.

And also probably how if we have so much complexity with osmc:symbol, why couldn't we have it as well for ref colour.

tyrasd · 2026-03-03T10:22:01Z

Not sure is it necessary to supporti ref:colour_bg somehow.

I would say not, because ref:colour_bg seems to be intended for the background colour of the road sign, which we don't care about here.

hlfan · 2026-03-03T16:07:36Z

fix the issue with overly long NSI preset names for PT route relations

⚖️

matkoniecz · 2026-03-03T16:30:15Z

it is kind of fitting for trains to have train-shaped icons...

well, I guess that solution would be to have limit on how long icon is allowed to be? Have you created already an issue for that?

1ec5 · 2026-03-03T18:09:54Z

Long wordmark icons are precisely why name-suggestion-index has historically preferred Twitter and Facebook icons (which have to be square) over Wikimedia Commons logos. Does ÖBB NightJet have a small logo or icon (P8972) that could be added to this Wikidata item? I believe NSI already prefers small logos over full logos.

tordans · 2026-03-03T18:18:53Z

Site note: we are putting too much stuff onto this one line...

Robot8A · 2026-03-05T00:04:20Z

Long wordmark icons are precisely why name-suggestion-index has historically preferred Twitter and Facebook icons (which have to be square) over Wikimedia Commons logos. Does ÖBB NightJet have a small logo or icon (P8972) that could be added to this Wikidata item? I believe NSI already prefers small logos over full logos.

Probably a version with just the letters NJ, which are used when abbreviating the train service (see https://iechub.rfi.it/ArriviPartenze/ArrivalsDepartures/Monitor?Arrivals=False&Search=tarvisio&PlaceId=3443 during night time as an example)

Edit: I wrote my message without realizing @hlfan actually already solved this https://www.wikidata.org/w/index.php?title=Q28127371&diff=prev&oldid=2469124147

tyrasd added 3 commits May 15, 2025 18:08

don't use NSI preset names for labels in raw member(ship) editor

a92a6d1

fixes #8759, closes #10583

show full entity name as hover-text in search results

9f1cb53

in case entries with long names (e.g. public transport route relations that have a NSI entry) can still be disambiguated from each other

show (route) ref in a (colored) shield in relation editors + search r…

1384445

…esults

tyrasd added the usability An issue with ease-of-use or design label May 15, 2025

1ec5 reviewed May 15, 2025

View reviewed changes

tyrasd added 6 commits May 20, 2025 20:05

update test specs with new function parameter

d44ab26

use ref:colour for relation colouring if present

a8caf5b

render multiple "ref shields" for semicolon separated ref values

e7f7d98

only render ref shields on relations in raw member editor

ddeecb9

and also render multiple ref shields in search results (if applicable) and drop some now unused imports

Merge branch 'develop' into route-relation-labels

80d4721

fix copy/paste mistake

2d54811

k-yle linked an issue Jan 5, 2026 that may be closed by this pull request

Omit disambiguator from relation type in member/membership editor #8759

Closed

matkoniecz reviewed Feb 24, 2026

View reviewed changes

Comment thread modules/osm/tags.js

Merge branch 'develop' into route-relation-labels

bd50668

github-actions bot deployed to pr-preview-11052 March 3, 2026 10:27 View deployment

add to changelog

e8d2f7d

tyrasd merged commit d23f468 into develop Mar 3, 2026
4 checks passed

tyrasd deleted the route-relation-labels branch March 3, 2026 10:30

github-actions bot deployed to pr-preview-11052 March 3, 2026 10:32 View deployment

tyrasd mentioned this pull request Mar 3, 2026

Make colour marker dot more noticeable #11924

Closed

Robot8A mentioned this pull request Mar 12, 2026

Improve the editing of bus routes at bus stop #4565

Open

1ec5 mentioned this pull request Mar 26, 2026

Update welcome screen - Change logic of privacy starting setting #9331

Open

1ec5 mentioned this pull request Apr 16, 2026

Add properties for icons in different media contexts ideditor/schema-builder#288

Open

Conversation

tyrasd commented May 15, 2025

Footnotes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

matkoniecz commented Feb 26, 2026

Uh oh!

Robot8A commented Feb 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tyrasd commented Mar 3, 2026

Uh oh!

Uh oh!

hlfan commented Mar 3, 2026

Uh oh!

matkoniecz commented Mar 3, 2026

Uh oh!

1ec5 commented Mar 3, 2026

Uh oh!

tordans commented Mar 3, 2026

Uh oh!

Robot8A commented Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Robot8A commented Feb 26, 2026 •

edited

Loading

Robot8A commented Mar 5, 2026 •

edited

Loading