Road refs: derive ref_class at import; pick the primary ref from multi-number labels

art-bot commented

2026-08-01 19:12:55 +00:00

Collaborator

The road_shields layer filters out ref values longer than three characters that do
not start with A, S or E. That correctly excludes Poland's county references (5501W) and
incorrectly excludes Sweden's four-digit länsvägar, which are perfectly ordinary
numbered roads that should carry a shield.

Two ways to fix it:

A per-country rule in the existing match on ["get", "country"]. Cheap, and the shield
layer is already country-conditional, so it fits — but it encodes national numbering
conventions in the style.
A ref_class column derived at import (national / regional / local), which is the
better fix: the decision about what a number means belongs with the country's mapping,
next to the rest of its reasoning, and the style then just picks a sprite per class. It is
probably what a fourth country forces anyway.

Recommend the second. Background: AGENTS.md, "The MapLibre style".

Merged from #39 — multi-number road labels (Poland)

Road labels in Poland show multiple road numbers on one road (north of Warsaw: "E77;S7;62")
— the source field is a semicolon-separated list and we treat it as a single field. The fix,
consistent with the above: do the selection at import time, choosing the most important
road (assumed to be the first in the list) and storing it as the primary ref.

Both halves are the same decision: what a road number means is decided at import, next to
the country's mapping; the style just consumes the derived columns. Prefer general rules
over per-country predicates ("is this feature type Y", not "is this country X") — see the
comment below.

The `road_shields` layer filters out `ref` values longer than three characters that do not start with A, S or E. That correctly excludes Poland's county references (`5501W`) and **incorrectly excludes Sweden's four-digit länsvägar**, which are perfectly ordinary numbered roads that should carry a shield. Two ways to fix it: - A per-country rule in the existing `match` on `["get", "country"]`. Cheap, and the shield layer is already country-conditional, so it fits — but it encodes national numbering conventions in the style. - **A `ref_class` column derived at import** (national / regional / local), which is the better fix: the decision about what a number *means* belongs with the country's mapping, next to the rest of its reasoning, and the style then just picks a sprite per class. It is probably what a fourth country forces anyway. Recommend the second. Background: `AGENTS.md`, "The MapLibre style". ### Merged from #39 — multi-number road labels (Poland) Road labels in Poland show multiple road numbers on one road (north of Warsaw: "E77;S7;62") — the source field is a semicolon-separated list and we treat it as a single field. The fix, consistent with the above: do the selection **at import time**, choosing the most important road (assumed to be the first in the list) and storing it as the primary ref. Both halves are the same decision: what a road number *means* is decided at import, next to the country's mapping; the style just consumes the derived columns. Prefer general rules over per-country predicates ("is this feature type Y", not "is this country X") — see the comment below.

art commented

2026-08-01 20:45:15 +00:00

Owner

The decision belongs in the import layer/derived column. I would say that should be a general rule: avoid making decisions per country if possible. Rephrase the predicate from "is this country X" to "is this feature type Y".

art-bot was assigned by art

2026-08-01 20:45:36 +00:00

art changed title from ~~Road shields drop Sweden's four-digit länsvägar~~ to Road refs: derive ref_class at import; pick the primary ref from multi-number labels

2026-08-04 09:49:27 +00:00

art commented

2026-08-04 09:49:27 +00:00

Owner

Merged #39 into this issue: Poland's multi-number road labels ("E77;S7;62") are the same problem from the other side — road-number semantics decided at import. Both get worked as one PR. #39 is closed as merged.