Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tenir compte des geométries en polygone dans syntheseff et vm_observations #409

Open
gildeluermoz opened this issue Apr 20, 2022 · 2 comments
Labels

Comments

@gildeluermoz
Copy link
Contributor

Lorsque la géométrie d'une observation n'est pas un point (ligne ou polygone/maille), celle-ci peut intersecter 2 communes ou plus.
Actuellement le parti pris retenu dans la vue synthese.syntheseff qui permet de construire la vm_observations est de retenir le centroïd de la géométrie de l'observation. De cette manière, on est certain que la géométrie de l'observation n'intersectera qu'une seule commune. En cascade, la vm_observations ne comporte pas de doublon et on peut construire un UNIQUE INDEX sur le champ id_observation.
Par contre, on attribue cette observation de manière aléatoire à la commune qui intersecte le centroîd de la géométrie. Ce qui n'est pas tout à fait juste puisqu'on ignore si le polygone est

  • une imprécision de la localisation (cas des observations par mailles)
  • un floutage volontaire de la localisation (espèces sensibles et dans ce cas le polygone peut être grand)
  • une surface où l'espèce est considérée comme partout présente

Dans tous ces cas, le centroïd est un positionnement aléatoire de l'observation.
On pourrait donc aussi choisir d'attribuer l'observation à toutes les communes intersectées. Selon le cas, parmi les 3 ci-dessus, ce serait soit juste, soit conforme à l'imprécision ou au floutage (on ne sait a priori pas où l'observation a été faite).

3 options
1 - on laisse comme ça et on accepte l'interprétation de la localisation des observations avec geom en polygone.
2 - on n'utilise plus le centroïd mais le geom d'origine pour calculer synthese.syntheseff et il y aura des doublons dans la vm_observations. En cascade, il faut modifier le code pour faire des COUNT(DISTINCT id_observation) afin que le nombre d'observations soit exacts. Voir faire une table de correspondance entre vm_observations et les communes.
3 - on laisse comme ça mais on exclue les observations trop imprécises (surface du geom supérieure à un certain seuil). On accepte alors l'imprécision pour les petits polygones.

A noter que l'option 2 pose un soucis de réprésentation puisqu'en cas d'affichage de l'observation sous forme de point, le point (centroïd du polygone) tombera parfois à coté de la commune. Dans la fiche commune, ça fait un peu désordre ! Il est possible de contourner ça en découpant le polygone selon l'intersect avec les comunes et calculer un centroïd de l'obs pour chacune des communes. Mais bonjour la requête, le calcul et les perfs !

Pas de solution idéale mais je suis preneur de l'avis de la communauté sur le sujet afin d'assumer un choix qui s'impose à tous.

cf aussi : #379

@jpm-cbna
Copy link
Contributor

Concernant les performances, avec les PR #397 et #402, le temps de génération des VM de l'Atlas pour 12 millions d'observations dans la Synthese est réduit à 12mn.

La PR #397 modifie la vue synthese.syntheseff pour améliorer les performances et aussi prendre en compte le floutage vis à vis des nomenclature diffusion_level et sensitivity. Elle se base sur le centroïde des communes, mailles 10x10 ou départements. Du coup, effectivement, certaines communes se retrouvent avec toutes les observations "floutées"...

@camillemonchicourt proposait de ne pas faire ainsi mais plutôt de dispatcher l'observation floutée dans toutes les communes correspondant au territoire de floutage... Du coup, cela correspond à ta solution 2. Cette solution à mon avis nécessite surement de revoir le fonctionnement de l'Atlas. Il faudrait aussi idéalement pouvoir mentionner que l'observation est présente dans la commune suite à un floutage...
Cela me semble la meilleure solution mais elle est beaucoup plus lourde en terme de développement.

@camillemonchicourt
Copy link
Member

Concernant le calcul des communes, je prendrai une 4° option, extension de l'option 2, mais plus juste et propre niveau BDD il me semble :
J'utiliserai la géométrie source de l'observation et je créerai une table n-n pour lister les communes des observations.
Ainsi on ne doublonne pas les observations dans vm_observations car cela pourrait apporter de la confusion, mais on a bien toutes les communes d'une observation à cheval sur plusieurs communes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants