Synthese - Regroupement d'observations par mailles

Afin de clarifier l'affichage de la répartition des observations sur la carte à petite échelle lorsqu'une recherche est lancée dans le module SYNTHESE, je peux voir les observations correspondant à ma recherche affichées à petite échelle sur la carte regroupé par maille.

Ces mailles doivent être colorées en fonction du nombre d'observations qu'elles contiennent.

Une légende doit pouvoir être affiché afin d'indiquer les intervalles d'observations correspondant à chaque couleur.

• Renvoyer les observations groupées par géométrie et non de façon distincte comme aujourd'hui.
• L'interface graphique doit passer le niveau de zoom à l'API afin d'activer/désactiver ce groupement par maille.
• L'activation de cette fonctionnalité doit être configurable.
• Le type de maille utilisé pour le regroupement doit être configurable.
• Le niveau de zoom au delà duquel le regroupement cesse doit être configurable.
• Les valeurs min et max des classes de nombres d'observation et leurs couleurs devront être à minima configurable.
  • Les classes de nombres d'observations pourront éventuellement être calculé automatiquement. Il faut voir si la classification doit rester fixe quelque soit la recherche (⇒ configuration) ou être dynamique (⇒ classification calculée). Dans ce dernier cas, il faudra définir le type de classification à utiliser (voir ressources).

• La limite des 100 000 données ne peut être levée car il faudrait changer tout le fonctionnement actuel de la Synthese. En effet, la carte à afficher quand la recherche se fait sans filtre demanderait de renvoyer les 9 millions d'observations au navigateur. Ce qui n'est pas envisageable… Afin de réaliser ceci, il est nécessaire de paginer côté serveur la liste des observations et d'afficher dans la liste seulement les observations visible sur la carte. Cela demande des modifications trop importantes.
  • Solutions :
    • maintenir la limite et indiquer via un texte dans la fenêtre d'information qui s'affiche que la coloration ne tient pas compte de toutes les données…
    • ne renvoyer que les données visible à l'écran en passant à l'API une bbox (M10 ou M5) via les paramètres de recherche géographique.
• Pour les observations sensibles ou avec niveau de diffusion, il faudrait pouvoir récupérer le centroïde de la géométrie correspondant au floutage demandé pour ces observations. Cela pose problème car cela réduire les performances. Cela demande d’exécuter la requête de floutage puis d'associer ces observations aux mailles correspondant au centroïde de la géométrie floutée…
  • Solution :
    • en mode regroupement par maille, l'interface n'afficherait pas le panneau listant les observations sous forme de tableau paginé. Le web service ne renverrait que le nombre d'observations contenues dans chaque maille. Ainsi pas de nécessité de flouter les observations ! ⇒ Mais finalement cela pose quand même problème si l'on effectue une recherche sur un taxon seulement. Si celui-ci est sensible et flouté au département, il apparaitra avec des mailles plus précise… Il faudrait donc pouvoir éliminer les observations dont le niveau de floutage correspond à une zone géographique moins précise que les mailles utilisées pour le regroupement. Dans ce cas là, nous pouvons maintenir le panneau latéral listant les observations mais le supprimer pourrait accélérer l'affichage car moins de données sont à récupérer.

• Création d'une carte choroplèthe avec Leaflet
• Outil en ligne d'aide au choix des couleurs pour une carte
• Différents types de classification pour les données à afficher sur une carte choroplèthe

SELECT la.area_code, COUNT(s.id_synthese) AS nbr
FROM gn_synthese.synthese AS s
	JOIN gn_synthese.cor_area_synthese AS cas ON (s.id_synthese = cas.id_synthese)
	JOIN ref_geo.l_areas AS la ON (cas.id_area = la.id_area)
WHERE la.id_type = ref_geo.get_id_area_type_by_code('M10')
GROUP BY la.id_area 
LIMIT 100000 ;

Résultats (en local) :

• Pour une maille M10 ou M5, le temps semble similaire entre 11s et 15s.
• Sans la limite à 100 000 données le temps de calcul est de ~12s.

SELECT
	s.id_synthese,
	s.date_min,
	s.lb_nom,
	s.cd_nom,
	s.nom_vern,
	s.st_asgeojson,
	s.observers,
	s.dataset_name,
	s.url_source,
	s.entity_source_pk_value,
	s.unique_id_sinp,
	s.id_nomenclature_sensitivity,
	s.id_nomenclature_diffusion_level,
	la.area_code,
	la.geojson_4326 
FROM gn_synthese.v_synthese_for_web_app AS s
	JOIN gn_synthese.cor_area_synthese AS cas ON (s.id_synthese = cas.id_synthese)
	JOIN ref_geo.l_areas AS la ON (cas.id_area = la.id_area)
WHERE la.id_type = ref_geo.get_id_area_type_by_code('M10')
ORDER BY s.date_min DESC ;

Résultats (en local) :

• Sans limite pour toute la base : 1mn 36s
• Avec la limite à 100000 : 1mn 28s

SELECT 
	s.id_synthese,
	s.date_min,
	s.lb_nom,
	s.cd_nom,
	s.nom_vern,
	s.st_asgeojson,
	s.observers,
	s.dataset_name,
	s.url_source,
	s.entity_source_pk_value,
	s.unique_id_sinp,
	s.id_nomenclature_sensitivity,
	s.id_nomenclature_diffusion_level
FROM gn_synthese.v_synthese_for_web_app AS s
WHERE s.the_geom_4326 IS NOT NULL
	AND ST_Intersects(s.the_geom_4326, ST_GeomFromWKB(ST_AsEWKB('POLYGON ((6.205649 43.299893, 6.205649 43.346541, 6.264669 43.346541, 6.264669 43.299893, 6.205649 43.299893))'::geometry), 4326))
ORDER BY s.date_min DESC ;

Résultats (en local) : ~60ms pour 6400 observations