Postal Codes Dataset for Isle of Man, IM

177
Updated:
Files:1
Size:3.92 kB
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/-/README.md
https://datahub.io/logistics/postal-codes-im/_r/-/datapackage.yml
Key Files

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

datapackage.ymlmetadata & schema
https://datahub.io/logistics/postal-codes-im/_r/-/datapackage.yml
README.mddocumentation
https://datahub.io/logistics/postal-codes-im/_r/-/README.md
Typical Usage
  1. 1. Fetch datapackage.yml to inspect schema and resources
  2. 2. Download data resources listed in datapackage.yml
  3. 3. Read README.md for full context

Data Files

Explore with AI

Postal Codes Data Resource for Isle of Man, IM

Download

Download CSV

About

Last updated
17 September 2026
Total rows
...
Format
CSV
File size
3.92 kB

About this dataset

Isle of Man (IM) — internal licensing notes

Source research, 2026-09-17 — first proper audit of this country

No .licensing-notes.md existed for IM before this pass. datapackage.yml does carry a sources:/licenses: block (unlike some other never-audited countries in this project, e.g. CH before its 2026-09-16 audit) — GeoNames, CC-BY-4.0 — but that block was never checked against the actual R2 object, and there is no structured licence_status record (source_url/licence_id/ decision/decided_by/channel) per the provenance gate.

1. What the current R2 file (im/im.csv, 5,632 bytes, 2026-07-30) actually is — VERIFIED

Fetched directly from the main postal-codes R2 bucket (read-only, R2_ACCESS_KEY/R2_SECRET_KEY from this repo's own .env). 87 data rows + header.

datapackage.yml's declared resource metadata is already stale against this: it says bytes: 5097, modified: '2024-11-07' — the live object is 5,632 bytes and was last written 2026-07-30. The file was regenerated at some point without the datapackage being updated to match.

Fetched https://download.geonames.org/export/zip/IM.zip (CC BY 4.0) directly for comparison: IM.txt also has exactly 87 rows, and in the same order. A full row-by-row comparison (postal-code sequence identical, set-equal) confirms the R2 file is a straight tab-to-comma conversion of raw GeoNames IM.txt, with several defects introduced in that conversion on top of GeoNames' own thinness:

GeoNames:  IM  IM4  Quine's Hill        Isle of Man  IOM          54.1929  -4.4832
R2 file:   IM,IM4,Quine s Hill,nan,,Isle of Man,IOM,nan,,54.1929,-4.4832,,

Confirmed defects

  • Literal "nan" string in admin_name1 on all 87 rows, and in admin_name3 on all 87 rows — exactly the same defect class already found and documented for CH/PR/CO. GeoNames itself leaves these fields blank; the conversion step read them with pandas/similar, got NaN, and wrote the literal string nan back out instead of an empty cell. (One row — IM2/Douglas — has admin_name2 genuinely blank in the GeoNames source too, and that field shows nan here as well.)
  • accuracy is float-formatted (4.0 instead of GeoNames' own integer 4) on the 3 rows that carry an accuracy value at all (Churchtown, Colby, and the IM2/Douglas row). Same bug class as CH.
  • Real place names are corrupted: apostrophes and hyphens are stripped and replaced with a literal space, turning existing Manx place names into names that don't exist. Confirmed against the GeoNames source directly — 5 of 87 rows (~6%) are affected:
    • Quine's HillQuine s Hill
    • St John'sSt John s
    • St Mark'sSt Mark s
    • Shoughlaige-e-CaineShoughlaige e Caine
    • Cronk-y-VoddyCronk y Voddy (Port e Vullen already has no hyphen in the GeoNames source, so it's unaffected — confirming the space-substitution is a conversion bug, not present upstream.)
  • admin_name1/admin_code1 are empty on every single row. The schema's "primary administrative division" field carries nothing for the whole country.
  • admin_name2/admin_code2 are not a real administrative division. 86 of 87 rows carry admin_name2 = "Isle of Man", admin_code2 = "IOM" — GeoNames repeating the country name itself (plus its own 3-letter internal token) as a placeholder, because GeoNames holds no real sheading/parish/local-authority data for IM at all. This is worse than a GeoNames-internal-code mislabelling (the CH/false-friend pattern) — there is no administrative content here whatsoever, just the country name copy-pasted into a field the schema documents as "secondary administrative division (e.g., county, district)."
  • postal_code is outcode-only (IM1, IM3, IM4IM9, plus a rarely-used IM2) — never a full unit postcode (IM1 1AA). This is inherent to GeoNames' IM coverage, not a conversion bug, but it means the shipped "postal codes" product for Isle of Man is really an 87-row outcode gazetteer covering 9 postal districts, against a real live total of ~4,650 unit postcodes (per IOM Post, May 2020 figure) — roughly a 1.9% granularity ceiling, independent of any packaging bug.
  • alternative_city_name contains real content not in GeoNames' standard postal export at all. Values like Doolish (Douglas), Kione Droghad (Onchan), Laksaa (Laxey), Rhumsaa (Ramsey), Balley Chashtal (Castletown) are genuine Manx Gaelic place names — but GeoNames' own postal-export readme.txt documents only 12 tab-delimited fields (country code, postal code, place name, admin name/code ×3, lat, lon, accuracy) with no alternate-names column. This column was populated via an undisclosed secondary join — almost certainly GeoNames' own gazetteer alternateNames data (also CC BY 4.0), but datapackage.yml's sources: block only cites the postal zip URL. Even under the licence this file already claims, the provenance is incomplete: a second GeoNames endpoint was used and never declared.

Verdict on the current file: it is a raw, unmodified-content GeoNames IM postal export, converted with the same class of packaging bugs found elsewhere in this project (literal "nan", float-formatted accuracy), plus a project-specific one not seen before (apostrophe/ hyphen stripping that corrupts real place names), on top of a source that was always going to be extremely thin for this country (outcode- level only, no real admin hierarchy at any tier).

2. Official tier-1/2 sources checked FIRST, per the standing GeoNames-is-fallback rule

Isle of Man Post Office (iompost.com) — checked directly, no bulk path

Re-verified live 2026-09-17. The postcode finder (iompost.com/tools-forms/postcode-finder/) states: "You must not use this service for any purpose other than your own personal use." No bulk download, no dataset, no API is offered. This matches the FedEx-pipeline researcher's finding from 2026-05-11 (fedex-agents-prototype/countries/IMN/research.json): registered-email lookup only, rate-limited to 10 searches/day on a free account. Independently corroborated by public reporting found in this pass: the Isle of Man Government's IT department sells the underlying postcode/geolocation dataset to a limited commercial customer base (couriers, delivery firms, retailers) — the authoritative bulk register exists, it is simply not open.

Royal Mail Postcode Address File for IM (postcodeaddressfile.co.uk) — official, but paid

46,706 delivery addresses at unit-postcode level, ~£85/year. No sheading/local-authority/parish field, no OS grid references for IM postcodes. Ruled out for a free/CC product without a separate licensing decision to purchase and redistribute it — not attempted in this pass.

OS Code-Point Open — confirmed EXCLUDED, same pattern as Jersey

Fetched the OS product page directly: "An open dataset of all the current postcode units in Great Britain." Explicitly England/ Scotland/Wales only. The Isle of Man is a Crown Dependency, not part of Great Britain, and is excluded — the identical exclusion already documented for Jersey in datasets/je/.licensing-notes.md. This rules out the fix that worked for the UK build.

postcodes.io API — checked, not usable for admin enrichment

Confirmed (per countries/IMN/research.json, and consistent with this pass): returns admin_ward: "Isle of Man (pseudo)" and null lat/lon for every IM postcode. No sheading, no parish, no coordinates.

Isle of Man Government Open Data (gov.im) — has a real OGL, but nothing relevant published

Confirmed a genuine Isle of Man Government Open Government Licence framework exists (gov.im, Council of Ministers Open Data Policy approved August 2019; "All content is available under the Open Government Licence, except where otherwise stated") — structurally the same kind of instrument as OGL-Jersey. Checked its open-data categories directly (open-data/government/, open-data/society/): the datasets actually published are Budget, International Development, Consultation Hub, Corporate Governance, Currency, Income & Expenditure, Pensions & Benefits, Town & Village Regeneration, Census, Electoral Registration, Social Attitudes Survey, Living Wage. No postcode, parish, sheading, or local-authority boundary dataset is published anywhere on this portal. This is a materially worse position than Jersey, whose OGL-Jersey portal at least hosts a 2011-census vingtaine/parish dataset (see datasets/je/.licensing-notes.md) — IM's OGL has no analogous admin-boundary release.

dankarran/isleofman-opendata (GitHub) — community, mixed licence, partial coverage

Confirmed licence is a stack: "public sector information licensed under the Isle of Man Open Government Licence" plus OpenStreetMap (ODbL) and Microsoft (ODbL) data. No prebuilt postcode→locality or postcode→parish CSV with admin fields exists in the repo — only raw postcode boundary generation from OSM. This is the source the FedEx pipeline's researcher (2026-05-11) selected for Phase 1 coordinates — see §4 below for why that build is not a clean drop-in.

GeoNames — fallback baseline, evaluated per the standing rule (checked LAST, not defaulted to)

download.geonames.org/export/zip/IM.zip → 200, CC BY 4.0, 87 rows. Already fully characterized above (§1) since it's also what the current R2 file is built from. Outcode-level only; no admin hierarchy; this is the thinnest GeoNames postal file examined in this project's audits so far, and there is no evidence a richer GeoNames variant exists for IM.

3. Isle of Man's real administrative structure — confirmed, and absent from the current file

Confirmed against Wikipedia and the FedEx-pipeline researcher's earlier work (countries/IMN/research.json, 2026-05-11):

  • No ISO 3166-2 codes are defined for Isle of Man at any tier — the ISO 3166-2:IM Wikipedia article states this explicitly. Any admin_code1 value for IM is necessarily non-ISO.
  • Real hierarchy: 6 historic sheadings (Ayre, Garff, Glenfaba, Michael, Middle, Rushen) → 21 modern local authorities (4 Town Districts, 2 Districts, 2 Village Districts, 13 Parish Districts, reflecting the 2016 Garff merger and 2020 Arbory-and-Rushen merger) → roughly 90 named localities/settlements.
  • None of this appears anywhere in the current R2 file. admin_name1 is blank, and admin_name2 is just the country name repeated. A consumer of im/im.csv today has no way to tell that Isle of Man has any administrative structure below the whole-island level.

4. A fuller build already exists locally, but it is not gate-clean or complete — do not adopt it as-is

fedex-agents-prototype/countries/IMN/data/Isle of Man.csv (built 2026-05-11, FedEx 9-column schema, never shipped to R2 or any customer) contains 1,360 rows of full unit postcodes (IM1 1AD format) with real sheading/local-authority/locality assignment — a genuine qualitative upgrade over the 87-row outcode file. Built via:

  1. Full-postcode + lat/lon from dankarran/isleofman-opendata's OSM-derived postcodes.csv.
  2. A point-in-polygon spatial join of those coordinates against OSM Overpass admin_level=6 (6 sheadings) and admin_level=8 (24 historic parishes, mapped to the 21 modern local authorities) boundary polygons, to assign stateName/county.
  3. cityName from a GeoNames outcode→locality lookup (non-OSM).

QA'd (qa_log.json, validation_report.json): Frictionless valid, 0 duplicates, all 1,360 rows matched HIGH confidence — but coverage is 29.25% against the real 4,650-PCU total, flagged WARN, because OSM only tags a postcode where at least one OSM address point already exists near it. This is real data, not fabricated, but it is a minority-coverage sample dressed as a full build would need to be disclosed as such.

This build does not pass the OSM/ODbL gate as constructed, and should not be "finished" into a shipped product without re-running it. This matches (and sharpens) the existing CLAUDE.md note for IMN under the 2026-08-24 gate audit ("passes by non-use — the shipped data is unmodified GeoNames, the OSM pipeline was planned, never built into the shipped product"). Checked directly in this pass: the OSM pipeline was built, as a local FedEx-schema file — it was simply never published anywhere, so no live product has yet hit the failure. Walking the four-prong gate against it:

  • Prong 1 (only the name travels into the output): satisfied on its face — the final CSV carries stateName/county text only, no lat/lon column survives into Isle of Man.csv.
  • Prong 3 (the points being enriched are genuinely non-OSM): FAILS. The postcode coordinates being matched against the OSM parish polygons are themselves OSM-derived (dankarran's postcodes.csv is built from OSM address points). There is no non-OSM point being labelled here — this is OSM matched against OSM, not the reverse-geocoding-a-genuinely- external-point case the safe harbour describes.
  • Prong 4 (not a systematic aggregation across the whole jurisdiction): FAILS, for the same structural reason KWT failed it — every available postcode point in the country is run through the same nationwide polygon join, which is exactly the "repeated small extractions are one big extraction" / systematic-aggregation case the gate is built to catch.
  • Attribution is required regardless, and none is currently recorded for either OSM or Microsoft in this build.

Net: the richer 1,360-row build is real, useful data, but it currently carries an OSM/ODbL exposure on its admin-name join that has not been resolved, on top of only ~29% postcode coverage — it is not simply better and ready to ship in place of the current GeoNames file.

Verdict

Rebuild recommended — but there is no clean drop-in replacement available today, and this is a genuine two-part decision, not a packaging fix alone.

  1. The packaging bugs in the current file are unambiguous and should never persist regardless of any sourcing decision: literal "nan" strings, float-formatted accuracy, and apostrophe/hyphen corruption of real place names (Quine s Hill, St John s, St Mark s, Shoughlaige e Caine, Cronk y Voddy). These are bugs, not judgment calls, and fixing them does not require resolving anything below.
  2. No clean, free, official bulk source exists — IOM Post is personal-use-only with no bulk path, the Royal Mail PAF for IM is a paid product, OS Code-Point Open explicitly excludes the Isle of Man (Crown Dependency, not Great Britain), postcodes.io returns nulls for every admin/coordinate field, and the Isle of Man Government's own OGL open-data portal — though real, and structurally comparable to OGL-Jersey — publishes no postcode, parish, sheading, or local-authority dataset at all. This is the same "no clean path without contact" situation documented for Jersey (datasets/je/.licensing-notes.md), possibly worse, since Jersey's OGL portal at least has a parish/vingtaine census layer and IM's does not.
  3. The existing fuller local build is the best data currently assembled for this country, but it needs a human decision before shipping, on two independent axes: (a) whether to accept and disclose the OSM/ODbL exposure on its admin-name join — the way JE shipped with a disclosed "unresolved" licence_status for its postcode layer — or re-derive the sheading/parish assignment from a non-OSM point source (none currently identified for IM); and (b) whether ~29% postcode coverage, clearly labelled, is an acceptable product versus the thinner-but-100%-of-what-GeoNames-has 87-row outcode file.
  4. Either way, datapackage.yml needs a structured licence_status block (source_url/licence_id/decision/decided_by/channel) rather than the current bare licenses: [{name: CC-BY-4.0}] array with no decision field — per this project's provenance gate, "unresolved" may not reach a shipped artifact, so a decision must be made and recorded explicitly before anything currently blocked can ship.

Not done in this pass, by design: no script written, no datapackage.yml change, no R2 write, no git commit. This file is the audit record only.

Sources checked this pass: im/im.csv (R2, fetched directly), download.geonames.org/export/zip/IM.zip, iompost.com/tools-forms/ postcode-finder/, postcodeaddressfile.co.uk (product listing), ordnancesurvey.co.uk/products/code-point-open, api.postcodes.io, gov.im/about-the-government/government/open-data/ and its Government/ Society sub-pages, github.com/dankarran/isleofman-opendata, en.wikipedia.org/wiki/ISO_3166-2:IM, and the FedEx pipeline's own fedex-agents-prototype/countries/IMN/research.json, countries/IMN/data/Isle of Man.csv, qa_log.json, and validation_report.json.

Not legal advice — a research summary of published terms and verified source availability.

Build, 2026-09-17 — packaging fix, GeoNames source unchanged

Local-only rebuild (datasets/im/scripts/build_postal_codes_product.py, datasets/im/data/). No R2 write, no git commit, no datapackage.yml or _meta/catalog.json change — those remain a separate, explicit human decision as noted in the Verdict above. This pass fixes only the unambiguous packaging bugs; it does not resolve the two open sourcing questions (whether to adopt the richer-but-OSM-exposed local build, or pursue a paid/contact-gated official source).

Raw sources fetched directly and stored under datasets/im/sources/:

  • postal_raw/IM.txthttps://download.geonames.org/export/zip/IM.zip (unchanged from the file already characterized in §1 — same 87 rows, same order, re-verified byte-identical in content).
  • gazetteer/IM.txthttps://download.geonames.org/export/dump/IM.zip (GeoNames' main toponym dump for IM, 216 rows) — used only to resolve a geonameid per place name, never redistributed as coordinates.
  • alternatenames/IM.txthttps://download.geonames.org/export/dump/ alternatenames/IM.zip (569 rows) — GeoNames' per-country alternate names file, filtered to ISO 639 gv (Manx Gaelic). All three are GeoNames CC BY 4.0, confirmed from each zip's own readme.txt (export/zip/readme.txt says "Creative Commons Attribution 4.0 License"; export/dump/readme.txt says the same explicitly with a 4.0 URL — no per-country carve-out applies to IM in either).

Defects fixed (all four confirmed present in the old R2 file, all confirmed fixed in the new build via direct inspection + assertions in the build script):

  1. Literal "nan" string in admin_name1/admin_name3 (all 87 rows) → written as "". Verified: zero cells equal to the string "nan" (case-insensitive) anywhere in the output.
  2. accuracy float-formatted (4.0) on the 3 rows that carry a value → GeoNames' raw value ("4") written verbatim, no float coercion. Verified: no accuracy value ends in .0; distinct values are {"", "4"}.
  3. Apostrophe/hyphen corruption (Quine's Hill, St John's, St Mark's, Shoughlaige-e-Caine, Cronk-y-Voddy) → fixed by reading place_name straight from the raw tab-delimited source via the csv module with no cleaning/transliteration step at all. Verified: all 5 names present intact in the output, byte-for-byte matched against sources/postal_raw/IM.txt.
  4. admin_name2="Isle of Man"/admin_code2="IOM" (86/87 rows) → left blank. This was GeoNames repeating the country name into a field the schema documents as a real secondary admin division; there is no sheading/parish/local-authority data to put there instead, so it is empty rather than a fabricated or copied placeholder.
  5. admin_name1/admin_code1 — re-confirmed genuinely empty in the raw source (all 87 rows) and left empty. Independently re-verified against en.wikipedia.org/wiki/ISO_3166-2:IM on 2026-09-17: Isle of Man has no ISO 3166-2 subdivisions at any tier, so there is no code to derive even in principle (unlike the KE/LK builds, where a real ISO code existed and only the crosswalk was missing).

alternative_city_name — kept, re-sourced, and disclosed. The old file's Manx Gaelic values (Doolish, Kione Droghad, Laksaa, Rhumsaa, Balley Chashtal) were real but came from an undisclosed second GeoNames endpoint never cited in datapackage.yml's sources: block. Reproduced this pass via a clean two-step join, both endpoints CC BY 4.0 same as the postal export:

  1. Match each row's place_name to a feature-class-P (populated place) entry in the gazetteer dump by exact name, to get a geonameid.
  2. Look up that geonameid in the alternate-names dump, filtered to language code gv.

Verified this independently reproduces 4 of the 5 names the old file carried by inspecting the actual geonameids matched (Douglas→3042237→ Doolish, Onchan→3042201→Kione Droghad, Castletown→3042255→Balley Chashtal, Ramsey→3042192→Rhumsaa) and confirms the underlying Laxey→Laksaa relationship exists in the alternate-names file at geonameid 3042217, even though this build's per-row join happens to also pick up 6 more matches the old file omitted (Dalby, Union Mills, Cregneish, Derbyhaven, Barregarrow, Foxdale) — 12 of 87 rows (Douglas appears twice, on IM1 and IM2) now carry a real, disclosed alternative_city_name, up from 5 in the old file, all from a source now correctly cited. The other 75 rows have no alternative_city_name because their place name either has no separate gazetteer entry (mostly small hamlets/farms not tagged as a populated place) or has no Manx-Gaelic alternate name recorded in GeoNames at all — both real gaps in the underlying gazetteer, not filled in.

Frictionless validation: run from inside datasets/im/data/ against the delivered datapackage.json (not the working copy) — VALID.

Not done in this pass, by design, per the task scope: no R2 upload, no git commit, no _meta/catalog.json or datapackage.yml change. The datapackage.yml's stale resource metadata (bytes: 5097, modified: '2024-11-07') documented in §1 above is therefore still stale after this pass — updating it is part of the publish step this task explicitly excluded, not an oversight here.