Reviewing DMRs

Draft

The text on this page is a working draft. Final wording is to be provided by the secretariat.

Every Data Maintenance Request arrives in the same place: the DMR list. Open a request to see the submitted values, the community vote, any suggested amendments, and the convenor's decision panel.

The list defaults to the Request status — the team's to-do list. Use the Status filter to look back at Approved, Rejected, Batched or Failed entries, and the Type filter to work through New, Edit or Delete requests as a group. The Code column shows the contributor's suggestion, not an assigned code.

Three controls are available on every DMR once you are signed in:

• Vote — 👍 Accept or 👎 Reject. A vote is advisory: it tells the chair how the team reads the request. You can change or withdraw your vote at any time before the decision is recorded.
• Suggest an amendment — propose specific field changes (a corrected name, a missing function digit, better coordinates) rather than rejecting outright. Amendments are themselves votable, so the team can converge on one corrected version.
• Comment — for anything that is not a field-level change: questions, evidence, references to national gazetteers or Rec 16 clauses.

Always state why. A bare 👎 gives the chair nothing to act on; a rejection that cites the clause of Recommendation 16 it breaches, or the existing entry it duplicates, resolves the request in one pass.

---

New UN/LOCODE requests

A request for a code that does not yet exist. It opens with the New entry badge, and the Requested change panel lists every field the contributor supplied.

Note the two things the panel deliberately does not assert: the code beside the country is the contributor's suggestion, and Status: — assigned on review is left for the maintenance team.

Check, in order:

1. Does it already exist? Search the directory for the location and for obvious name variants. Duplicate codes are the most common defect. Remember the one LOCODE per location rule — a place with several functions gets one code with several function digits, not several codes.
2. Is it a location at all? Codes are not assigned to subdivisions, to single-use or temporary locations, or to places that do not exist. A specific terminal or berth inside an existing location belongs in a child code, not a new LOCODE.
3. Country code — correct ISO 3166-1 alpha-2. XZ is reserved for international waters and international cooperation zones.
4. Name — the international gazetteer name in the Roman alphabet. Diacritics are permitted; only the standard abbreviations (Apt, I., Is., Pto, Pt, St) are allowed. A matching name without diacritics must be present as the ASCII fallback.
5. Subdivision — ISO 3166-2, the part after the hyphen only. For US-CA, record CA. Blank where not applicable.
6. Function classifier — the 8-character string. At least one function digit is required, and each digit claimed must actually be true of the location. 0 means "function not officially verified"; B (cross border) is deprecated and must not be used.
7. Coordinates — mandatory. Since the 2020 edition every new entry must carry coordinates in ISO 6709 style, e.g. 5114N 00001W. Check them: a coordinate that lands in the wrong country or in open ocean is the single easiest defect to spot and the most damaging to leave in.
8. Suggested code. The requester may propose a code element. Treat it as a suggestion only — it must have a mnemonic link to the location name and must not already be allocated in that country. The final code element is assigned by the secretariat, and reviewers must not invent one.
9. Status is left blank. Status is assigned by the maintenance team through the review process, never by the requester.

If everything checks out, vote 👍. If one field is wrong, prefer Suggest an amendment over a rejection — it keeps the request moving.

---

Amendments to existing UN/LOCODEs

A request to change an entry that is already published. The bar here is different: the code element itself does not change, and downstream users have been consuming the existing entry, so a change must be justified rather than merely preferred.

An amendment carries the Amendment badge and shows the assigned code it applies to. The code element is fixed — it is not editable on an amendment — so your review is entirely about the field values.

Check:

• What is actually changing? Name, function, subdivision and coordinates each carry a different change indicator. Confirm the request identifies the right kind of change.
• Name changes must reflect a real change of the official name (or correct a demonstrable error), evidenced against a national or international gazetteer — not a preference for one transliteration over another. Remember that the name without diacritics must be updated alongside the name.
• Function changes must reflect a real change in the facilities at the location. Adding a digit means the facility exists and is in use; removing one means it no longer is. If the change is only that the function was never verified, 0 may be the honest answer.
• Coordinate corrections are always welcome and are the least contentious amendment — verify the new value plots to the right place.
• Never change the code element to match a new name. A location that is renamed keeps its code. Mnemonic value is nice; stability is essential.
• Never reuse a code. Codes from deleted entries are not reissued.

---

Removal of UN/LOCODEs

The highest bar of the three. Removal breaks every downstream system still referencing the code, so it needs a positive reason, not merely the absence of a reason to keep it.

A removal carries the Removal badge and adds two highlighted rows the other types do not have: Replaced by — the successor code, where the location is superseded rather than gone — and Reason for removal. Those two rows are the substance of the review; the fields above them are the entry as it stands today. On a removal, Suggest a modification can only change the successor code.

Check:

• Why is it being removed? Valid reasons include: the location does not exist, it was created in error, it duplicates another entry, or it has no remaining transport function. "Not used much" is not a reason.
• Duplicates. Where the removal resolves a duplicate, confirm which of the two entries survives and that the surviving entry carries all the functions of both.
• Downstream impact. Consider whether the location is still referenced in live trade documents. Where in doubt, the safer outcome is to mark the entry rather than delete it.
• The deletion notice period. A removal is not immediate. An entry marked for removal remains visible in the published directory as a deletion notice for one calendar year before it is physically removed, so consumers have a release cycle to migrate. Verify the requester understands the entry will not vanish on approval.
• No reuse afterwards. Once removed, the code is retired permanently.