Si on garde la clé c'est pour qu'elle soit vérifiable (et l'algo de calcul est simplissime) et éviter les erreurs de saisie "à la volée". Ce qui aurait mérité alors de garder le code division (là où il est encore utile et non nul, donc pas dans les départements 75, 92, 59 et 13) : la validation de la clé est alors immédiate et on repère immédiatement les inversions de chiffres. Là on se contente juste d'un test de longueur, et d'un controle à posteriori via le rapprochement BANO-OSM d'Osmose (ce qui n'aide pas du tout les premiers contributeurs).
Ce serait donc bien de promouvoir ce contrôle à priori (dès la saisie ou dans le validateur de données avant l'envoi à OSM) et non à posteriori (d'autant qu'il y a encore des tas de lieux à référencer et rapprocher de façon plus intelligente qu'un simple rapprochement de nom qui est bourré de pièges). Ces références FANTOIR pourtant accélèrent considérablement à mon avis les rapprochements et lèvent pas mal d'ambiguités, et fonctionnent encore pour détecter les changements de noms et les expliquer. Peut-être qu'on pourrait s'en sortir en délimitant les zones de direction dans les 4 départements concernés, afin que la validation puisse déduire le code manquant pour valider la clé. pour les autres départements on sait que le code direction est 0, donc la validation est possible et à mon avis il reste alors recommandé de garder la lettre clé finale dans les données OSM. C'est une solution simple: 4 zones à créer pour Paris, 2 zones pour chacun des 3 départements (à priori des communes entières, sauf si depuis des communes ont fusionné entre deux zones à cheval, sans forcément changer les codes FANTOIR qui risquent fort d'attendre encore 1 an ou plus avec leur ancien code commune et leur ancien code direction). Cela permettrait ensuite de faire le point avec la DGFIP pour que finalement elle voit que les codes direction ne sont plus nécessaires et peuvent être unifiés à "0" sans avoir même besoin de le préciser, quitte à changer les lettres clés dans les 4 départements pour tenir compte du changement implicite de code direction à 0, puis finalement même retirer ce code direction obsolète du fichier FANTOIR de la DGFIP. Et tant qu'à faire ce changement pour les 4 départements, rationaliser à nouveau la typologie (les codes voie à 4 chiffres peuvent tous passer à 1 lettre plus 3 chiffres, puisque toutes les lettres ne sont pas utilisées). LE code final en serait plus lisible sous la forme générale: 5 chiffres (code commune)+1 lettre de type+3 chiffres (rang dans le type)+lettre clé calculée sur les 9 premiers caractères (sans besoin de changer l'algo de calcul qui reste simple: une substitution des lettres par un chiffres puis un calcul similaire au LUHN, et un modulo mappé sur une lettre finale). Ou bien tout en gardant 10 caractères, passer à un code avec 5 chiffres (code commune)+2 lettres (type+sous-collection du type sans le 0, le I et le L pour éviter la confusion avec les chiffres en ignorant la casse non significative) +2 chiffres (rang dans le type+collection)+lettre clé (avec un nouvel algo possible: une simple somme des chiffres, pondérés chacun par plusieurs facteurs distincts 1,2,3,5,7,11,13,17,19 en fonction de leur rang, puis un modulo égal à un autre nombre premier comme 23, conduisant à mapper une clé d'une lettre parmi 23, sans le I et le O). Le sous-code "collection" peut être utilisé pour les transitions millésimées dues aux fusions/scissions de communes (on a le choix parmi les 23x23 lettres, quand actuellement on n'utilise que les chiffres 00 à 99 et souvent beaucoup moins, et 1 lettre parmi 3 suivi d'un chiffre parmi 9). Au pire, on définit ça comme notre nouveau "code FANTOIR-OSM" remplaçant le "code FANTOIR-RIVOLI" historique et capable aussi de représenter d'autres champs du FANTOIR (exemple: public contre privé, provisoire/chantier/projet/voie déclassée ou fermée mais qui pourrait être reclassée à l'avenir). Et ce nouveau code n'a pas non plus obligation à n'être que pour les communes si la compétence échoie à une agglomération ou un département (dans ce cas on peut jouer sur les 5 premiers chiffres ou lettres), ou à un grand gestionnaire foncier privé ou para-public (exemple: agences de bassin, parcs naturels, portuaires/aéro-portuaire, armée, forêts, zones internationales...) Le lun. 16 déc. 2019 à 13:08, Vincent de Château-Thierry <osm.v...@free.fr> a écrit : > > > De: "Yves P." <yves.prat...@gmail.com> > > > Concernant la clé de contrôle, est-ce nécessaire de la garder sachant > > qu’il peut manquer le code div pour la recalculer ? > > Si j’ai bien compris, tu as la base DGFiP complète sur un serveur et > > un outil de contrôle qualité qui peut vérifier la cohérence entre > > ref:FR:FANTOIR et les données brutes « FANTOIR ». > > Du coup elle devient inutile ? > > Oui, le fichier FANTOIR est pris ici : > > https://www.data.gouv.fr/fr/datasets/fichier-fantoir-des-voies-et-lieux-dits/ > et fait partie intégrante du processus BANO, car cette longue liste est > (sur le papier) la plus exhaustive pour nous permettre de comparer le > contenu d'OSM. C'est un peu la clé de voûte de BANO ce fichier. > > Concernant le format du ref:FR:FANTOIR, on peut s'interroger sur la > pertinence du format à 10 positions, mais je ne vois pas ce qu'apporterait > maintenant d'enlever la clé de contrôle, pour passer à un code sur 9 > positions. Ca occasionnerait un gros chantier de mise à jour OSM, ça > casserait momentanément tous les outils développés autour de BANO. Et, > cerise sur le gâteau, ça casserait l'interopérabilité vis-à-vis des autres > bases de données qui s'appuient sur la même structure de clé, comme l'a > rappelé Christian. Bilan : beaucoup d'inconvénients et 0 valeur ajoutée. Je > disais la même chose pour ne pas inclure le code Direction, les arguments > sont les mêmes ici. > > Après, on peut s'amuser, pour la gymnastique intellectuelle, à trouver le > bon algo pour calculer la clé, etc. Mais dans notre contexte je ne vois pas > ce que ça apportera concrètement à OSM, dès lors que, plus que le respect > d'un algo, on cherche à respecter une intégrité référentielle vis-à-vis > d'un fichier public qui fait autorité. > > vincent > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
