Retour d'expérience montée de version atlas 1.5.0

[pbarille]

Bonjour,

Après avoir procédé à la montée de version de GeoNature en version 2.8.1 (depuis la 2.7.5), nous venons de passer l'atlas en version 1.5.0 (depuis la 1.4.2) - Merci pour cette nouvelle version !

Nous avons cependant eu quelques souci avec la réinstallation complète de la BDD (install_db.sh) en utilisant le script fourni dans la version 1.5.0, les voici ainsi que la méthode appliquée pour résolution si cela peut avoir un intérêt pour la communauté.

Impossibilité de supprimer la base existante en lançant le script install_db.sh
Nous avons dû modifier le fichier "settings.ini" présent dans la configuration de l'Atlas et passer le paramètre drop_apps_db à true pour autoriser la suppression et la recréation.

Impossible d'accéder aux foreign tables utilisateurs.bib_organismes et gn_meta.cor_dataset_actor
Nous avons passé les requêtes suivante sur la base geonature2db :

GRANT USAGE ON SCHEMA gn_meta TO geonatatlas;
GRANT SELECT ON TABLE gn_meta.cor_dataset_actor TO geonatatlas;
GRANT USAGE ON SCHEMA utilisateurs TO geonatatlas;
GRANT SELECT ON TABLE utilisateurs.bib_organismes TO geonatatlas;

Vue syntheseff personnalisée
Nous avons une vue syntheseff spécifique qui nous renvoyait 0 résultats.
Un changement de projection est intervenue sur la nouvelle version, il est désormais nécessaire de reprojeter les centroïdes en 4326 et non plus en 3857

Vue materialisée vm_communes
Nous avons dû commenter la ligne suivante dans la requête de création de la vm_communes :

JOIN atlas.t_layer_territoire t ON ST_CONTAINS(ST_BUFFER(t.the_geom,200), c.the_geom)

Cette partie de la requête nous renvoyais une erreur "GEOSBuffer: std::bad_alloc" mais peut-être est-ce dû à la configuration de notre serveur ou à nos données - même si pas d'erreur de géométrie remontée par Postgis sur t.the_geom

Bonne fin de journée,
Pascal

[camillemonchicourt]

Merci beaucoup pour ce retour très précieux, car cette nouvelle version regroupe beaucoup de contributions de beaucoup de projets et cela a été complexe et long de les assembler, et donc de tout bien vérifier et tester.

A noter que depuis une version 1.5.1 est sortie avec quelques corrections de l'installation et surtout une mention pour installer NVM en cas de mise à jour, mais vous l'avez certainement vue : https://github.com/PnX-SI/GeoNature-atlas/releases

Concernant le paramètre drop_apps_db à true en effet c'était implicite dans notre tête, du coup on n'a pas pensé de le mentionner, mais on va l'indiquer dans les notes de version.

OK pour les GRANT, il faut que l'on regarde où on peut ajouter ça. Bien vu.

Bien vu aussi pour les projections, on va l'indiquer.

Pour le Buffer sur les communes, on va regarder ça de plus prêt.

Par curiosité, si votre atlas est en ligne et publié, je suis preneur de l'URL pour voir la nouvelle version en production ?

Merci.

[pbarille]

Bonjour,

L'atlas en version 1.5 est installé uniquement sur notre serveur de développement pour le moment. Il devrait être en prod en janvier 2022. Nous communiquerons le lien dès qu'il sera en ligne.

Bonne fin de journée,

[camillemonchicourt]

OK les retours ont été ajouté aux notes de version de la 1.5.0.

Par contre pour le soucis sur la vm_communes, je ne sais pas pourquoi ce soucis est apparu et n'était pas présent dans la version précédente.
Quand on a beaucoup de données, cette intersection peut être longue, lourde et ne pas aboutir, mais dans ce cas, ça aurait fait pareil en 1.4.0.
A voir si d'autres structures ont le même soucis.

[pbarille]

Bonjour,

Voici un retour complémentaire sur le buffer utilisé dans la création de la vm_communes.
Après quelques investigations, il nous semble que le problème vient du calcul d'un buffer métrique sur une donnée en SRID 4326.

En modifiant la requête de cette manière, nous n'avons plus de problème et un temps d'exécution plus que raisonnable (environ 20 secondes pour la Région Bretagne) :

CREATE MATERIALIZED VIEW IF NOT EXISTS atlas.vm_communes
TABLESPACE pg_default
AS
WITH t_layer_buffer AS(
SELECT st_transform(st_buffer(st_transform(t.the_geom,2154),200),4326) as buff
FROM atlas.t_layer_territoire t
)
 SELECT c.insee,
    c.commune_maj,
    c.the_geom,
    st_asgeojson(st_transform(c.the_geom, 4326)) AS commune_geojson
   FROM atlas.l_communes c
  JOIN t_layer_buffer tlb ON st_contains(tlb.buff, c.the_geom)
WITH DATA;

Bonne fin de journée,

[jpm-cbna]

En complément, j'ai testé la requête suivante:

SELECT st_buffer(t.the_geom, 200) AS buff FROM atlas.t_layer_territoire AS t ;

Le polygone obtenu ne correspond pas du tout à mon territoire avec un buffer de 200m.
C'est facilement visualisable avec DBeaver:

Pour que cela fonctionne correctement, il faut utiliser une des 2 solutions ci-dessous.

Apparemment, un cast vers ::geography puis dans notre cas vers ::geometry pourrait être une alternative à l'utilisation de st_tranform() pour la création du buffer:

st_transform(st_buffer(st_transform(t.the_geom, 2154), 200), 4326) AS buff

peut être remplacé par:

st_buffer(t.the_geom::geography, 200)::geometry AS buff,

Pour tester, vous pouvez lancer la requête suivante dans la base de l'Atlas:

SELECT 
	st_buffer(t.the_geom::geography, 200)::geometry AS buff1,
	st_transform(st_buffer(st_transform(t.the_geom, 2154), 200), 4326) AS buff2
FROM atlas.t_layer_territoire AS t ;

J'obtiens les mêmes buffers. Pour mieux les visualiser, vous pouvez mettre le second buffer à 100m au lieu de 200m.

Dans les 2 cas, le temps de génération de la VM passe de 14mn à 7mn.
Bien entendu le résultat est différent aussi car la requête d'origine créée un buffer erroné.

Second point, dans mon cas le territoire utilisé est une région. Avec un buffer de 200m je n'arrive pas à sélectionner toutes les communes de la région, seulement 921 sur 946. Pour que cela fonctionne correctement, j'ai du augmenter la taille du buffer à 500m. Malheureusement, cette augmentation de taille du buffer augmente aussi le temps d'execution de la requête.

La requête:

CREATE MATERIALIZED VIEW atlas.vm_communes AS
WITH layer_buffer AS(
    SELECT st_buffer(t.the_geom::geography, 500)::geometry AS buff
    FROM atlas.t_layer_territoire AS t
)
SELECT
    c.insee,
    c.commune_maj,
    c.the_geom,
    st_asgeojson(st_transform(c.the_geom, 4326)) AS commune_geojson
FROM atlas.l_communes AS c
    JOIN layer_buffer AS lb
        ON st_contains(lb.buff, c.the_geom) ;

Pour vraiment gagner en performance et générer la VM Communes en 1 seconde, il est nécessaire d'utiliser la technique de subdivision du territoire (st_subdivide()). Pour que cela soit vraiment performant, il faut stocker le résultat dans une table ou une VM et indexer les géométries créees.
Nous utilisons un buffer négatif dans ce cas, car la présence d'une commune sur le territoire et alors vérifiée avec la fonction st_intersect().
Cela implique de maintenir cette VM et de modifier la fonction de rafraîchissement des VMs.
Je vais proposer une PR avec ce fonctionnement.

Voici le code SQL en question:

DROP MATERIALIZED VIEW IF EXISTS atlas.vm_communes ;
DROP MATERIALIZED VIEW IF EXISTS atlas.vm_subdivided_territory ;

CREATE MATERIALIZED VIEW atlas.vm_subdivided_territory
AS 
	SELECT
		random() AS gid,
		'territory_buffer-200' AS territory_layer_code,
		st_subdivide(st_buffer(t.the_geom::geography, -200)::geometry, 255) AS geom
	FROM atlas.t_layer_territoire AS t
WITH DATA;

CREATE INDEX ON atlas.vm_subdivided_territory USING gist (geom);
CREATE UNIQUE INDEX ON atlas.vm_subdivided_territory USING btree (gid);


CREATE MATERIALIZED VIEW atlas.vm_communes AS
SELECT
    c.insee,
    c.commune_maj,
    c.the_geom,
    st_asgeojson(st_transform(c.the_geom, 4326)) AS commune_geojson
FROM atlas.l_communes AS c
WHERE EXISTS (
		SELECT 'X' 
		FROM atlas.vm_subdivided_territory AS st 
		WHERE st_intersects(st.geom, c.the_geom)
	) 
WITH DATA;

CREATE UNIQUE INDEX ON atlas.vm_communes (insee) ;
CREATE INDEX index_gist_vm_communes_the_geom ON atlas.vm_communes USING gist (the_geom) ;