Closed CelestinHuet closed 6 months ago
Je ne comprend pas les explications, j'ai l'impression que cela part du principe qu'il ne peut y avoir des mises à jour que de façon descendantes, si oui pourquoi? Si, non, qu'ai-je mal compris?
Je ne comprend pas les explications, j'ai l'impression que cela part du principe qu'il ne peut y avoir des mises à jour que de façon descendantes, si oui pourquoi? Si, non, qu'ai-je mal compris?
On en discutera tout à l'heure mais tu entends quoi exactement pas le terme mises-à-jour descendantes ? Le fait que la propagation ne se fait que de manière descendante (d'un niveau de segmentation parent/grossier à un fils/plus résolu) et pas de manière ascendante (si tous les segments fils d'un même segment parent sons d'une classe, le segment parent doit changer de classe) ? Si c'est ça, je ne sais pas si c'est très intéressant de l'avoir car je pense que le nombre de cas où on aurait besoin de cette fonction ne justifie pas le dev et les traitements à faire à chaque saisie (avec l'index spatial ça ne devrait j'espère pas être trop lourd).
En réunion le 20/02, il a donc été décidé d'implémenter une propagation de type "ecrase same".
Il est également nécessaire de rajouter une suppression des parents ayant des fils de classes différentes. Il a été décidé d'afficher que la couche sémantique la plus fine mais de permettre de naviguer dans la pyramide des segments (que les contours).
Enfin il faudra modifier la visualisation des segments non annotés à une des deux dates : remplacer la bordure rouge par un hachurage rouge (ou autre symbologie permettant de gérer la couche la plus basse).
Je viens d'ajouter l'écrase same et la suppression des parents ayant des fils de classes différentes. Je veux bien que vous regardiez si c'est le comportement attendu. J'ai un peu beaucoup changé la manière de faire la propagation, donc vous pouvez aussi contrôler le delete all et le delete current. J'ajouterai ensuite la visualisation (ce sera plus difficile de vérifier le comportement de la propagation avec la visualisation)
Bon, il y a encore un cas où ça ne marche pas...
Ce devrait être corrigé, avec en prime une optimisation du temps de calcul (mais en contrepartie un temps d'initialisation un peu plus long que précédemment)
c'est tout de même mieux sans processing ;)
Lors de la propagation, il y a une superposition de la couleur à chaque couche de la pyramide de segmentation non ? Ce n'est pas ce que l'on souhaiterait non ? Il avait été question de n'afficher la couleur de la classe sémantique qu'à la dernière couche mais de pouvoir naviger dans la pyramide quand même.
J'ai l'impression que sur les bordures des dalles, il y a deux segments identiques qui se superposent... D'où cette impression de superposition. Une erreur lors de la division des segments qui intersectent une limite de dalles ?
La branche prop_visualisation contient maintenant la propagation et la visualisation. Cela sera le rendu final
La visualisation n'a pas l'air de se mettre à jour avant un déplacement de la carte sur la deuxième carte (celle de MAJ). La mise à jour se fait correctement si on annote sur le millésime M2 et pas sur le M1.
J'ai l'impression que sur les bordures des dalles, il y a deux segments identiques qui se superposent... D'où cette impression de superposition. Une erreur lors de la division des segments qui intersectent une limite de dalles ?
Effectivement il y a un doublons des segments. Il est déjà présent dans les données segmentées donc le soucis viens plutôt de là. Par contre je rejoins Nicolas, on avait parlé d'afficher uniquement la frontière/le train des segmentations et qu'on affichait la classe sémantique de la dernière couche. Dans l'idée on pourrait faire ainsi :
Ok, pour la mise à jour lors du déplacement, je vais voir ça.
Pour l'affichage, as-tu regardé la branche prop_visualisation ? J'ai séparé en deux branches :
Ok, pour la mise à jour lors du déplacement, je vais voir ça.
Pour l'affichage, as-tu regardé la branche prop_visualisation ? J'ai séparé en deux branches :
- propagation : le mécanisme de propagation ascendant et descendant
- prop_visualisation : la branche propagation, mais avec en plus la visualisation demandée. J'ai laissé deux branches différentes, sinon c'est très compliqué de contrôler la partie propagation
Ah oui je n'avais que regarder la branche propagation. Je regarde la prop_visualisation.
Ok c'est bon chez moi pour la visu et la propagation. Pour la mise à jour lors du déplacement c'est bon aussi d'ailleurs 👍 Pour la visu, je suggère juste de peut-être que l'alignement des lignes se fasse à partir de la carte et pas de l'entité car ça fait des rendu un peu perturbant je trouve. C'est juste un truc à changer dans la définition de la symbo. Exemple dans l'état actuel : Ce que ça donne avec un alignement sur la carte PS : Ne vous fiez pas aux labels que je donne surtout 😆
En effet, c'est plus propre. C'est corrigé sur la branche prop_visualisation !
Salut,
Sous réserve que la mise en évidence des segments non labellisés soit celle de prop_visualisation (hachure au niveau de la dernière couche avec référentiel carte) et non celle de cette branche (contours rouges + problème si les enfants ne sont pas du même type que le parent) :
On valide le merge tout à l'heure.
D'accord, on pourra en discuter à la réunion de mardi prochain !