Documentation du workflow

[jalazawa]

Le problème est un peu complexe

Quoi qu'il arrive au sujet de ce point, je propose d'écrire le workflow de travail sans les exemples dans le readme en précisant à chaque étape les données d’entrées et de sortie et les fichiers externes qui ont été utilisés (règles de validation, d'agrégation, de correction).

Je vais prendre cet exemple UK / NIE à "2017-04-27 21:00:00"

Lorsqu'on charge les données initiales, on obtient ça

On constate que les données CTY | UK est plus grande que les deux autres et c'est normal.

Car d'après les règles "cty_rules", la valeur de UK doit contenir CTA|NORTH_IRELAND

UK:
CTY:
- GB
- "CTA|NORTH_IRELAND"
CTA:
- GB
BZN:
- GB

Mais voilà ce qui se passe quand on appel la fonction aggregate_with_rules

On obtient ce tableau

Ici, on a rajouté la donnée "CTA|NORTH_IRELAND" à la donnée CTY|GB.

PB la donnée CTY|GB contenait déjà la donnée "CTA|NORTH_IRELAND".

Au moment de la validation de la donnée, on a de nouvelles surprises

La règle d'égalité entre CTY|GB et CTA|GB devrait être égal à TRUE et ici cette règle est FALSE.

Le fait que ce test soit égal à FALSE implique que lors de la correction des données automatiques, la donnée CTY est corrigée.

Je pense que la règle qui corrige cette donnée est la suivante :

replace: CTY
  use: CTA
  country:
  when_false:
    - CTY_NA
    - CTY_CTA_EQUAL
    - CTY_CTA_DIFF_LT_05
    - CTY_CTA_DIFF_LT_10
    - CTY_BZN_EQUAL
    - CTY_BZN_DIFF_LT_05
    - CTY_BZN_DIFF_LT_10
  when_true:
    - BZN_NA
    - CTA_NA
    - CTA_IS_POS
    - BZN_IS_POS
    - CTA_BZN_EQUAL

Le comportement des fonctions d'agrégations et de correction est encore à travailler.

Je ne sais si c'est une solution, mais il faut peut-être faire un fichier avec des règles d'agrégation et un fichier différent pour la validation.

Pour revenir au point initial, il est primordiale d'écrire le workflow de travail quelque part.