Skip to main content
Solved

Comment créer un ChangeDetector avec tolérance ?


Bonjour,

 

dans le cadre d'un processus de mise à jour je suis amené à comparer les modifications faites sur un ensemble de point entre deux moments donnés. J'utilise par conséquent un Transformer ChangeDetector pour obtenir les points n'ayant pas changés DU TOUT. Cependant il existe aussi des points bougeant PEU mais de manière suffisante pour que le ChangeDetector les considère comme différents. Pour palier à ca, existe-t-il un moyen d'integrer une tolérance de distance pour qu'un transformer ChangeDetector puisse faire passer dans le flux unchanged les points revised étant suffisament proche d'un original ?

 

Actuellement, j'utilise un NeighborFinder sur les flux Added et Deleted, pour creer ce mechanisme à la main, mais cette solution a trouvé sa limite lorsque deux points Base sont proche du meme Candidate, j'obtient alors des incohérences de résultat.

 

 

 

Best answer by david_r

Bonjour

 

 

Vous pouvez essayer de mettre un AnchoredSnapper avant le Matcher, avec un Group By sur le même identifiant que vous utilisez dans le Matcher. Je propose d'envoyer les données mise à jour sur le port Anchor, et les anciennes données sur Candidates. Ceci pour éviter de changer la géométrie des nouvelles données. La tolérance saisie dans l'AnchoredSnapper va décider si le Matcher détecte un changement ou pas.

 

 

David
View original
Did this help you find an answer to your question?
This post is closed to further activity.
It may be a question with a best answer, an implemented idea, or just a post needing no comment.
If you have a follow-up or related question, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.

8 replies

mark2atsafe
Safer
Forum|alt.badge.img+44
  • Safer
  • November 4, 2015
Maybe the two sets of data have different precision? Try the AttributeRounder transformer.

 


david_r
Celebrity
  • Best Answer
  • November 4, 2015
Bonjour

 

 

Vous pouvez essayer de mettre un AnchoredSnapper avant le Matcher, avec un Group By sur le même identifiant que vous utilisez dans le Matcher. Je propose d'envoyer les données mise à jour sur le port Anchor, et les anciennes données sur Candidates. Ceci pour éviter de changer la géométrie des nouvelles données. La tolérance saisie dans l'AnchoredSnapper va décider si le Matcher détecte un changement ou pas.

 

 

David

david_r wrote:
Bonjour

 

 

Vous pouvez essayer de mettre un AnchoredSnapper avant le Matcher, avec un Group By sur le même identifiant que vous utilisez dans le Matcher. Je propose d'envoyer les données mise à jour sur le port Anchor, et les anciennes données sur Candidates. Ceci pour éviter de changer la géométrie des nouvelles données. La tolérance saisie dans l'AnchoredSnapper va décider si le Matcher détecte un changement ou pas.

 

 

David

Je vais essayer cette methode dès mon retour au bureau, cependant etes vous sur que l'anchoredSnapper n'associe à chaque Candidate qu'un seul Anchor ?


david_r
Celebrity
  • November 5, 2015
jeanrochsales wrote:

Je vais essayer cette methode dès mon retour au bureau, cependant etes vous sur que l'anchoredSnapper n'associe à chaque Candidate qu'un seul Anchor ?

C'est l'attribut spécifié dans le Group By du AnchoredSnapper qui va assurer cela, donc bien choisir la bonne clé primaire qui les associent.


david_r wrote:

C'est l'attribut spécifié dans le Group By du AnchoredSnapper qui va assurer cela, donc bien choisir la bonne clé primaire qui les associent.

Donc voici mon schema actuel, si je vous ai bien suivi:

Ce qui sous entends que j'ai 269 objets qui sont proches, mais pas identiques entre mes deux sources (mais je dois les faire passer comme objets similaires), et 7124 qui sont soit identiques, soit trop loins. Parmis ces 7124 j'en ai donc 6639 qui sont identique exactement (ajouté au 269 qui sont approximatif j'obtiens donc 6908 objets "stables"), et 485 qui sont créés entre mes deux instants.

Au final, 6639+269+485 = 7393, le compte est bon, on passe aux lettres.

Cette methode vous semble-t-elle cohérente ? J'entends par la que si je compare mes résultats avec la fonction d'appariement d'OpenJump, j'ai un resultat legerement différent (a 1 ou 2 objets pret), surement lié au fait que le changedetector accepte les points ayant une distance égale a X alors que OpenJump ne prends que le spoints ayant une distance strictement inférieure à X.

EDIT: Je viens de comprendre que vous vouliez utiliser un matcher a la place d'un changedetector, ce que je comprends, mais je ne suis deja pas tres à l'aise avec les transformers que je connais, nul besoin d'aller plus loin


david_r wrote:
Bonjour

 

 

Vous pouvez essayer de mettre un AnchoredSnapper avant le Matcher, avec un Group By sur le même identifiant que vous utilisez dans le Matcher. Je propose d'envoyer les données mise à jour sur le port Anchor, et les anciennes données sur Candidates. Ceci pour éviter de changer la géométrie des nouvelles données. La tolérance saisie dans l'AnchoredSnapper va décider si le Matcher détecte un changement ou pas.

 

 

David

Je post un screenshot de la solution mise en place, merci à david_r pour son aide inestimable ! Je vais construire un autel a son honneur dans mon bureau.

fin.png


david_r
Celebrity
  • November 5, 2015
jeanrochsales wrote:

Donc voici mon schema actuel, si je vous ai bien suivi:

Ce qui sous entends que j'ai 269 objets qui sont proches, mais pas identiques entre mes deux sources (mais je dois les faire passer comme objets similaires), et 7124 qui sont soit identiques, soit trop loins. Parmis ces 7124 j'en ai donc 6639 qui sont identique exactement (ajouté au 269 qui sont approximatif j'obtiens donc 6908 objets "stables"), et 485 qui sont créés entre mes deux instants.

Au final, 6639+269+485 = 7393, le compte est bon, on passe aux lettres.

Cette methode vous semble-t-elle cohérente ? J'entends par la que si je compare mes résultats avec la fonction d'appariement d'OpenJump, j'ai un resultat legerement différent (a 1 ou 2 objets pret), surement lié au fait que le changedetector accepte les points ayant une distance égale a X alors que OpenJump ne prends que le spoints ayant une distance strictement inférieure à X.

EDIT: Je viens de comprendre que vous vouliez utiliser un matcher a la place d'un changedetector, ce que je comprends, mais je ne suis deja pas tres à l'aise avec les transformers que je connais, nul besoin d'aller plus loin

Mon seul commentaire est que nous n'avez probablement pas besoin de mettre un Matcher ET encore un ChangeDetector, je pense que l'un ou l'autre devrait suffir.

Donc tous les objets sortant du AnchoredSnapper sont à traiter du même manière


david_r
Celebrity
  • November 5, 2015
jeanrochsales wrote:

Je post un screenshot de la solution mise en place, merci à david_r pour son aide inestimable ! Je vais construire un autel a son honneur dans mon bureau.

fin.png

Ahah, avec plaisir :-)


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings