-
Notifications
You must be signed in to change notification settings - Fork 46
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
Comments
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 @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... |
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 : |
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: