Non modificare manualmente file sotto data/, SQL di release o report
generati. Ogni correzione parte da una fonte dichiarata o da una regola
riproducibile.
Non reintrodurre materiale storico ritirato, copie dei relativi asset o baseline anteriori alla ricostruzione clean-room.
Una proposta deve indicare:
- record e campo interessati;
- valore corrente e proposto;
- editore, URL, data di riferimento e data di accesso;
- licenza e attribuzione;
- regola riproducibile;
- conseguenze su ID, riconciliazione e report.
Non usare scraping, Poste “Cerca CAP”, API non autorizzate o il servizio pubblico Nominatim per bulk geocoding. Non acquistare una fonte per conto del progetto e non accettare condizioni commerciali senza decisione del maintainer.
- il codice ISTAT identifica il comune;
- un CAP non identifica un comune;
- il nome simile non basta;
- più candidati restano ambigui;
- una località senza match resta senza comune padre;
official_verifiedeofficial_boundary_derivednon possono essere usati senza una nuova fonte ufficiale compatibile e documentata;- il campo GeoNames
accuracyva preservato; - GeoNames non deve essere presentato come Poste Italiane.
python -m pip install -r requirements.txt -r requirements-dev.txt
python scripts/build_dataset.py
python scripts/check_determinism.py
python scripts/validate_dataset.py
ruff check scripts tests
mypy
coverage run -m unittest discover -s tests
coverage report
node --test tests/pages_core.test.mjs
python scripts/build_pages.py
python scripts/build_release.py
python scripts/validate_release.py
git diff --checkVerificare che:
structural_qualitysiapassed;operational_data_readinessrestiexperimental_non_official;- due build siano identiche;
- nessun
source_idscanonico contenga identificativi di fonti ritirate; - nessun input, report o asset ripristini materiale storico ritirato;
- la Pages mostri warning e attribuzione GeoNames.
La PR deve descrivere fonti/licenze, schema, statistiche prima/dopo, rischi residui e comandi eseguiti. Tutti i check richiesti devono essere verdi prima del merge.
Per segnalazioni usare gli issue form per località, CAP, coordinate o variazioni amministrative. Discussioni e casi d'uso possono essere aperti in GitHub Discussions.
Il tag deve coincidere con project.json. Preparare release/<versione>.md,
costruire e validare dist/<versione>/, ma non creare tag o release senza
conferma esplicita del maintainer.