ban-data
ban-data copied to clipboard
etalab
Bon sang ! SEN ne signifie pas forcément SENTIER !
La ville de 76 Saint Léger du Bourg Denis a nommé plusieurs voies "sente ..." et les données BAN proposent systématiquement "Sentier ...."
C'est un vrai problème pour les secours que cette faiblesse majeure du référentiel !
https://github.com/etalab/ban-data/blob/0fe565418fbdc5490441b9d22c5a410979b11fd9/scripts/clean.sql#L137
La désabréviation ne peut pas être faite dans tous les cas en utilisant /data/abbreviations.csv, car il y a plusieurs chaine avec la même abréviation.
Et pareil au Houlme ! SENTE DEVEAUX 76770 LE HOULME => BAN DIT "SENTIER DEVEAUX"
https://github.com/etalab/ban-data/blob/0fe565418fbdc5490441b9d22c5a410979b11fd9/scripts/clean.sql#L137 calcule la version abrégée, elle ne fait pas de désabréviation.
C'est bien 'SENTE' dans les données Poste.
Sur le seul département 76, il y a 3203 incohérences entre nom_voie et nom_afnor sur la livraison du 22/1/2017.
Problème identique en "EN" désabrégé systématiquement en "ENCEINTE": https://github.com/etalab/ban-data/issues/17
Cela provient d'une désabréviation automatique qui est difficile, comme le précise @frodrigo . Travaillant sur d'autres points d'amélioration, la mise en place de la nouvelle base et des processus correspondant, nous laissons le soin aux utilisateurs du Guichet Adresse de trancher entre le nom_afnor et le nom_voie, l'ordinateur ne connaissant pas la vérité terrain. Je précise que le nom_afnor est le nom de la voie selon les normes afnor. une erreur peut cependant y être présente.
En attendant une remise au propre au cas par cas qui prendre des années, La Poste a des libellés non abrégés qu'il faudrait utiliser pour lever l'ambiguité plutôt que de conserver une désabréviation automatique qu'on sait problématique. Exploitons toutes les données à notre disposition.
La chaine de livraison IGN vient d'être améliorée pour désabréger correctement les cas ambigus en s'aidant du nom afnor (origine La Poste)
