Establish contribution flow for reverse-geocoding polygons in OpenSAK-Data

[AgreeDK]

Problem Statement

Charles Suprin reached out on Facebook offering Bermuda parish polygons generated with the ConvertOSMtoPolygon script, which would bring OpenSAK's reverse-geocoding data more in line with project-gc. Currently several Bermuda parishes are missing from our data (see attached map comparison — the white/empty areas).

We currently have no defined process for accepting this kind of community contribution, even though the demand exists and the value (more accurate, more complete reverse-geocoding coverage) is clear.

Proposed Solution

Define and document a lightweight contribution flow for OpenSAK-Data, similar in spirit to our existing translation contribution process.

Proposed scope
Write a CONTRIBUTING.md (or similar) for the OpenSAK-Data repo describing:
Expected file format/structure for polygon submissions
Naming conventions
ODbL licensing consent/attribution requirements for submitted data
PR-based submission process (PR can be opened by the contributor, Fabio, or Allan)
Optional: basic CI validation on PRs (valid GeoJSON syntax, no self-intersecting polygons, naming convention check)
Manual review/vetting step before merge (at least initially — no automated acceptance)
Out of scope (tracked separately)
Any in-app feature to let users load/run their own local polygon files (see #777)

[AgreeDK]

Charles's underlying goal is broader than one-off contributions: he'd like OpenSAK to become authoritative (or match the best available) on reverse geocoding, and points out that administrative boundaries shift over time (e.g. Connecticut dropping counties for census areas), so this isn't a one-time data fix but something that needs an ongoing contribution path.

Bob Long described how GSAK historically handled this: a central, versioned online polygon repository. The first time a user's GSAK needs reverse geocoding for an area, it auto-downloads the polygons and caches them locally; on subsequent lookups it compares the local version against the online version and re-downloads only if newer. Submissions went through a vetting person (Clyde, later Mike) before being published. That's a meaningfully larger architecture (server-side versioning/distribution API + a vetting workflow) than what's in scope here — flagging it as a longer-term direction, not something to build now.

Immediate next step for Charles's Bermuda contribution: doesn't need to wait for this process to be formalized — can be taken in via a direct PR in the meantime.

[stoppie777]

I am working on updates to the UK counties, both GSAK .txt files and .geojson. The reason is that currently GSAK holds 67 UK counties when, in fact, there are 102 (some of the 67 haven't existed since 1996!). I am building these using the same OSM boundaries used by Project-GC - which we use for the likes of County Challenges etc. So, OSAK would definitely benefit from a mechanism to maintain local polygon updates. I will format the .geojson to match that currrently deployed on OSAK.