You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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 lavm_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, lavm_observations
ne comporte pas de doublon et on peut construire unUNIQUE INDEX
sur le champid_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
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 lavm_observations
. En cascade, il faut modifier le code pour faire desCOUNT(DISTINCT id_observation)
afin que le nombre d'observations soit exacts. Voir faire une table de correspondance entrevm_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
The text was updated successfully, but these errors were encountered: