Postal Codes Dataset for Malta, MT

159
Updated:
Files:1
Size:4 kB
Rows:73
Formats:csv
License:CC-BY-4.0

Postal Codes Dataset for Malta, MT including name of the city, town, or place, various administrative divisions and alternative city names.

Part of a Data Solution

  • Postal Codes Solution

    Every worldwide postal-code dataset in one bundle — the ultimate global reference for precise postal codes.

    Explore →

API Access

Access dataset files directly from scripts, code, or AI agents.

Browse dataset files
Dataset Files

Each file has a stable URL (r-link) that you can use directly in scripts, apps, or AI agents. These URLs are permanent and safe to hardcode.

/logistics/postal-codes-mt/
https://datahub.io/logistics/postal-codes-mt/_r/-/.licensing-notes.md
https://datahub.io/logistics/postal-codes-mt/_r/-/.migration-notes.md
https://datahub.io/logistics/postal-codes-mt/_r/-/ATTRIBUTION.txt
https://datahub.io/logistics/postal-codes-mt/_r/-/README.md
https://datahub.io/logistics/postal-codes-mt/_r/-/datapackage.yaml
Key Files

Start with these files — they give you everything you need to understand and access the dataset.

datapackage.yaml— metadata & schema
https://datahub.io/logistics/postal-codes-mt/_r/-/datapackage.yaml
README.md— documentation
https://datahub.io/logistics/postal-codes-mt/_r/-/README.md
Typical Usage
  1. 1. Fetch datapackage.yaml to inspect schema and resources
  2. 2. Download data resources listed in datapackage.yaml
  3. 3. Read README.md for full context

Data Files

Explore with AI

postal-codes-mt

Download

Download CSV

About

Last updated
5 October 2026
Total rows
73
Format
CSV
File size
4 kB

About this dataset

Malta (MT): migration notes

Internal record of the P6 migration from the old scripts to the producer: the discrepancies found, their causes, and who decided what. This is a dated record, so the numbers are as of the migration and not kept current. It is not shipped.

  • Issue: pc-28e.8.15
  • Commit: see git log -- datasets/mt (P6 mt commit)
  • Parity verdict: format-only (gate: pass, exit 0), against the live public CSV
  • Producer: custom, refresh disabled

Sources

InputURLNotes
GeoNames postal exporthttps://download.geonames.org/export/zip/MT.zipMember MT.txt; 3-letter locality prefixes only (GeoNames withholds the 4-digit suffix "for copyright reasons")
  • The file the old build_postal_codes_product.py (2026-09-15) read from its local snapshot sources/postal_raw/MT.txt.
  • Stable "latest" URL; nothing versioned to resolve. mt.inputs.json records bytes and sha256 per run.

Parity against the live public CSV (2026-10-05)

Rows: 73 live and 73 fresh, none only on one side, 0 changed cells, 0 cell classes, 0 duplicate keys. Same row order. The only difference is line endings: live is CRLF (old builder's csv.DictWriter default), fresh is LF. With \r stripped from live, the files are byte-identical.

No discrepancies to trace.

Decisions

DecisionByBasis
Accept the CRLF→LF differenceStanding rule (format-only parity pre-approved)0 changed cells, equal rows
latitude/longitude → numberStanding rule (real types, as in ad)All values numeric in the produced CSV
accuracy → integer, standard GeoNames accuracy descriptionStanding ruleAll values are 4 in the produced CSV
primaryKey: [postal_code, place_name]Agent, from the old builder's PKUnique on the produced CSV; the producer checks it. postal_code alone is also unique today, but the old builder keyed on the pair, so that was kept
Old exact-row-count assert droppedBrief (no row-count asserts)Structural checks (68 councils, known GeoNames codes, PK unique, MT only, no "nan") kept
Remove the row/prefix count from the descriptor descriptionStanding doc ruleRephrased as "locality prefixes covering all 68 local councils"
README.md left unchangedAgentIt has no counts and no licence_status line, and is neither the "no data yet" stub nor the "sample … contact sales" text; see open questions

Transforms carried over

From build_postal_codes_product.py (2026-09-15):

  • admin_code1: GeoNames numeric admin code ("01".."68") → ISO 3166-2:MT through the old builder's crosswalk (verified by name against Wikipedia's ISO_3166-2:MT, 2026-09-15), including the island swaps (Rabat/Victoria, the two Żebbuġ).
  • admin_name1: council name per GeoNames code (GeoNames' own admin_name1 is a Maltese restatement of place_name, e.g. "Il-Birgu").
  • postal_code, place_name, coordinates and accuracy as-is; alternative_city_name empty.
  • Asserts → ProducerError: 12 columns, every row MT, known GeoNames codes, no literal "nan", (postal_code, place_name) unique, all 68 councils present. The old "accuracy ends in .0" check is moot (no pandas, values are read as text) and was not ported.

Not ported

  • The old builder's generated datapackage.json/README.md/ATTRIBUTION.txt/zip (build.py and the descriptor own these now), and publish_r2.py.
  • The old builder's postal_code pattern constraint (^[A-Z]{3}$) and its per-field descriptions; the descriptor keeps its existing field descriptions.

Open questions

  • pending: README.md is the generic template ("a comprehensive list of postal codes … sourced from official and publicly available records"). For a GeoNames locality-prefix-only dataset this overstates it; the descriptor description and ATTRIBUTION.txt carry the real caveat. Not one of the brief's stale-README cases, so left as is; the user may want it rewritten from the old builder's README template.
  • .licensing-notes.md still quotes dated row counts; left for the pc-hfz sweep.