[Synthèse] - Affichage données sensibles

[jbrieuclp]

Version
2.15.0 et inférieures et suivantes ?

Description du bug
Dans la synthèse, lors de la requête intégrant un critère spatiale (par exemple une commune, pour les autres je ne sais pas car pas testé, mais ce devrait être la même) aucun résultat de donnée sensible ne remonte.

Comportement attendu
Faire remonter les données sensibles de manière dégradée

Cause
La sous-requête générée concernant les données sensibles est formatée de cette manière :

WITH 
area_filter AS 
(
	SELECT ref_geo.l_areas.geom_4326 AS geom_4326, ref_geo.l_areas.id_area AS id_area, ref_geo.l_areas.id_type AS id_type, ref_geo.l_areas.area_name AS area_name, ref_geo.l_areas.area_code AS area_code, ref_geo.l_areas.geom AS geom, ref_geo.l_areas.centroid AS centroid, ref_geo.l_areas.source AS source, ref_geo.l_areas.enable AS enable, ref_geo.l_areas.meta_create_date AS meta_create_date, ref_geo.l_areas.meta_update_date AS meta_update_date 
FROM ref_geo.l_areas 
WHERE ref_geo.l_areas.id_area IN (23342))

[...]

SELECT 2 AS priority, gn_synthese.synthese.id_synthese AS id_synthese, ST_Transform(l_areas_1.geom, 4326) AS geom 
FROM ref_geo.l_areas, 
area_filter, 
gn_synthese.synthese 
[...]
WHERE [...]
	AND ST_Intersects(ref_geo.l_areas.geom_4326, area_filter.geom) 
	[...]
	AND gn_synthese.synthese.id_nomenclature_sensitivity != 67 
ORDER BY gn_synthese.synthese.id_synthese DESC
LIMIT 200000

Premier point : la partie ST_Intersects(ref_geo.l_areas.geom_4326, area_filter.geom) fait une intersection entre une geom en 4326 et une geom en 2154, donc fatalement, ça ne marche pas...
Second point : je ne sais pas quel est l'objectif de cette jointure en mode FULL JOIN ?

ref_geo.l_areas, 
area_filter, 
gn_synthese.synthese 

parce qu'au lieu de remonter 1 donnée de la synthèse on remonte autant de fois cette même donnée qu'il y a de géométries de la table ref_geo.l_areas qui intersecte notre pauvre commune (c'est déjà beaucoup si l'on filtre avec une commune, alors si c'est un département...)

En ce qui concerne le premier point, l'origine du bug est là :
https://github.com/PnX-SI/GeoNature/blob/5e166f3747735f457ec007b64a0060c1a9bc211f/backend/geonature/core/gn_synthese/utils/query_select_sqla.py#L482C50-L482C81

Cette fonction filter_other_filters doit surement être utilisée à plusieurs niveau, de fait changer l_areas_cte.c.geom en l_areas_cte.c.geom_4326 risque de faire planter d'autres requêtes, c'est donc plutôt self.geom_column qui n'est pas la bonne transmise. Je laisse le/les développeurs à l'origine de cette fonction corriger le truc.

Pour le second point je dois plus comprendre la requête pour proposer une solution. -_-

[jbrieuclp]

Ok, le changement du geom_column ici résout aussi le premier problème :

GeoNature/backend/geonature/core/gn_synthese/utils/blurring.py

Line 110 in e0790c6

geom_column=LAreas.geom_4326,

En changeant de cette manière : geom_column=LAreas.geom

[jbrieuclp]

Autre truc bizarre : pour une données communale (qui a un polygone correspondant à la limite de la commune) ma donnée étant considérée comme sensible elle doit ressortir en maille 10km. La requête générée par sqlalchemy exécutée sous postgres me retourne 4 mailles 10km qui correspondent aux mailles qui intersectent la commune. C'est ok.
Seulement je n'ai qu'une maille transmise par l'API et donc qu'une maille affichée sur la synthèse ????

[bouttier]

Je suis d’accord qu’il serait plus performant de ré-écrire le filtre d’area avec un exists plutôt qu’un join afin d’éviter de retourner plusieurs lignes SQL (bien que dé-dépliqué ensuite par SQLAlchemy).

Quant a l’API qui ne renvoi qu’une maille, en effet ce n’est pas normal … j’essayerai de reproduire.