Support user-supplied custom polygon files for reverse geocoding

Aperta
  • Qualcosa non va?
#777 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
12/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
python
Ambito
data

Direzione di ricerca

The issue names the existing _db_key() settings pattern as the place to hang a per-database custom polygon path, but names no source files. Before any code, settle the open questions: replace or overlay the bundled OpenSAK-Data set, how the file is selected and validated, and what happens on malformed GeoJSON. Check for an existing feature request and align the format with issue #776. Done means a design decision is recorded, not a patch.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area: geo-data feature
Problem Statement

Following up on Charles Suprin's Facebook request (Bermuda polygons) — a separate, app-side need identified by Fabio: give users a way to run reverse geocoding against their own polygon file instead of (or in addition to) the bundled OpenSAK-Data set.

Charles's specific use case: he wants a more complete/accurate Bermuda dataset than we currently ship, and would like to point OpenSAK at his own file rather than waiting for it to be merged into OpenSAK-Data.

This is distinct from custom-polygon support for challenge types like DeLorme — this is about reverse-geocoding source data specifically.

Proposed Solution

Goal

Let users supply their own polygon file for reverse geocoding, on a per-database basis (using the existing _db_key() settings pattern).

Open questions to resolve before implementation
Does a custom file replace the bundled dataset entirely, or overlay it (e.g. only for areas the custom file covers, falling back to OpenSAK-Data elsewhere)?
File selection: exposed in Settings, with file picker + validation on load?
What happens on invalid/corrupt/malformed GeoJSON — clear error message, fallback to bundled data, or hard failure?
Expected file format — should match whatever format we settle on in the contribution guide (issue #776) so a file good enough to submit is also good enough to load locally.
Check for an existing GitHub feature request on this (Fabio mentioned recalling one — worth confirming before starting design work, to avoid duplicating discussion).
Out of scope
Any server-side/central distribution or auto-update mechanism for polygons (see notes on GSAK's model in issue #776) — this issue is about loading a local file only.
Priority note

Lower priority than issue #776 — not urgent for Charles's specific Bermuda contribution, since that can be handled via a manual PR into OpenSAK-Data in the short term.

Lingua principale
Python
Stelle
37
Fork
17
Merge medio
16h 7m
PR unite (30g)
128

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di OpenSAK-Org/OpenSAK

Tutte le issue di OpenSAK-Org/OpenSAK

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.