Bonjour
La livraison FANTOIR de janvier 2023 est désormais incluse dans BANO (et donc utilisée par Pifomètre).
Pourquoi annoncer celle là particulièrement ? Parce que c’est la dernière. En effet, le fichier FANTOIR cède la place à d’autres fichiers dont TOPO, qui sera pour nous son remplaçant. Un peu de détail sur cette page de data.gouv.fr.
Le fichier TOPO nous fournit quasiment la même information que FANTOIR. On garde le détail par commune des noms de voies et lieux-dits, les dates de création et d’annulation.
Un changement cependant : le « code FANTOIR » que l’on manipule dans OSM sur 10 caractères ne sera plus fournit que sur 9. Le dernier caractère (la clé de contrôle) n’est plus fourni, et un des constituants du calcul de cette clé (le code « direction ») n’est plus fourni non non plus.
On retrouve ce code dans quasi 500.000 objets d’OSM, c’est donc un peu pénible de se dire que du jour au lendemain ce contenu n’est plus raccord avec le fichier de référence qui le diffuse…
Concrètement ce changement va devoir se retrouver
au niveau des outils de QA comme Osmose, où la validité d’un code devra être calculée en considérant les 9 premiers caractères
dans BANO, qui devra considérer le contenu des tags ref:FR:FANTOIR en tronquant au 9ème caractère
dans Pifomètre, qui dans ses propositions d’intégration, devra fournir un code sur 9 caractères et non plus sur 10, et qui devra n’afficher que des codes sur 9.
Côté OSM cela introduit une période mixte, où cohabiteront des codes sur 9 et sur 10 caractères. Je n’imagine pas une opération de mass-edit pour convertir tous les codes à leur version sur 9 caractères, mais c’est l’occasion de lancer la discussion.
Donc techniquement, le tag ref:FR:FANTOIR n’a plus d’utilité que pour garder le vrai code Fantoir historique et gérer la transition.
Du coup, quel tag à la place ? Est-il toujours utile ? J’imagine pour oui pour forcer les rapprochements.
Concernant une édition de masse, je suis pour à condition qu’elle soit annoncée suffisamment à l’avance, qu’on sache qui fait quoi et comment on le fait. Je ne sais pas si beaucoup de personnes se raccrochent à notre Fantoir sur OSM. Mais on tout état de cause, on ne pourra pas garder une clé qui n’a plus d’existence légale ni de support avec une valeur qui n’est plus à jour.
Si la suppression des ref:FR:Fantoir et leur bascule sur une nouvelle clé avec une nouvelle valeur est trop compliquée, peut-on imaginer de dupliquer lé clé vers une clé définie vers un Fantoir à 9 caractères, puis effacer le Fantoir historique bien plus tard ? Est-ce que ca a un intérêt ?
Pour nos outils à nous, tu vois comment la transition ? Facile/pas facile, long/pas long ?
Je rejoins Donat sur la création d’une nouvelle clé (réf:FR:TOPO ou autre plus pertinent), avec bascule automatisée vers le code à 9 caractères. Ça laisse le temps de faire tranquillement la mise à jour des outils et de la documentation. On pourra supprimer l’ancienne clé une fois que l’on se sera assuré que tout fonctionne bien avec la nouvelle.
Je pense qu’il a toute son utilité, qu’une édition de masse n’a pas d’intérêt.
Comme le suggère @vdct les outils QA ne doivent utiliser et rapprocher que les 9 premiers caractères.
La mise à jour de la valeur peut/doit se faire uniquement en cas de changements significatifs sur l’objet.
La règle tag2link si elle existe doit continuer de fonctionner avec ou sans la clé de contrôle.
La clé de contrôle est utile pour une saisie manuelle avec un risque d’erreurs de saisies important.
L’algorithme n’a pas changé, simplement ce caractère n’a plus d’utilité.
interne : permettre à BANO et Pifomètre d’effectuer des rapprochements entre la liste officielle des noms de voies et lieux-dits et les objets nommés dans OSM, quand le nom diverge alors qu’il concerne bien la même entité dans les 2 contextes OSM et DGFiP
externe : FANTOIR est à la base un fichier sans géographie, seuls les codes INSEE permettent de rattacher chaque nom à une commune, ce qui est très approximatif vu qu’on parle de voies et lieux-dits. En ce sens notre tag permet de coller une localisation assez précise à chaque code FANTOIR
J’aime bien l’idée d’un nouveau tag ref:FR:TOPO sur 9 caractères mais je trouve la manip assez overkill vu que les motivations sont moyennement liées à OSM
J’imaginais plutôt un système où ce sont d’abord les outils qui s’adaptent :
BANO, qui ne chercherait à rapprocher qu’avec les 9 1ers caractères de chaque code, et ne lèverait pas d’erreur pour un code à 10 caractères
Pifomètre, qui tronquerait aussi à 9 caractères tous les codes lus, et renseignerait des codes à 9 caractères dans les propositions d’intégration d’adresse
On peut imaginer en parallèle un outil qui, commune par commune, modifie les codes à 10 caractères pour les tronquer à 9. Mais cet outil (je ne dis pas « robot » volontairement) agirait sur de petites zones, et avec un contrôle par les contributeurs. Le passage de 10 à 9 caractères prendrait du temps, pendant lequel il faudrait qu’Osmose tolère les 2 formats de codes
(ping @frodrigo )