Postal Codes Dataset for Isle of Man, IM

294
Updated:
Files:1
Size:3.83 kB
Rows:87
Formats:csv
License:CC-BY-4.0

Postal Codes Dataset for Isle of Man, IM 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-im/
https://datahub.io/logistics/postal-codes-im/_r/-/.licensing-notes.md
https://datahub.io/logistics/postal-codes-im/_r/-/.migration-notes.md
https://datahub.io/logistics/postal-codes-im/_r/-/ATTRIBUTION.txt
https://datahub.io/logistics/postal-codes-im/_r/-/README.md
https://datahub.io/logistics/postal-codes-im/_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-im/_r/-/datapackage.yaml
README.md— documentation
https://datahub.io/logistics/postal-codes-im/_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-im


About this dataset

Isle of Man (IM): migration notes

Internal record of the P6 migration from the old script 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.12
  • Commit: the worktree commit P6 im: SST producer; parity format-only (crlf) (pc-28e.8.12)
  • 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/IM.zipMember IM.txt. The old builder read a local copy at sources/postal_raw/IM.txt
GeoNames main gazetteer dumphttps://download.geonames.org/export/dump/IM.zipMember IM.txt; place_name → geonameid (feature class P) for the Manx-name join. Old local copy sources/gazetteer/IM.txt; URL from the old builder's docstring and generated datapackage
GeoNames alternate-names dumphttps://download.geonames.org/export/dump/alternatenames/IM.zipMember IM.txt; ISO 639 gv (Manx Gaelic) names. Old local copy sources/alternatenames/IM.txt; URL from the same places
  • All three URLs are stable, not versioned. Sizes and sha256 are recorded in data/im.inputs.json; --no-fetch reuses the cache.
  • The descriptor sources listed only the postal export; the two dumps were added, as the old builder's own datapackage listed them.

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

Rows: 87 live and 87 fresh, none only on one side, 0 changed cells, no cell classes, same row order. The only difference is line endings: live uses CRLF, the producer writes LF (3915 vs 3827 bytes). Covered by the standing CRLF→LF sign-off.

No discrepancies to trace. The Manx-name join reproduces all live alternative_city_name values (e.g. Douglas → Doolish, Peel → Purt ny h-Inshey, Union Mills → Mwyllin Doo Aah).

Decisions

DecisionByBasis
Accept CRLF→LFStanding rule (user, P5 standing sign-off)Format only, equal rows, 0 changed cells
latitude/longitude → number, accuracy → integerStanding rule (real types, user decision), derived from the produced CSVaccuracy is 4 or empty
primaryKey: [postal_code, place_name]Standing rule, derived from the produced CSVUnique in the output (place_name alone is not: Douglas and Ballasalla each appear under two outcodes); the old builder's datapackage used the same key
postal_code pattern constraint ^IM\d$Agent: port choiceFrom the old builder's generated schema; the producer also checks it
Field descriptions from the old builder's generated schema (counts removed); accuracy description set to the standard textAgent: port choice / standing doc ruleThe P3 generic descriptions didn't say the admin columns are deliberately empty
Count removed from the descriptor description ("87 outcode-level postal codes" → "outcode-level postal codes (IM1-IM9)")Standing doc rule (no counts)
Replace the old row-count assert with structural checks (columns, IM country code, admin values only empty or the known "Isle of Man"/"IOM", postal-code pattern, unique PK, the five once-corrupted names present intact)Agent: port choiceBrief: no exact row-count asserts
README.md left as isAgentIt is a generic description with no counts, no licence_status line and no "sample/contact sales" or "no data yet" text, so none of the doc rules apply

Transforms carried over

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

  • Cells copied verbatim with csv (no pandas): no literal "nan", accuracy 4 not 4.0, apostrophes/hyphens intact in place names.
  • admin_name1..3 / admin_code1..3 all empty (admin_name2/admin_code2 "Isle of Man"/"IOM" is the country name, not an admin tier; IM has no ISO 3166-2 subdivisions).
  • alternative_city_name: first class-P gazetteer entry by exact name → first gv alternate name of that geonameid.
  • Rows keep the postal export's order.
  • Old asserts → ProducerError.

Not ported

  • The old builder's generated README/ATTRIBUTION/datapackage.json and zip: build.py and the committed descriptor/README own those; free datasets get no zip.
  • publish_r2.py: removed; publishing is the shared pipeline's job.

Open questions

  • None needing the user. .licensing-notes.md was left verbatim; there is no ATTRIBUTION.txt in the dataset directory (pc-hfz sweep).