feat(pipeline) : Ensure the zone_diffusion_codes for DROM/COM

[vperron]

There were cases where we did have the zone_diffusion_code set to "97" which can't be right, as it would mean that a given service coyuld be available across the oceans.

Let's fix it and set the correct, 3-digit department number.

This will also enable their search as we now (since the "new" communes) search for a match agains commune.departement, which can be 3 digits.

I would love to add a data test for this, but not sure how useful that is. So far, CHECK_SERVICE_ERRORS() is only semantic but does not validate for instance that the zone_diffusion_code is a correct department number if the zone_diffusion_type is "department", and so on.

If we wanted to validate this, what should be the correct way to proceed?

[vperron]

NDA : Je le nomme comme ça car dans ce bloc, on s'attache à appliquer les codes et noms des zones de diffusion SUITE au geocoding (on considère qu'à cette étape, les codes INSEE sont mieux résolus et par conséquent que les zones de diffusion seront plus précises en les appliquant à partir des codes INSEE post-geocoding)

[vperron]

Vu avec @vmttn :

• ajouter un unit test pour vérifier la logique du code (en particulier passage par les différentes étapes de setting des ZD, etc)
• ajouter un data test séparé qui vérifie (cf https://docs.getdbt.com/reference/resource-configs/where) que dans le cas de tel ou tel type zone de diffusion, on a bien des codes qui correspondent à une valeur correcte d'EPCI, commune, departement, region...

[vmttn]

+1 pour les tests à venir :)

[vperron]

Etude d'impact statistique:

• on passe de 138 lignes (action logement) avec un code de ZD à 97, à 0 lignes: elles ont maintenant un véritable code et nom de département.

• on a un changement des choses en ce qui concerne les départements dans les DOM/TOM:

  • les noms des départements et communes sont canoniques et non plus exotiques
  • lorsque les services ont une géoloc mauvaise, leur ZD devient mauvaise
    ==> Cela ne concernant que l'ODSPEP, on décide de sortir ODSPEP de ce traitement.

• Meme constat pour les ZD "vides" alors que elles ont un type de ZD "commune" ou "departement" : on ne "corrige" que pour une trentaine de lignes sur les ~12000 concernées par une ZD vide.
  ==> On ne peut pas "corriger" car les adresses en question n'ont en fait pas de code INSEE, même post-géocodage. Le vrai traitement est:

• retenter le géocodage jusqu'a ce qu'un code INSEE se montre

• en attendant potentiellement proposer de retirer les records qui ont un type de ZD mais pas de valeur associée

[vperron]

Vu avec @vmttn , on fait une exception pour ODSPEP et on fera un ticket supplémentaire plus tard pour rationaliser encore nos données d'adresse : mettre à 0 celles qui sont "mal" géocodées (en-dessous de 0.8)