Open PNPyrenees opened 2 years ago
J'ai le même problème depuis qu'on a mis en place la sensibilité sur l'atlas..
Par contre le fait d'enlever l'index unique ne permet plus de rafraîchir les vue de manière "concurrente", ce qui est censé ne pas bloquer les autres requêtes durant le rafraîchissement https://www.postgresql.org/docs/current/sql-refreshmaterializedview.html
J'ai essayé d'enlever le CONCURRENTLY
dans la fonction de rafraîchissement, et ça ne pose de problème d'accès à la vue. L'appli continue à très bien fonctionner
J'ai aussi essayer cette requête pour limiter le nombre d'insersection à une, mais la requête met 14h...
create materialized view atlas.test as (
select
obs.cd_ref,
obs.id_observation,
m.id_maille,
m.geojson_maille,
date_part('year'::text, obs.dateobs) AS annee
from atlas.vm_observations obs
join lateral (
select *
from atlas.t_mailles_territoire tmt
where st_intersects(obs.the_geom_point, tmt.the_geom)
limit 1
)m on true
)
Preneur de retour sur ce sujet
En phase de test de monté en version de GeoNature-Atlas, je constate que sur les fiches espèces il y a une anomalie dans l'affichage des points d'observation pour les espèces ayant plus de 500 observations renseignées dans atlas.vm_observations.
En regardant la console, la route /atlas/api/observationsMailleAndPoint/XXX (XXX étant le cd_ref) récupère bien toutes les observations mais elles ne sont pas restituées sur la carto.
Je suis alors passé en affichage par maille mais attention : La table vm_observations_mailles était vide et ne pouvait pas être rafraichi à cause des données devant être floutées à la maille de 10km. En effet, l'objet géographique d'origine devant être remplacé par le centroïde de la maille de 10km fait qu'on tombe exactement à l'intersection de 4 maille de 1 km ce qui générant des doublons non compatible avec l'index atlas.vm_observations_maille_id_observation_idx tel que définit par défaut. Comme alternative, j'ai modifié la déclaration de cet index en retirant la condition UNIQUE :