CZ Zoning Plan Amendment Watcher

Marketplace-native Apify Actor that watches Czech municipal official notice boards (úřední desky) for zoning-relevant postings — zoning plan amendments (změna územního plánu), new zoning plans, urbanistic studies, public consultations and planning decisions — classifies them with a transparent rule-based Czech lexicon, links them to cadastral areas (katastrální území) and parcel numbers, matches them against your watchlist, and emits provenance-linked dataset records with deep links to the official postings.

Who it is for

• Land scouts / akviziteři monitoring 10–50 cadastral areas across dozens of municipalities who cannot manually re-check boards and miss short statutory comment windows.
• Small-to-mid property developers needing early warning of upzoning/downzoning around owned or optioned land.
• Architects / planning consultants tracking proceedings that touch active commissions.

Sources and legal basis

Municipal notice-board publication is legally mandated by § 67 of Act No. 128/2000 Sb. (including electronic form). This Actor reads only publicly accessible listing pages:

Board ID	Municipality	Source
praha	Hlavní město Praha	eud.praha.eu electronic board (official)
ostrava	Statutární město Ostrava	ostrava.cz úřední deska
liberec	Město Liberec	liberec.cz/deska/

Posture:

• Honest User-Agent, low request rate (one listing request per board per run), politeness delay between boards, robots.txt respected (Liberec disallows /files/… asset paths — the Actor never downloads files; detail links are surfaced for you to open yourself).
• No authentication circumvention, no paywall bypass, no CAPTCHA evasion — ever.
• Delivery model is excerpt + deep link to the official posting; third-party copyrighted annexes are never republished wholesale.
• eDesky.cz offers a national aggregation but its API requires a user account key; this Actor therefore reads municipal boards directly. Built-in coverage is deliberately limited to the boards above plus any custom boards you add — see Coverage honesty below.

Input

Field	Type	Default	Description
mode	incremental | full	incremental	incremental: emit notices new since the previous run (first run establishes a baseline and emits the current backlog flagged baselineEstablished). full: re-emit everything currently posted within the lookback window.
boards	array of IDs or {name,url}	all three built-ins	Built-in IDs: praha, ostrava, liberec. Custom boards: {"name": "Obec X", "url": "https://…"} parsed by a conservative generic parser (marked parserKind: "generic", slightly damped confidence). Max 25 per run.
cadastralWatchlist	string[]	[]	Katastr names you care about (Strašnice, Hrušov…). Matching folds Czech diacritics and respects word boundaries. Hits are tagged and prioritized in output ordering. Max 200 entries.
daysBack	integer 1–90	14	Skip notices officially posted older than this (bounds first-run backlog). Undatable notices are always kept.
maxItems	integer 1–10000	500	Hard cap on zoning_notice records per run. Records cut by the cap stay pending and are retried next run (at-least-once delivery).

Output (default dataset)

One record stream, deterministic under identical inputs:

1. run_summary (always first): mode, baseline flag, board success/failure counts, raw vs zoning-relevant counts, emission counts, legal-basis note and disclaimer.
2. zoning_notice: classified planning notice with:
   • noticeClass: one of zmena_up, novy_up, uzemni_studie, verejne_projednani, uzemni_rozhodnuti, other_planning;
   • classificationConfidence (title match > body match; damped when families compete), matchedKeywords for auditability;
   • impactHint (upzoning / downzoning / neutral) with hard-capped LOW confidence — keyword-based impact guessing is explicitly not overpromised;
   • affectedCadastralAreas, parcelNumbers (best-effort extraction);
   • watchlistMatches; stable recordId (SHA-1); full provenance with deep links.
3. board_health (one per requested board): fetch/parse status, raw and zoning counts, latency, error text — so partial outages and layout breakage are visible instead of silent.

Incremental state lives in the key-value store under key watch-state: a single bounded document (hard cap 5,000 notices, oldest evicted first) with per-entry integrity fingerprints. Corrupt or tampered state degrades to an explicit baseline rather than silently suppressing diffs.

Coverage honesty

• Coverage equals exactly the enabled boards. Notices posted on physical boards only are invisible to any electronic monitor; this Actor never claims CZ-wide completeness.
• Liberec reachability: www.liberec.cz has been observed dropping connections from some datacenter IP ranges (including parts of the Apify platform), while working normally from residential/EU networks. When unreachable, the run still succeeds with the remaining boards and the failure is reported verbatim in that run's board_health row — never silently.
• A board that responds but yields zero parseable items is flagged in logs and visible via board_health across runs — layout changes surface as data, not as silent gaps.
• Classification is heuristic (rule-based lexicon with reported confidence), not a legal characterization. Always verify against the linked official posting.

Legal & attribution

• Source attribution on every record: "Czech municipal official notice boards (úřední desky)", with municipality, board URL and notice deep link.
• Informational monitoring aid only — not legal or planning advice. Users remain responsible for verifying deadlines and consequences against the official sources.
• No personal-data enrichment: applicant names inside notices are neither extracted nor stored.

Pricing

Free / pay-per-usage safe. This Actor performs no pay-per-event charging and stores no billing markers, so enabling PPE later requires an explicit pricing migration, never implicit charges.

Development

npm install
npm run lint          # ESLint
npm run typecheck     # tsc --noEmit
npm run build         # dist/
npm test              # unit + integration + adversarial + schema suites (offline fixtures)
npm run test:smoke    # live-source smoke against real boards (SMOKE=1)
npm run smoke:local   # end-to-end Actor run with local Apify storage

Node 20+. Tests use captured live fixtures plus clearly-marked synthetic zoning notices so flows are deterministic regardless of what each board publishes on a given day.