[Proposal/Discussion] An international cross-reference database for traffic sign identifiers

tes_maker · September 12, 2026, 9:34pm

International cross-reference database for traffic sign identifiers

Hello,

I am currently working on a project to build a cross-reference database between national traffic sign identifiers and international classifications, in particular the Vienna Convention on Road Signs and Signals.

The goal is not to replace the national identifiers currently used in OpenStreetMap, but rather to provide an additional cross-reference layer connecting identifiers from different national systems.

For example, several countries may use different identifiers for signs corresponding to the same Vienna Convention model:

VIENNA:A1a — Dangerous bends (left)

Germany    → DE:103-10
Belgium    → BE:A1a
Czechia    → CZ:I-1b
Denmark    → DK:A41.2
Estonia    → EE:142
...

The national identifiers would remain unchanged, while the database would provide an international reference linking them together.

Signs not covered by the Vienna Convention

The Vienna Convention obviously does not cover every traffic sign used worldwide.

I therefore also intend to use an OTHER classification for cases where several countries have signs with a common meaning or function, but where there is no appropriate Vienna Convention equivalent.

For example:

OTHER:D9 — Snowmobile path

Estonia    → EE:437
Finland    → FI:D8
Sweden     → SE:D9

The idea is not to force a sign into the Vienna Convention when there is no genuine correspondence.

Current structure

The current structure looks roughly like this:

VIENNA:A
└── VIENNA:A1a
    └── VIENNA:A1a-Aa-V1
        ├── AT → AT:2b
        ├── BE → BE:A1a
        ├── BG → BG:A2
        ├── CZ → CZ:I-1b
        ├── DE → DE:103-10
        └── DK → DK:A41.2

Each international reference can therefore have several variants, and each variant can be associated with the identifiers used in different countries.

Why?

Such a database could make it possible to answer questions such as:

Which national traffic signs correspond to the same international concept?
What is the French equivalent of a particular German traffic sign?
Which signs convey the same information in different countries?
How can software interpret traffic signs coming from different national systems?
How can we preserve national identifiers while still allowing international comparison?

This could potentially be useful for OSM editors, mapping tools, navigation software and mobility applications.

A potential use case for autonomous vehicles

Such a database could also be useful for traffic-sign perception and recognition systems, particularly in the context of autonomous vehicles.

A recognition system may identify a traffic sign visually, but its interpretation can depend on the country where the vehicle is operating. Two visually similar signs may have different national identifiers, while signs from different countries may convey essentially the same information.

A structured cross-reference database could therefore provide a link such as:

recognized sign
      ↓
national identifier
      ↓
international classification
      ↓
meaning / function

This could help a system interpret a recognized traffic sign according to the country in which it is operating, while still preserving national regulatory differences.

The goal is not to define autonomous driving rules, but rather to provide a structured interoperability layer between different traffic-sign systems.

What I am not proposing

I am not currently proposing to replace traffic_sign=* with this classification, nor to change the existing national identifiers used in OSM.

At this stage, I would mainly like to discuss whether such an international cross-reference layer would be useful to the community and whether the proposed structure makes sense.

I would particularly appreciate feedback on:

the structure of the classification;
the distinction between VIENNA-* and OTHER-*;
how mappings between multiple national systems should be represented;
how to handle cases where a correspondence is functional rather than strictly equivalent;
possible uses of such a database within the OpenStreetMap ecosystem and beyond.

The project is still under development, and I am very open to changing its structure based on community feedback.

Thank you in advance for your comments and suggestions!

Minh_Nguyen · September 12, 2026, 10:32pm

I appreciate the separation of concerns between codes versus meanings. The coexistence of these concepts has been a sticking point in previous discussions about traffic sign classification on this forum. Even though CORSS standardizes many common signs, the mundane visual differences between national standards likely matter to traffic sign recognition systems. They seem to matter to mappers too: many pages on our wiki feature large galleries of very similar signs, as if the diversity in styles is a point of pride.

What form would this database take? A GitHub repository full of JSON files? A proper database running on a server somewhere? Or should we explore modeling these signs in Wikidata, since Wikidata already has ready access to all the sign diagrams on Wikimedia Commons? There already seems to be extensive coverage of France and Luxembourg, as well as more limited coverage of the United States and a few other countries.

Since you’ve described this as an international resource, could additional namespaces represent commonalities between other multinational sign systems, such as the Central American Manual on Uniform Traffic Control Devices and the SADC Road Traffic Signs Manual? I could also see a similar approach being relevant to countries that rely on regional sign coding systems, particularly Australia, Canada, Mexico, and the United States. For example, each Canadian province has wide latitude to develop their own sign designs with independent codes, but many of the signs correspond across provincial lines.

How would the database handle correspondences that aren’t one-to-one across national lines? For example, one country might use only one sign for what another country uses two different signs in different situations (or arbitrarily). Or one country might assemble two physical signs for the same purpose that another country puts into a single combined sign.

9_tab · September 12, 2026, 11:04pm

Interesting.

The other day, I looked into the way local traffic signs are described on wiki.openstreetmap.org . If there is a description for a sign there, it can display that from the tag on the map or in the iD map editor. Ideally it would list equivalents. Presumably these equivalents are fairly easy to obtain. If the entire thing could be generated in an automated way, this would obviously be better.

A few points from there, mostly concerning mapping in OSM:

Access defaults for (OSM) highway values vary by country. For less frequent modes of transportation, these can be surprising.
The official name of a sign is defined per (official) language
Some signs change substantially in meaning (or at least for OSM tagging) if they have an additional sign. Sample: Tag:traffic_sign=DE:250,1020-30 - OpenStreetMap Wiki . In Germany, additional signs have standarized text and numbers, locally it’s just free text: sample
Tag values with square brackets will need some work to link to wiki-pages. Sample: DE:274.1[30] see here.

The general question when mapping is if one should map the sign separately, directly to (one or several) ways or indirectly with other tags (sample: maxspeed, access). Sometimes (access) signs are missing on one end of a street, so a safe choice can be to add signs separately.

Taginfo has the following project that includes signs for many countries and may have attempted something similar: Traffic_signs_EUR_OC | Projects | OpenStreetMap Taginfo

Other than that, the wiki is currently partially broken, so it’s unclear if it’s worthwhile doing it there. In any case, a way to see an annotation of the tag for a sign on the map is helpful.

Minh_Nguyen · September 13, 2026, 6:06am

In a couple months, an overhaul of CORSS will take effect in most of the countries that have signed onto the original convention. Every sign code will change, some more straightforwardly than others. For example, the old sign A, 1^a will become A-01.1. Old sign A, 3^b will be eliminated without replacement. For the countries that rejected the changes, I don’t know whether it would be better to slot them into the new system anyways or treat them as non–Vienna Convention countries.

tes_maker · September 13, 2026, 8:27am

Thank you for these remarkably insightful comments! You touched on several fundamental challenges that I’ve been addressing in the data model.

The ultimate goal of this project is to establish an international umbrella reference layer—a “supreme” cross-reference standard that links national traffic sign identifiers together based on shared semantics and function, even when local visual designs or legal frameworks differ.

Here is how I envision answering each of your points:

1. Database Format & Wikidata Integration

Primary Repository: The project is being developed as a GitHub repository containing structured JSON files. This ensures clear version control, community participation through Pull Requests, schema validation via CI/CD pipelines, and easy re-use by third-party software.
Wikidata Alignment: I see Wikidata as highly complementary. Rather than substituting a lightweight, domain-specific repository, each record in this database will optionally cross-link to its corresponding Wikidata QID (and by extension, Wikimedia Commons SVG files). This combines specialized sign logic with rich community-maintained media assets.

2. Namespaces for Regional & Sub-national Systems

Moving beyond a generic OTHER category is a great idea. Using explicit, standardized namespaces for major regional frameworks—such as MUTCD:*, SADC:*, or sub-national codes like CA-ON:* for Ontario—creates a much more robust architecture.

Vienna Convention (VIENNA:*) remains the primary international baseline where applicable.
Regional Standards (MUTCD:*, SADC:*) serve as fallback umbrella namespaces when signs are unique to specific regions.
OTHER:* is strictly reserved for global functional concepts that lack any formal international standard.

3. Multi-sign Assemblies, 1-to-N Mappings & Functional Correspondences

To support complex relationships (such as one country using a combined single sign vs. another stacking two physical signs), the schema relies on a positional assembly structure.

Instead of forcing a rigid 1-to-1 link, national implementations map directly to specific positional elements or sub-variants under the parent concept.

Here is an example snippet showing how a single international concept (Slippery Road due to Ice/Snow) links different national systems:

{
  "reference": "VIENNA-A34",
  "name": "Slippery Road - Ice or Snow",
  "description": "Warning of slippery road conditions specifically due to ice or snow.",
  "declinations": [
    {
      "code": "VIENNA-A34-Aa-V1-EA",
      "localizations": {
        "de": {
          "system": "StVO",
          "position": { "center": "DE-101-51" }
        },
        "at": {
          "system": "StVO",
          "position": { 
            "center": "AT-16",
            "bottom1": "AT-f" 
          }
        },
        "us": {
          "system": "MUTCD",
          "position": { "center": "US-W8-5a" },
          "mapping_type": "functional"
        }
      }
    }
  ]
}

How this resolves complex edge cases:

Composite vs. Single Signs: The position dictionary allows mapping either a standalone sign (center) or a physical assembly (center + bottom1 sub-plate).
Functional Equivalents: The optional mapping_type flag (e.g., exact vs functional) explicitly documents when two signs convey the same practical meaning despite visual or regulatory differences.
1-to-N Mapping: A country can map multiple distinct national codes to different sub-declinations under the same top-level international reference without breaking the semantic hierarchy.

tes_maker · September 13, 2026, 8:33am

Thanks for these very practical points regarding OSM integration.

Automated Equivalents & Tooling: Being able to automatically generate sign equivalents and descriptions for editors like iD or map renderings is one of the main goals of this structured JSON approach.
Taginfo (Traffic_signs_EUR_OC): Thanks for sharing this reference! I’ll check out their dataset to see how they structured their work and where we can align.
Parameterized Values & Assemblies: Handling parameterized values like DE:274.1[30] and supplementary plates (like DE:250,1020-30) is crucial. The position-based schema is designed to isolate the base sign while accommodating variable values and conditional sub-plates.
OSM Mapping Practice: This database is meant to act purely as a semantic translation layer. It won’t dictate whether mappers should tag physical sign nodes or directly apply implied access tags (maxspeed, access), but it will help software understand what a given sign tag implies in different national contexts.

tes_maker · September 13, 2026, 8:55am

Here is my GitHub repo.

tes_maker · September 13, 2026, 11:01am

Thanks for the heads up on the CORSS overhaul - this has some real implications for how we structure sign data, so I wanted to propose an update to the schema before the new codes land.

The core issue: the revised convention replaces the old letter-based codes (A,1a / A,1b, A7…) with a single decimal identifier per danger type (A-01.1, A-23.1…), and pushes what used to be encoded in the letter (shape, mirroring, sometimes color) down into free attributes each country can set independently (see e.g. Art. 35 §1 for color, and the explicit “symbol may be mirrored” wording for orientation). If we keep baking shape/orientation into a composite code, we’ll end up reconstructing exactly the kind of rigid 1:1 mapping the new convention is moving away from.

Proposed structure - keep the official Vienna reference as the stable pivot, and split everything else into independent declination attributes:

{
  "reference": "A-23.1",
  "legacyReferences": ["A7"],
  "name": "Level crossing with barrier(s)",
  "description": "Warns of a level crossing equipped with full or half barriers arranged in a staggered pattern on each side of the track. The symbol may be mirrored.",
  "declinations": [
    {
      "shape": "triangle",
      "background": "white",
      "border": "red",
      "mirrored": false,
      "legacyCode": "VIENNA-A7-Aa-V1",
      "localizations": {
        "fr": { "system": "IISR", "position": { "center": "FR-A7" } },
        "de": { "system": "StVO", "position": { "center": "DE-151" } }
      }
    },
    {
      "shape": "triangle",
      "background": "orange",
      "border": "red",
      "mirrored": false,
      "legacyCode": "VIENNA-A7-Aa-V2"
    },
    {
      "shape": "diamond",
      "background": "yellow",
      "border": "black",
      "mirrored": false,
      "legacyCode": "VIENNA-A7-Ab-V1"
    },
    {
      "shape": "triangle",
      "background": "white",
      "border": "red",
      "mirrored": false,
      "system": "MUTCD",
      "mappingType": "functional",
      "localizations": {
        "us": { "position": { "center": "US-W8-5a" } }
      }
    }
  ]
}

Key points:

reference is the new Vienna decimal ID and the only stable pivot - no composite string built from shape/orientation/variant.
legacyReferences / legacyCode preserve the mapping to the pre-overhaul letter codes, so nothing already matched gets lost.
shape, background, border, mirrored become independent, filterable attributes instead of being baked into an arbitrary letter (Aa/Ab). This also lets us represent multiple real-world background colors under one sign (e.g. white vs orange background, both with red border) without multiplying references.
mappingType: "functional" is kept as-is for non-signatory equivalence (MUTCD, etc.) where there’s no formal treaty link, just a practical match.

On your two open questions:

Signs eliminated without replacement (e.g. old A,3b): rather than forcing these under a nonexistent new reference, I’d keep them as standalone entries with reference: null and a status flag:

{ "legacyReferences": ["A3b"], "reference": null, "status": "eliminated", "note": "No successor sign in the revised convention." }

That keeps the historical record queryable without polluting the new numbering.

Countries that rejected the amendment: I don’t think it’s accurate to treat them as non-Vienna once the overhaul takes effect - they’re still Parties, just running the pre-overhaul text. I’d rather tag this at the country level than the sign level, e.g. adding conventionVersion: "1968" vs "2026-revised" inside each country’s localizations entry. That way a rejecting country’s legacyCode stays the authoritative match, while accepting countries move to reference, without having to fork the whole dataset per country.

Open to feedback, especially from anyone who’s already tracking other background color/border combinations beyond the three above.

Minh_Nguyen · September 13, 2026, 3:04pm

By the way, the MUTCD itself is a national standard (for the U.S.). There’s a lot of confusion online about it being some kind of international system, but in reality it merely influenced national designs in other countries and some international conventions that the U.S. isn’t a party to.

Just as the U.S. national MUTCD serves as the primary basis for Canada’s MUTCDC and the Central American MUTCD, the SADC-RTSM is adapted from South Africa’s standard, which in turn borrows heavily from the British TSRGD. While continental European signs heavily influenced the original Vienna Convention, that influence is more explicit in this year’s revisions, which eliminate some options that had been popular in other regions.

Regardless, even within some national systems, there’s a strong need for the same sort of correspondence that you’re building but at a subnational level. Sorry if my use of the term “regional” was unclear. For example, Michigan’s R3-8v functionally corresponds to Ohio’s R3-H8cp. The national MUTCD only provides a legal basis for these signs but otherwise doesn’t coordinate them specifically. If these signs happen to correspond to one of Québec’s signs, it would be no different than corresponding to one of Romania’s or Japan’s.

trial · September 14, 2026, 9:08am

Never heard that, for instance BE:C1 is for for the 3 official languages (but I may be wrong).

Of course, if you have text its in the part, or do we have “fixed texts” with several variants with hardcoded IDs? I know, Germans can write DE:274.1[30] or DE:274.1.30 (not this one, but speed limits can be “hard coded” in the ID). Anyway, see below a possible solution.

I can imagine that for “except bicycles” (sens unique limité in Belgium). For France it’s M9v2, , author: Roulex 45.

I believe the wikidata item is missing.

Here you have a pretty good summary of road signs Europe wide (31 countries).

The English pendant is more about colors.

Open to feedback, especially from anyone who’s already tracking other background color/border combinations beyond the three above.

With the wikidata item you can get the associated SVG. On the Vienna sign you get the generic , on each localization, you get localized version, .
By the way something like a jinja2 / variable SVG would make sense I guess to cope for instance with speed limit signals (here the speed).
When you have a pictogram, the main color can make sense.

Do you expect to have extensions. Let’s take
FR:Signalisation routière en France - OpenStreetMap Wiki as example.

A15a1
A15a2
A15b
A15b
This matches this part of the Vienna Convention:
15. Cattle or other animals crossing
(a) Warning of a section of road on which there is a particular danger of animals
crossing shall be given by a symbol representing the silhouette of the animal, domestic or wild,
most frequently encountered, such as symbol A, 15a for a domestic animal and symbol A, 15b for a
wild animal.
(b) The symbol may be reversed.
A15a1, A15a2: should we accept an array:

"fr": [{ "system": "IISR", "position": { "center": "FR-A15a1" } },
       { "system": "IISR", "position": { "center": "FR-A15a2" } },
      ]

For the last one (A15b ), I guess it will get a specific ID if the sign get permanent in the IISR, but we have similar cases with reversed symbols.
Do we want to track the (subtle) difference?
I would say yes, as Germans have different IDs for that:

DE-142-10
DE-142-20

Probably that’s the intention of "mirrored": false,, but then we have to duplicate the entry for the mirrored French sign, right?

For pictograms/symbol it may be useful as seen on Road signs in Germany - Wikipedia, to name them.

But if we keep baking shape/orientation into a composite code, we’ll end up reconstructing exactly the kind of rigid 1:1 mapping the new convention is moving away from.

9_tab · September 14, 2026, 2:18pm

Maybe Tag:traffic_sign=CH:2.01#Names makes it clear. The sign with that code has 3 (or 4) official (or local) names.

That’s different: Tag:traffic_sign=CH:2.59.5 - OpenStreetMap Wiki has different codes for “zone” or “zona”.

There are also the additional signs that can have “random” text varying by language. A selection on Tag:traffic_sign=CH:2.01#With additional signs

9_tab · September 14, 2026, 2:22pm

It would be nice if the mapping practice could easily be displayed together with the info from your database. Sample: On traffic_sign=CH:2.01 everything but the “Access” and debug sections could come from your database.

9_tab · September 14, 2026, 2:25pm

Please bear in mind that the texts on Tag:traffic_sign=CH:2.01 - OpenStreetMap Wiki don’t have codes. At least for one canton there is a database that should show every traffic sign found on the ground (and actual text values used). One could cross-check that with OSM.

trial · September 14, 2026, 2:57pm

No, we don’t care about how signs are “named” here, or not yet.
We could add this information in an namepart, for instance a dictionary with language as prefix.
A localized description could also make sense.

That’s different: Tag:traffic_sign=CH:2.59.5 - OpenStreetMap Wiki has different codes for “zone” or “zona”.
Then it’s not an issue here.

For the additional signs with “random” text, it’s the same as with the M9 in France. With the textual part , it works on OSM level. But for a subset, a common reference may make sense for instance for local traffic Anlieger frei/Sauf riverains.

9_tab · September 14, 2026, 3:18pm

Maybe the experts don’t, but most other mappers might only recall the name. Note we are discussing the database, not actual tagging of a each sign on nodes/ways, etc. The wiki page or a db-entry needs the names, but osm features don’t.

Square brackets are mostly for cases where the text is part of the sign, not a text on an additional sign.

tes_maker · September 14, 2026, 4:27pm

Based on your feedback, I’d like to propose an updated architecture for the JSON schema to cover these requirements cleanly:

Wikidata & Visual Assets: An optional wikidata field is supported at both the core and localization levels, allowing tools to fetch official SVG assets directly from Wikimedia.
Multilingual Descriptions & Names: Instead of flat strings, properties like name and description use localized dictionaries (e.g., {"de": "...", "fr": "..."}). This provides official multi-language documentation for wiki pages and editors without impacting physical OSM tagging.
Language-Specific Codes & Multi-variant Localizations (e.g., Switzerland/Belgium): To handle cases where a sign’s official code or reference varies by region/language, or where multiple national codes map to the same concept, national entries in localizations accept arrays with optional language and officialName attributes.
Dynamic Text & Supplementary Plates: Common semantic plates map to a shared semantic key, while free-text or localized supplementary plates use dynamic text dictionaries within assemblies.

Here is a draft snippet illustrating this updated architecture:

{
  "reference": "VIENNA:A-25",
  "legacyReferences": ["A7"],
  "wikidata": "Q1138851",
  "name": {
    "en": "Level crossing with gates or barriers ahead",
    "fr": "Passage à niveau muni de barrières",
    "de": "Beschrankter Bahnübergang",
    "it": "Passaggio a livello con barriere"
  },
  "description": {
    "en": "Warns of a level crossing equipped with full or half barriers.",
    "fr": "Avertit de la présence d'un passage à niveau muni de barrières ou de demi-barrières.",
    "de": "Kündigt einen Bahnübergang mit Schranken oder Halbschranken an."
  },
  "declinations": [
    {
      "shape": "triangle",
      "background": "white",
      "border": "red",
      "mirrored": false,
      "legacyReferences": ["VIENNA:A7-Aa-V1"],
      "wikidata": "Q1138851",
      "localizations": {
        "ch": [
          {
            "system": "OSR",
            "code": "CH-1.01",
            "position": {
              "center": {
                "code": "CH-1.01"
              },
              "bottom1": {
                "code": "CH-5.01",
                "text": {
                  "de": "Ausgenommen Linienbusse",
                  "fr": "Excepté bus de ligne",
                  "it": "Eccetto bus di linea",
                  "rm": "Ora bus da lingia"
                }
              }
            },
            "officialName": {
              "de": "Schrankenbewehrter Bahnübergang",
              "fr": "Passage à niveau avec barrières",
              "it": "Passaggio a livello con barriere",
              "rm": "Passagi da egl-fer cun barrieras"
            }
          }
        ],
        "fr": [
          {
            "system": "IISR",
            "code": "FR-A7",
            "position": {
              "center": {
                "code": "FR-A7"
              },
              "bottom1": {
                "code": "FR-M9v2",
                "text": {
                  "fr": "Sauf vélos"
                }
              }
            }
          }
        ],
        "de": [
          {
            "system": "StVO",
            "code": "DE-151",
            "position": {
              "center": {
                "code": "DE-151"
              }
            }
          }
        ],
        "us": [
          {
            "system": "MUTCD",
            "code": "US-W10-1",
            "mappingType": "functional",
            "position": {
              "center": {
                "code": "US-W10-1"
              }
            }
          }
        ]
      }
    }
  ]
}

What do you think of this structural approach? Don’t take the content into consideration, it is just to see the structure of the datas.

Minh_Nguyen · September 14, 2026, 4:53pm

Not to nitpick, but in the MUTCD, sign W10-1 warns about an upcoming at-grade railroad crossing (level crossing), regardless of any barrier. Is the idea is to fall back to the “next best thing” when a given jurisdiction lacks a sign for a specific concept that some other standard defines? If you add an entry for every such conceptual mismatch, it would quickly bloat the database. At that point it might be worth exploring a hierarchy of concepts, like how in Wikidata a welcome sign is a subclass of place name sign or a rural speed limit sign is a subclass of speed limit sign.

PanierAvide · September 14, 2026, 6:25pm

Hi, someone sent to me the link to the discussion, this is very interesting!

I’m working on the Panoramax project, we have made a very limited database for now for traffic signs (here) in order to display the automated detections from pictures of traffic signs on a map, with correct symbol.

I checked your repo, this is impressive work already! I’m wondering if you could set a precise license, in order to make sure this can be used in other projects. My repo was started with a CC0 for sign data, and each traffic sign symbol is linked to Wikimedia Commons, so it keeps it original license from there.

tes_maker · September 14, 2026, 7:19pm

Hi PanierAvide,

Thanks for stopping by! It’s great to see interest from the Panoramax team—automated detection visualization on street-level imagery is a perfect real-world use case for this database!

Regarding licensing: I have explicitly set the non-software content (database structure, compilations, country sets) under Creative Commons Attribution 4.0 International (CC BY 4.0).

This allows open projects like Panoramax to freely use, adapt, and build upon the data (even commercially), with simple attribution (Road sign data by Paul TESSON (tes_maker) - CC BY 4.0).

As you mentioned, vector sign assets themselves are referenced via Wikidata IDs (wikidata) and retain their original licenses directly on Wikimedia Commons.

The LICENSE file is now updated in the repo. I’d love to sync further on how this architecture can best serve Panoramax’s automated detection pipelines!

trial · September 14, 2026, 8:00pm

Maybe the experts

I was referrinq to the actual proposal.
Ironically your page refers to the ID, not to a name.
With a wikidata entry, we can get the name (label) and the description.
For French and English, both language being used for the Vienna Convention, it’s easy to add the “legal” wording.

Of course I know that FR:B0 and CH:2.01 have the same meaning (thanks to this post) and I don’t expect anybody to start with Category:Road signs of Switzerland and Liechtenstein by number - Wikimedia Commons when looking for a traffic sign in your country.

Square brackets are mostly for cases where the text is part of the sign, not a text on an additional sign.

Possibily in your country, but it doesn’t matter here. For speed signs, urban entries/exits, yes. BTW, those may may exist at one place in different languages, like EB10 in French and Breton language, but out of scope here.

For clarification, below, only 50 is the variable part, as you have a specific ID for each top text, isn’t it?

.

@tes_maker sounds better, for your example, you can add wikidata=Q3362360 for FR-A7. But as long as you’re dealing with structured information, wikidata or data items should be able to modelize that. But a specific solution like yours may be better.