Postal Codes Dataset for Serbia, RS

463
Updated:
Files:1
Size:74.9 kB
Rows:1,155
Formats:csv
License:CC-BY-4.0

Postal Codes Dataset for Serbia, RS 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 →

Premium

You're viewing a free sample

Get the complete dataset — all rows and files — delivered instantly after checkout, with lifetime access to the latest version.

  • Secure checkout via Stripe
  • Instant download after payment
  • Lifetime access to the latest version
  • Creative Commons Attribution 4.0 International license
20% off
$49.90$39.92
one-time payment

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-rs/
https://datahub.io/logistics/postal-codes-rs/_r/-/.licensing-notes.md
https://datahub.io/logistics/postal-codes-rs/_r/-/.migration-notes.md
https://datahub.io/logistics/postal-codes-rs/_r/-/ATTRIBUTION.txt
https://datahub.io/logistics/postal-codes-rs/_r/-/README.md
https://datahub.io/logistics/postal-codes-rs/_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-rs/_r/-/datapackage.yaml
README.md— documentation
https://datahub.io/logistics/postal-codes-rs/_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

postal-codes-rs-sample


About this dataset

Serbia (RS): migration notes

Internal record of the P5 migration from the old script to the producer: the discrepancies found, their causes, and who decided what. This is a dated record (2026-10-11), so the numbers are as of the migration and not kept current. It is not shipped in the zip.

  • Issue: datopian/postal-codes#41 (no builder scripts in the repo)
  • Commits: the recovered builder, then the producer (this branch)
  • Parity verdict: explained (gate: sign-off) [row_order ×1], covered by the standing sign-off
  • Producer: custom, refresh disabled

Recovered builder

build_postal_codes_product.py (dated 2026-08-31) was found uncommitted in the working copy, together with its two saved GeoNames inputs. It is committed unchanged in the commit before this one, then removed by the producer commit.

Re-run on 2026-10-11 against its saved inputs it reproduces the live rs.csv byte for byte (sha256 ed43ff7656…). The producer was then checked the same way: its transform() on those saved inputs gives the live data, differing only in line endings, and in row order inside shared postal codes.

Sources

InputURLNotes
GeoNames postal exporthttps://download.geonames.org/export/zip/RS.zipCC BY 4.0. Admin fields are empty in this file
GeoNames gazetteer dumphttps://download.geonames.org/export/dump/RS.zipSame publisher and licence. Gives each populated place its district (admin1 SE/VO, admin2 0-24)

Parity against the live zip (2026-10-11)

Rows: 1,155 live and 1,155 fresh, none only on one side, 0 changed cells. Order differs only inside postal codes that have several rows (GeoNames' tie order), the row_order class pre-approved on 2026-10-02.

GeoNames' files haven't changed for Serbia since the live build, so the only difference is the row order and CRLF → LF.

Decisions

DecisionByBasis
Port the recovered builder faithfully; no new source or logicUser, 2026-10-11The 2026-10-03 rule ("no producer from scratch when no builder exists") doesn't apply: the builder was found, and re-running it reproduces the live CSV byte for byte
LF line endings (the old script wrote CRLF)Standing rule (user, 2026-10-02)format-only verdicts pass; every shared producer writes LF
Drop the hardcoded row-count assertP5 ruleStructural checks (columns, uniqueness, formats, full admin coverage) stand in
Keep README.md and ATTRIBUTION.txt from the repo; don't re-harvest them from the live zipAgent, following PR #38The repo copies were corrected there (no hardcoded data, true sources); the zip copies still carry counts and the old wording
refresh.enabled: falseAgentNothing publishes before the owner signs off; flip it when R2 is updated

Transforms carried over

  • District (okrug): each postal row is matched to a gazetteer place by name (or asciiname); with several candidates the nearest by haversine distance wins, if within 50 km. Otherwise the nearest populated place of any name within 100 km. A row with none is a ProducerError.
  • District name and ISO code from a fixed table; "Morava" is corrected to "Moravica" (RS-17). The 7 Vojvodina districts also get admin_name2 "Vojvodina" and RS-VO.
  • Coordinates rounded to 5 decimals, accuracy AREA. Checks (5-digit codes, unique (postal_code, place_name), no nan, all 25 districts) are ProducerErrors.

Open questions

  • The public sample at postal.datahub.io/rs/rs.csv is an older build than the zip (no district, accuracy 4; 0 of its 100 rows match the zip's first 100). Publishing the new sample fixes this; nothing has been uploaded.
  • R2 is untouched. Publishing waits for the owner's sign-off.

Provenance

Written 2026-10-11 from the recovered script, the re-run against R2, scripts/parity.py rs (reads the live zip, writes nothing) and the Frictionless validation of the built zip.