Location Naming

Over the years working in IT, I have seen some naming standards for computers, sites, and countries. Most of the time we try to capture things like the organizational unit, system type, location, and other information. So how do we name a location? Let’s start with an example.

Say you’re naming a firewall in Frankfurt: fw-fra-01. That works fine — until the company opens a second site in Freiburg, and someone abbreviates it the same way. Now fra means two different cities depending on which site’s admin wrote the ticket, and nothing in the naming scheme catches it, because “fra” was never actually defined anywhere — it was just typed. The moment a location code has to survive more than one person making it up, it needs to come from an external, documented standard instead of whatever felt natural at the time. That’s what the rest of this post is actually about.

Naming Standards

There are a lot of standards, they were built for different purposes, and they don’t agree with each other. The same country can carry four different official codes depending on which standard you’re reading from — which is exactly the kind of thing that turns into a production bug the day someone assumes they’re interchangeable.

ISO 3166

Codes for the representation of names of countries and their subdivisions — the one most people have actually seen, because it shows up in URLs, phone system locales, and shipping forms.

ISO 3166-1 alpha-2: two letters, e.g. DE (Germany), AT (Austria), US (United States).
ISO 3166-1 alpha-3: three letters, e.g. DEU, AUT, USA — more readable, used where a 2-letter code is ambiguous.
ISO 3166-2: subdivision codes built on top of the country code, e.g. DE-NW (Nordrhein-Westfalen), DE-BY (Bayern), US-CA (California).

NUTS

European Union standard — Nomenclature of Territorial Units for Statistics — a strictly hierarchical breakdown used for EU statistics and regional funding, three levels deep:

NUTS 1: major socio-economic regions — for Germany, this is essentially the 16 Länder, e.g. DE1 (Baden-Württemberg), DEA (Nordrhein-Westfalen).
NUTS 2: sub-regions/Regierungsbezirke, e.g. DE11 (Stuttgart).
NUTS 3: districts/kreisfreie Städte, e.g. DE111 (Stadtkreis Stuttgart).

https://en.wikipedia.org/wiki/Nomenclature_of_Territorial_Units_for_Statistics

FIPS

The Federal Information Processing Standard for country codes (FIPS 10-4, “Countries, Dependencies, and Areas of Special Sovereignty”) is a US government standard that looks like ISO 3166-1 alpha-2 — two letters — but deliberately isn’t the same code set. The classic example: Germany is DE under ISO 3166, but GM under FIPS 10-4. Mix them up in a dataset that’s supposed to be ISO-only and you get silent, hard-to-spot data corruption rather than an obvious error.

NIST formally withdrew FIPS 10-4 in 2008 in favor of ISO 3166, but it lives on in a lot of legacy US government and GIS systems — which is exactly why it’s still worth knowing the difference exists.

United Nations – Code for Trade and Transport Locations (UN/LOCODE)

A 5-character code for ports, airports, and other trade/transport locations: the ISO 3166-1 alpha-2 country code plus a 3-letter location code, e.g. DEHAM (Hamburg, Germany), DEBER (Berlin), USNYC (New York). Unlike ISO 3166 or NUTS, this one names places within a country down to city level, not administrative subdivisions.

https://service.unece.org/trade/locode/de.htm

Three sites, side by side

Back to the firewall example from the intro — say the company has three sites: Hamburg, Dormagen (both Germany), and Sunnyvale, California. Here’s the code each standard would assign to each site’s country, subdivision, and city, side by side:

Standard	What it actually identifies	Hamburg, Germany	Dormagen, Germany	Sunnyvale, California, USA
ISO 3166-1	the country	`DE`	`DE`	`US`
ISO 3166-2	the country’s subdivision (state/Land)	`DE-HH` (Hamburg, a city-state)	`DE-NW` (Nordrhein-Westfalen)	`US-CA` (California)
NUTS	EU statistical region (country-specific numbering, EU/EFTA only)	`DE6` (NUTS 1)	`DEA` (NUTS 1)	doesn’t apply — Sunnyvale isn’t in an EU/EFTA country
FIPS 10-4	the country, under the old US government scheme	`GM` (not `DE`)	`GM` (not `DE`)	`US` (matches ISO here)
UN/LOCODE	the specific city/port	`DEHAM`	`DEDMG`	`USSNN`

Reading the table row by row, rather than city by city, is more useful than it sounds:

Country-level codes are shared, subdivision/city codes aren’t. Hamburg and Dormagen always agree on the country row (DE / GM) but diverge everywhere below it — which is exactly what a location code should do, and exactly what a plain “first three letters of the city name” scheme (like the Frankfurt/Freiburg example) can’t guarantee.
Hamburg is a special case: city and state are the same boundary. Because Hamburg is simultaneously a city and a full federal state, its ISO 3166-2 code and its NUTS 1 code describe the same area. That’s not true for Dormagen, which sits inside the much larger Nordrhein-Westfalen — its subdivision code covers a whole state, not just the town.
Sunnyvale is the one that breaks a NUTS-only scheme. The NUTS row for Sunnyvale is simply empty, because NUTS has no jurisdiction outside the EU/EFTA. A naming scheme built only around NUTS works perfectly right up until the company opens its first non-European site — which is usually exactly when someone notices the naming scheme was never actually general enough.

Region Names

Between “country” and “building” there’s a scale none of the standards above touch at all: the multi-country “region” that cloud providers use to group data centers. This is a naming problem the ISO/NUTS/FIPS/UN-LOCODE world never solved for anyone, so every provider invented its own scheme from scratch — and, predictably, none of them agree either.

AWS uses a <geography>-<direction>-<number> pattern with no city name at all: eu-west-1 (Ireland), eu-central-1 (Frankfurt), us-east-1 (Northern Virginia), ap-southeast-1 (Singapore). The number exists because AWS sometimes adds a second region in the same geography/direction (eu-west-2 is London, eu-west-3 is Paris) — so eu-west-1 isn’t “the west of Europe,” it’s “the first region AWS happened to build in the west of Europe.”
Azure names regions more like place names, but inconsistently — some carry a country (germanywestcentral, actually Frankfurt), some a compass direction plus continent (westeurope, actually Amsterdam; northeurope, actually Dublin), and some a compass direction plus country (eastus2, Virginia). There’s no single rule you can apply to guess a new region’s name from its location.
Google Cloud is the most systematic of the three: <continent>-<direction><number>, e.g. europe-west3 (Frankfurt), us-central1 (Iowa), asia-southeast1 (Singapore) — closer to AWS’s pattern than Azure’s, but still its own scheme, not shared with AWS.

None of the three map cleanly onto ISO 3166, NUTS, or UN/LOCODE — a region name tells you which provider’s naming convention you’re reading, not which country-code standard to cross-reference. If your own naming scheme needs to reference “which cloud region,” that reference has to be stored as its own field, because there’s no external standard to derive it from the way DE or DEHAM can be derived from a country or city.

Manufacturer Plant Codes

There’s a much smaller-scale version of the same problem inside every large manufacturer: naming its own sites for internal use — logistics, invoicing, supplier documentation, org charts. Mercedes-Benz/Daimler solves it with a three-digit internal plant number (“Werknummer”) assigned to each production and logistics location across the whole group, independent of country, region, or any external standard:

010 — Untertürkheim (powertrain)
040 — Berlin-Marienfelde
050 — Sindelfingen
054 — Rastatt
060 — Wörth
067 — Bremen

(Per publicly available supplier/logistics documentation — not an official published master list, and plant numbers do get reassigned or retired as the network changes.)

That’s actually the more interesting lesson: not every location-naming problem needs an ISO committee. When the set of locations you need to name is small, closed, and entirely under your own control — a car maker only has so many plants — a flat three-digit internal number is a perfectly reasonable answer, and it’s simpler than anything ISO 3166, NUTS, or UN/LOCODE offer for the same sites. The complexity of those standards exists because they have to stay stable and unambiguous across organizations that don’t talk to each other. A Werknummer only has to make sense inside Mercedes-Benz.

Building & Room Naming

All the standards above name locations at country or region scale. The same problem — give every location a unique, structured, human-orientable identifier — shows up one level down, inside a single building. It’s worth looking at how three real, unrelated organizations solved it, because they don’t agree with each other.

BMLVS (Austria) — a full alphanumeric identifier

The Austrian Ministry of Defence (BMLVS) publishes a guideline for room numbering across its entire property portfolio (“Leitfaden für die Systematik der Raumnummern und Raum-Identifikationsnummern im BMLVS”, Beilage 2 zur Richtlinie CAD Bauwesen 2015). It defines two related identifiers:

RaumID (Room-ID) — a fixed 20-character alphanumeric code: property code (LIEGEV-Code), object number, building section/staircase, floor, a room-attribute flag, a running number, and a room-subdivision marker. Every segment has a fixed length, and unused positions are padded with a placeholder character, so the code stays database-sortable and queryable even when a building doesn’t use every field.
RaumNr (Room Number) — a shortened, human-readable form for door signs and floor plans, e.g. ST1/O1/01 for the first room on the first floor in staircase 1, or ST1/O1/T01 for the stairwell on the same floor.

Design choices worth calling out: special-purpose spaces (corridors G, stairwells T, balconies A) get their own numbering sequence per floor instead of competing with regular rooms for numbers; rooms are numbered clockwise starting left of the main entrance, by rule, not by whoever draws the plan; historical wing names (e.g. “Josephinian Wing”) are explicitly barred from the identifier itself; and existing buildings keep their old room numbers rather than being renumbered, with the new RaumID generated and stored purely for the property database alongside the legacy number.

Erzbistum Paderborn (Germany) — the room stamp, tied to DIN 277

The Archdiocese of Paderborn’s drawing standard (“Raumstempel Erläuterungen”, Stand 30.10.2018) takes a different shape: a seven-line stamp printed directly on the floor plan next to each room, combining an identifier with DIN 277 area classification.

Raum-ID: floor abbreviation + running number, separated by a period — E.005 (ground floor, room 5), U1.001 (first basement, room 1). A further .1/.2 suffix marks a sub-room only reachable through another room rather than directly from a corridor or stairwell.
Floor area per DIN 277 (2016), split into Verkehrsfläche (VF, circulation area), Technikfläche (TF, technical/plant area), and Nutzungsfläche (NUF, usable area) — further divided into seven DIN 277 usage categories, from NUF 1 (living/dwelling) through NUF 2 (office work), NUF 3 (production, R&D), NUF 4 (storage, retail), NUF 5 (education), NUF 6 (medical/care) to NUF 7 (everything else).
Room designation per DIN 277.
User — distinguishing, e.g., “Büroraum Pfarrbüro” (parish office) from “Büroraum Pfarrer” (pastor’s office), two rooms of the same DIN 277 type with different occupants.
5–7. Room area, room perimeter, and clear ceiling height, each in metric units to two decimal places.

Like the BMLVS guideline, numbering runs clockwise per floor from the main entrance, and special room types (corridors FL, stairwells TH, elevator shafts AF, balconies BN, parking spaces STP, and more) get their own sequence. But there’s a genuine difference: corridors and stairwells here keep the same number all the way through the building — U.FL01 in the basement and 2.FL01 on the second floor are the same physical stairwell/corridor, just with the floor prefix changed — whereas in the BMLVS system, every floor restarts its own numbering independently. Two defensible answers to the same question: does a shared vertical space have one identity across the building, or a new one on every floor it touches?

Weimar Schießhaus — zones instead of floors

A renovation plan for the Schießhaus Weimar (WEHA GmbH, 2011) shows a third, much simpler approach, and it works because the building is a single one-off structure rather than part of a portfolio: rooms are grouped into functional zones — A (hall area), B (club/salon area), C (living/guest-room area), D (catering area) — each with its own sequential number (A1, A2, … B1, B2, …). Stairs get a T prefix (T01, T02), outdoor colonnades a K prefix (K01, K02). No floor encoding at all, because none is needed here — the identifier only has to carry as much structure as the building actually has.

What they have in common

Despite disagreeing on the details, all three share the same underlying moves: pull circulation and special-purpose spaces out into their own numbering namespace so they don’t collide with regular rooms; fix the numbering direction/order by rule rather than by convention; and size the identifier to the scale of the problem — a defence ministry with hundreds of properties needs a 20-character database key, a single historic hall needs a letter and a number. It’s the same underlying problem as ISO 3166 or UN/LOCODE — assign a stable, structured, unique name to a place — just solved at the scale of a doorframe instead of a country, three different times, three different ways.

Make a one-time donation

Make a monthly donation

Make a yearly donation