Rapidité de service des couches WFS

[rhum1s]

EPCI WFS

Simplification de la géométrie semble pouvoir résoudre le problème. Trouver un meilleur compromis ou créer une couche simplifiée et la reprendre manuellement, ou essayer la topologie dans PostGIS.

• [x] Test avec simplification vraiment invisible à l’œil

  
  -- Compte le nombre de vertices sur la table originale sans et avec simplification
  select sum(ST_NPoints(geom)) from cigale.epci_poll_backup
  union all
  select sum(ST_NPoints(ST_SimplifyPreserveTopology(geom,0.0004))) from cigale.epci_poll_backup;

-- Modifie la géométrie de la table avbec la géométrie de la table originale simplifiée update cigale.epci_poll as a set geom = ST_SimplifyPreserveTopology(b.geom,0.0004) from cigale.epci_poll_backup as b where a.gid = b.gid;

OK  388e671cc95d5cdedd44f508ff5efd0fc233b796

## COMM WFS

Simplification topo à 0.0004 est encore trop lourde. Idem 0.0008.
Même avec 0.001 qui est le max avant d'avoir trop d'erreurs de géométrie, la couche mets trop de temps à charger. Sans prendre en compte le temps de chargement des graphiques.
```sql
-- Backup table
create table cigale.comm_poll_backup as select * from cigale.comm_poll;

-- Compte le nombre de vertices sur la table originale sans et avec simplification
select sum(ST_NPoints(geom)) from cigale.comm_poll_backup
union all
select sum(ST_NPoints(ST_SimplifyPreserveTopology(geom,0.0004))) from cigale.comm_poll_backup
union all
select sum(ST_NPoints(ST_SimplifyPreserveTopology(geom,0.0008))) from cigale.comm_poll_backup
union all
select sum(ST_NPoints(ST_SimplifyPreserveTopology(geom,0.005))) from cigale.comm_poll_backup;

-- Modifie la géométrie de la table avbec la géométrie de la table originale simplifiée
update cigale.comm_poll as a
set geom = ST_SimplifyPreserveTopology(b.geom,0.001)
from cigale.comm_poll_backup as b
where a.gid = b.gid;

On applique quand-même une simplification de la géométrie 483551ce3fa414851971a911444a9b3ed75e77ab

Même en simplifiant chaque commune en un carré, le temps est extrêmement long! Est-ce que mapserver doit re-projeter la couche?

Possibilité de mettre des filtres dynamiques dans le mapfile et appeler ces valeurs à partir de l'URL

# Dans le mapfile
VALIDATION
    'ctype'    "[A-Z0-9._%+-|'\(\)]"
 #END
DATA "geom from [...] and siren_epci::text like '%ctype%' [...] "
# Dans l'url
...&ctype=200054807

OK 83b93ca96bc51e177511f833a3fe25108893efe5

Graphiques

Trop longs même sans le chargement des communes. Ce n'est pas le temps de création des graphiques mais le temps de récupération des données (requêtes SQL) qui pose problème.

• [x] Contraintes sur les tables
• [x] Cluster de tables Réduit énormément le temps d'éxécution des requêtes

  
  CREATE INDEX "idx.bilan_comm_v4_secten1.an.ss.code_cat_energie.id_polluant"
  ON total.bilan_comm_v4_secten1 USING btree (an,ss,code_cat_energie,id_polluant);

CLUSTER total.bilan_comm_v4_secten1 USING
"idx.bilan_comm_v4_secten1.an.ss.code_cat_energie.id_polluant";

#
OK 370e711910c9316116a8648eae8244a6386f1b06

- [ ] Hardware
- [ ] Mettre un sablier en attendant la fin du chargement

[rhum1s]

Si on simplifie beaucoup on peut bloquer le zoom. L'appli est faite pour être utilisée en niveau haut de zoom.

[rhum1s]

Essayer d'utiliser le cache NGINX?

[rhum1s]

Redémarrer le serveur?

[rhum1s]

Couche des EPCI - Simplification de la géométrie

Couche des communes - Simplification de la géométrie, ne charger que les communes de l'EPCI désiré avec une modification du Mapfile à la volée.

Graphiques - Contraintes sur les tables, cluster des tables

[rhum1s]

• [x] Essayer d'ajouter le paramètre polluant pour les couches EPCI et communes ce qui simplifierait le mapfile.
• [x] Cluster des tables EPCI et commnunes en fonction an, poll, epic.