Open DonovanMaillard opened 5 years ago
camillemonchicourt
commented
5 years ago De mémoire ce champs n'est pas utilisé dans GN. Il n'a pas cette vocation. Si on l'utilisait, et qu'un zonage était a enable=false alors il devrait être utilisé nul part sinon c pas compréhensible.
Si on voulait ne pas intersecter certains zonages il faudrait mieux mettre un champs clair comme "intersect(true/false)" et le mettre sur bib_type_area plus que sur chaque zonage de l_area
DonovanMaillard
commented
5 years ago OK merci !
TheoLechemia
commented
5 years ago Ce champs pourrait être utilisé pour l'affichage des "aires" dans les listes déroulantes dans les formulaires côté front. Ce n'est pas le cas actuellement.
DonovanMaillard
commented
5 years ago Merci pour ce retour :)
La modif n'étant pas bien grosse à priori et que coté BDD, je teste tout ca sur mon serveur de test et je ferai une PR dans la semaine pour avoir ce paramètre "intersect_synthese" :)
camillemonchicourt
commented
5 years ago Ça complexifie encore la compréhension de la BDD avec encore un champs. C'est discutable. Si on met un zonage dans la BDD c'est pour l'utiliser...
DonovanMaillard
commented
5 years ago Pas forcément l'utiliser pour tout...
Sur une donnée avec un gros polygone ou un grand transect, tu sors une liste de plein de mailles... qui en soit n'est pas dans les exports. Et l'info des mailles n'est pas faite pour des analyses données par données le plus souvent. Ca peut aussi être quelque chose qui est propre à mon instance (dans ce cas j'ai juste à retirer ce type du trigger).
A voir si c'est souhaité par d'autres utilisateurs dans ce cas. Mais je pense qu'on est plus à un champ près dans la base, surtout sur une table bib_type qu'on alimente essentiellement lors de la mise e place et sur laquelle on revient rarement dans un fonctionnement normal à priori :)
DonovanMaillard
commented
5 years ago après discussion avec Camille, ce n'est effectivement pas un probleme de trigger. Les intersections en soit ne sont pas un probleme et sont utiles pour des analyses par exemple, ou le seront quand on voudra des affichages par mailles etc par exemple.
Le problème est simplement que ces types soient affichés dans les modales d'info sur la synthèse. Il serait donc plutôt question de ne pas afficher ces intersections pour certains id_types, définis par l'utilisateur dans son fichier de configuration.
camillemonchicourt
commented
5 years ago Solution retenue : Proposer un parametre permettant d'exclure des types de zonage de l'affichage dans la Synthèse (excluded_id_area_type)
TheoLechemia
commented
5 years ago On affiche les aires intersectées dans un onglet séparé pour ne pas surcharger l'interface de la fiche info synthese: 39150cf22ffdf89ad425e122c2e53c5472c83e21
camillemonchicourt
commented
5 years ago OK bonne solution pour le moment.
Bonjour,
Je pense qu'il n'est pas forcement souhaitable que les intersections de la cor_area_synthese porte sur l'ensemble des objets présents dans la table l_areas. Par exemple j'ai les mailles 1KM, sur une observation à la commune j'ai une liste "Autres espaces concernés par l'observation :" qui devient vite très (troooooop) longue.
Question donc. A quoi sert le champ 'enable' booléen dans la table l_areas du ref_geo? Pour ma part je suis tenté d'ajouter dans le trigger "WHERE a.enable='TRUE'" pour éviter les intersections avec les objets enable=FALSE, et mettre par exemple mes mailles à FALSE. Est-ce quelque chose qui peut avoir des effets indésirables? Ou a l'inverse, est-ce intéressant de le faire directement ici pour tout le monde?