# Projections socio-démo et filtrage territorial

## Principe

L'application démarre au niveau `commune` afin que l'utilisateur choisisse immédiatement une commune. Ce choix est propagé à tous les endpoints métier : carte, frise temporelle, KPI bâtimentaires, graphiques, socio-démo, consommation foncière et sources.

```text
GET /api/territoires?niveau=commune
GET /api/indicators?niveau=commune&territoire=62001
GET /api/batiments?niveau=commune&territoire=62001&year=1980&mode=cumul
```

Le niveau `epci` reste disponible pour retrouver la lecture du premier POC et pour les indicateurs dont l'échelle communale n'est pas pertinente.

## Projection démographique

La population observée doit être distinguée de la population projetée.

- Observé : INSEE, recensement de la population, idéalement à la commune.
- Projeté : INSEE OMPHALE, avec millésime, scénario, horizon et échelle explicites.

Point de vigilance : OMPHALE produit des projections à une échelle compatible avec la méthode, généralement EPCI ou zone d'étude de taille suffisante. Une commune filtrée dans l'interface ne doit donc pas faire croire à une projection communale officielle si cette projection n'existe pas.

## Règle d'affichage proposée

Quand l'utilisateur sélectionne une commune :

1. afficher les données observées communales ;
2. afficher les projections seulement si elles existent à cette échelle ;
3. sinon, afficher une projection contextualisée issue de l'EPCI / zone OMPHALE, avec une mention claire ;
4. rendre visible la source, le scénario, l'horizon et la limite méthodologique.

## Contrat PostGIS attendu

La vue `foncier_poc.v_batiments_historique` doit contenir :

```text
id_batiment
geom
code_insee
commune
code_territoire
nom_territoire
annee_apparition
surface_emprise_m2
usage
source_annee
qualite_annee
```