Data Attributes

Every UN/LOCODE entry carries the same set of attributes. What each attribute means, and which values are valid, is defined by Recommendation 16 — that is the authority, and this page does not restate it.

What this page covers is the layer the Recommendation does not describe: how those attributes are laid out and encoded in the published directory and in the files you download. Each row below links to the definition rather than repeating it.

The columns

The directory is presented in 11 columns. In the downloadable files (CSV, TXT, MS Access) the LOCODE column is split into two — country and location — so the files carry 12 fields per row.

#	Column	Encoding	Defined in
1	Change	Single character, blank if unchanged	Annex II — Change Indicator
2	LOCODE	CC + XXX; split into Country and Location in file formats	Annex II — UN/LOCODE code
3	Name	Roman alphabet, diacritics permitted	Annex II — Location Name
4	NameWoDiacritics	The same name with diacritics stripped	Annex II — Location Name used in international trade
5	SubDiv	1–3 alphanumeric characters	Annex II — Subdivision
6	Function	8-character positional string	Function Attribute
7	Status	2 letters	Status Attribute
8	Date	YYMM	Annex II — Last Updated Date
9	IATA	3 letters, populated only when it differs from the location code	Not covered by Recommendation 16
10	Coordinates	ddmmN dddmmE	Geographical Coordinates Attribute
11	Remarks	Free text, optionally tagged	Annex II — Remarks

Encoding conventions

These are presentation and file-format conventions. They are not part of the Recommendation, so they are recorded here.

LOCODE is one column on the web, two in the files

On the directory pages the five characters appear as a single LOCODE value, conventionally written with a space between the country and location elements for legibility — AD ALV. The space is a reading aid only; in use the code is five characters, ADALV. Every downloadable format instead splits the value into a Country field and a Location field, because that is more useful for sorting, joining and filtering.

Function is an 8-character positional string

The Recommendation defines the individual function codes; the directory encodes them as a fixed 8-character string, one position per function. A position holds its own digit when that function is present, and a hyphen when it is not.

For example, AD ALV (Andorra la Vella) carries --34-6--: positions 3, 4 and 6 are filled, so the location has road, air and multimodal facilities, and no others.

The special codes (0 for an unverified function, A for a Special Economic Zone) occupy the first position. A location must have at least one function recorded; see the function table for what each digit means.

Coordinates are degrees and minutes, not decimal

Coordinates are recorded as a single string in a compact, fixed-width form:

ddmmN dddmmE

• Latitude first: two digits of degrees, two of minutes, then N or S.
• A single space.
• Longitude second: three digits of degrees, two of minutes, then E or W.

There are no seconds and no decimal fraction — the resolution is one minute of arc. 4230N 00131E is the entry for Andorra la Vella. Note the leading zero on the longitude: the degree field is always three digits, so values below 100° are padded.

Decimal coordinates are held alongside, but not published

One minute of arc is roughly 1.8 km, so the Coordinates value above locates a place to within a grid square rather than to a point. That is what Recommendation 16 asks for, and the published value is unchanged.

For its own purposes the maintenance system also records the decimal degrees a contributor placed on the map when raising a Data Maintenance Request:

37.0206   -7.9356

Latitude then longitude, signed rather than lettered — the sign carries the hemisphere, so there is no N/S/E/W. These are held as two separate fields, not one lat,lng string. A joined value would contain a comma, which is the CSV field separator: any write that missed the quoting would split it in two and silently truncate the longitude, leaving a coordinate that still parses and is simply wrong.

Three things to be clear about:

• They are not part of Recommendation 16. No status, function or code decision rests on them, and they carry no authority. The Recommendation-16 value in the Coordinates column remains the definitive one.
• They are not published. The downloadable release formats — CSV, TXT, MS Access and the SKOS vocabulary — do not carry them.
• They are visible where the system uses them: in the per-country files in /locodes/ and in the JSON data artefacts, which is how the contributor portal reads them back. There they appear as a single coordinatesDecimal string, JSON having no delimiter to collide with.

Their only job is to let the change form show the exact point that was submitted, and let a later amendment adjust it, instead of rounding to the nearest minute each time an entry is edited.

Date is year and month only

Date is four digits, YYMM. 2505 is May 2025. There is no day component.

IATA is only populated when it differs

Where the location code element is itself the IATA code, the IATA column is left empty rather than duplicating it. A value appears only when the two diverge.

Name abbreviations and subordinate locations

A small set of standard abbreviations is used in the name columns:

Abbreviation	Meaning
Apt	Airport
I.	Island(s)
Pto	Puerto
Pt	Port
St	Saint

Where a separate code has been assigned to something subordinate to a main location — a second airport, an outlying port, a freight terminal — the name is written twice, in two places in the alphabetical listing:

• Under the main location, with the subordinate name after a hyphen: GB LHR London-Heathrow Apt
• Under its own name, with the main location after an oblique stroke: GB LHR Heathrow Apt/London

Both forms carry the same code. This is a listing convention, not two entries.

Facilities inside a location that do not have their own UN/LOCODE are handled as child codes instead.

The source data in this repository

The published artefacts are generated from one CSV per country in /locodes/. Those files follow the 12-field file layout above, in the same order, with three repository-specific conventions:

• No header row. The column order is fixed and implicit.
• Country header rows. The first row of each file names the country: the location field is empty and the name field is prefixed with a full stop (.ANDORRA). These rows are markers for the published listing, not entries, and the publisher filters them out when generating data artefacts.
• Two further fields, 13 and 14, holding the decimal latitude and longitude described above. Both are optional and almost always empty; either both are set or neither is. They are internal to the maintenance system and are not part of the published file layout.

Formatting rules for those files — encoding, line endings, quoting — and the normaliser and validator that enforce them are documented in locodes/README.md in the repository.

These files generate the publication

The per-country CSVs are the source from which the publication files are generated. At each release the publish pipeline reads them and produces the downloadable artefacts — the Part 1/2/3 CSVs, the text file, the MS Access database and the SKOS vocabulary — which are then listed on the publications page. Nothing is authored directly in a publication file: every value in a release traces back to a row in /locodes/.

Source

The column layout described here follows the UNECE UN/LOCODE column description. Where that page and Recommendation 16 differ, the Recommendation is authoritative.