-
Notifications
You must be signed in to change notification settings - Fork 7
DRAFT # Intégration des données de fichiers BAL v1.x au sein de la BAN
- voir Le Schéma de la Base Adresse Locale (BAL).
- Tout objet dit ‘identifiable’ possède un identifiant, dit ‘BanID’
Les fichiers BAL sont la source d'alimentation primaire des adresses BAN.
Les fichiers BAL sont des fichiers CSV qui suivent la structure du Format BAL. Un fichier BAL contient l’ensemble des données d’adresses d’une commune. À chaque soumission de fichier BAL auprès de la BAN, le fichier est traité dans son intégralité.
L’étape de traitement permettant l’enregistrement des données issues de fichiers BAL vers la BAN est appelée ‘étape de digestion’.
Au sein d’un fichier BAL, le fournisseur de données à la possibilité de fournir des identifiants (appelé identifiants BanID) spécifiques à chaque lieu constituant l’adresse. La présence de ces identifiants permet la gestion du cycle de vie des adresses et autres lieux présents dans la BAN.
À l’inverse, en cas d’absence d’identifiant BanID, les lieux seront mis à disposition des usages sans aucun support du cycle de vie.
La gestion du cycle de vie permet d’assurer le suivi d’un lieu et donc d’une adresse, dans le temps, sans influence des évolutions administratives, comme la modification de son toponyme principal ou son rattachement à une nouvelle commune.
DRAFT : Etude en cours sur la possibilité d'utiliser des fichier hybride (lieu avec et sans banID au sein d'un même fichier BAL)
Le fournisseur de données portant la responsabilité des informations qu’il fournit, la BAN n’a pas vocation à les adapter/modifier/corriger. En ce sens, elle ne modifie jamais les informations issues d’un fichier BAL. Pour autant, le format BAL étant particulièrement permissif, certaines incohérences (volontaires ou non) peuvent apparaitre au sein des données fournies à la BAN.
La suite de ce document a pour objectif d’expliquer le comportement adopté par la BAN lors de la digestion des données d’un fichier BAL.
Lors de l’intégration des données d’un fichier BAL au sein de la BAN, les adresses, voie, lieu-dit, ou autre toponyme et enfin communes ou arrondissement, suivent un cycle de vie différent selon la présence ou non d’identifiants BanID.
-
Si aucun Identifiant BanID n’est fourni :
- Si elles sont présentes, l’ensemble des données préexistantes de l’entité administrative responsable (
District) sont supprimées - L’ensemble des données du fichier BAL sont ajoutées à la BAN.
- Aucun historique des données n’est conservé
- Absence de cycle de vie : Le suivi d’une adresse ne peut pas être assuré - pas de notion de mise à jour, la nouvelle saisie écrase et remplace la précédente.
- Si elles sont présentes, l’ensemble des données préexistantes de l’entité administrative responsable (
-
Si les identifiants BanID sont fournis :
- Le système va identifier les ajouts, suppression et modification de données.
- Les mises à jour sont effectuées de façon atomique (seules les opérations nécessaires sont effectuées) sous forme d’ajouts, suppressions ou modifications.
- L’historique des données est automatiquement conservé.
- Maintenance du cycle de vie : Chaque adresse est maintenue dans le temps et supporte les mises à jour de ses informations.
Lors de leur intégration, les données fournies par un fichier BAL ne sont pas réordonnées et sont traitées dans leur ordre de fourniture, soit dans un ordre descendant.
Il est conseillé de fournir les données, triées par commune ou arrondissement (si nécessaire) dans l’ordre suivant :
- Odonymes (voies et/ou lieux-dit) sans adresses
- Adresses, ordonnées par positions.
À chaque ligne d’un fichier BAL, le système va créer ou mettre à jour au moins un objet Address et/ou Toponym.
Le traitement par ordre descendant et la présence ou non d’identifiants BanIDs ont une influence directe sur la digestion des données.
À chaque ligne d’un fichier BAL, le système va :
- Identifier le
District, sur la base du code INSEE (ou à défaut, du nom) de la commune indiqué sur la ligne en cours de lecture. - Créer un objet
CommonToponymidentifié par la combinaison des éléments suivants :- Le code INSEE (ou à défaut, le nom) de la commune indiqué sur la ligne en cours de lecture.
- Le nom du toponyme principal indiqué sur la ligne en cours de lecture.
- Si la ligne indique qu’il s’agit d’une position d’adresse (format BAL 2.x) ou bien qu’un numéro est présent et inférieur à 99999 (format BAL 1.x), créer un objet
Addressidentifié par la combinaison des éléments suivants :- Le code INSEE (ou à défaut, le nom) de la commune indiqué sur la ligne en cours de lecture.
- Le nom du toponyme principal indiqué sur la ligne en cours de lecture.
- Le numéro indiqué sur la ligne en cours de lecture.
- S’il est présent, le suffixe indiqué sur la ligne en cours de lecture.
À chaque ligne d’un fichier BAL, le système va :
- Créer ou mettre à jour (après récupération dans la BAN) un objet
CommonToponymidentifié par son ‘BanID de toponyme principal’ indiqué sur la ligne en cours de lecture. - Si la ligne indique qu’il s’agit d’une position d’adresse (format BAL 2.x) ou bien qu’un numéro est présent et inférieur à 99999 (format BAL 1.x), créer ou mettre à jour (après récupération dans la BAN) un objet ‘Address’ identifiés par le ‘BanID d’adresse’ indiqué sur la ligne en cours de lecture.
L'envoi des données de lieux vers la BAN est effectué après digestion et suit diverses étapes dans un ordre précis :
- Suppression, dans la BAN, de tous les objets de lieux non identifiés (sans BanID) et liés à ce
District. - Ajout, dans la BAN, des nouveaux objets
CommonToponymcréés (avec ou sans BanID). - Modifications, dans la BAN, des objets
CommonToponym(uniquement pour ceux avec BanID). - Ajout, dans la BAN, de nouveaux objets
Addresscréés (avec ou sans BanID). - Modifications, dans la BAN, des objets
Address(uniquement pour ceux avec BanID). - Suppression, dans la BAN, de tous les objets de lieux identifiés (avec BanID) et liés à ce
District, et absent du fichier BAL.
L’ordre des attributs (colonnes) au sein des fichiers BAL n’a pas d’incidence sur l’intégration des données. Les attributs inconnus sont ignorés et ne sont pas enregistrés dans la BAN.
Bien que chaque ligne du format BAL corresponde à une position, les objets stockés par la BAN sont des objets de type Address, CommonToponym ou District (voir la section `Structure de données au sein de la BAN’ ). Ce sont ces objets qui portent les positions.
Les objets Address peuvent porter plusieurs positions. Ces positions y sont donc stockées sous forme de liste.
L’ordre des positions fournies dans le format BAL est conservé au sein de la BAN.
Par convention, la première position fournie sera considérée comme étant celle par défaut.
Si des positions sont nécessaires pour un usage métier, et que cette information est à la fois librement partageable et d’intérêt public, alors elle devrait se trouver au sein des données méta de l’adresse.
- Les toponymes n’ont pas de gestion multiposition.
- Le format BAL 1.x actuel permet de ne spécifier qu’un choix restreint de données méta des communes/toponymes/adresses. À savoir :
- Commune : Code INSEE
- Adresses : Codes de Parcelles cadastrales
Par convention, la première valeur de 'position' fournie est considérée comme étant celle par défaut.
C’est donc cette première valeur qui devra être utilisée par les systèmes exploitant les données de la BAN et se limitant à une unique 'position'.
DRAFT : Exemple a venir
Au sein d’un fichier BAL, hormis les attributs spécifiques aux multilinguismes (attribut suffixé par le code de la langue), les données sont fournies dans la langue par défaut.
À moins d’indications spécifiques du fournisseur de données, la langue par défaut est le Français (code FRA dans la norme iso639-3).
S’ils sont présents, les attributs multilingues permettent de fournir une traduction dans la langue indiquée par le suffixe de l’attribut.
Dans le cas où un attribut multilingue fourni fait référence à la langue par défaut (et donc en doublon, par exemple nom_voie_FRA alors que la langue par défaut est déjà le français), alors cette valeur est ignorée lors de l’intégration.
Dans le cas où la valeur d’un attribut multilingue est vide, alors cette donnée n’aura pas de valeur multilingue. (Dans ce cas, la valeur par défaut - sans multilinguisme - devra être exposée par les usagers)
- La BAN fournit une API permettant de spécifier la langue par défaut pour chaque fournisseur de données.
- Le format BAL ne permet pas de spécifier une langue par adresse/voie/toponyme, mais uniquement de façon globale, sur l’ensemble des données fourni.
En cas d’exposition de données dans une langue absente de la BAN, les données par défaut - sans multilinguisme - seront celle à privilégier.
DRAFT : Exemple a venir
La BAN stocke des objets de lieu de type ‘adresse’ (les Address ), ‘voie, lieu-dit, ou autre toponyme’ (les CommonToponym) ou commune ou arrondissement (les District).
Si ces données sont issues d’un fichier BAL, que le fournisseur de données dispose des autorisations de publication et que la structure du Format BAL est respectée, alors les données contenues au sein du fichier seront acceptées par la BAN.
Pour autant, un fichier BAL est un fichier CSV respectant un format déterminé et distribuant ses informations sous forme de lignes. Chacune de ces lignes représente une position d’adresse ou de voie et autre lieu-dit sans adresse d’une entité administrative (une commune ou un arrondissement). Ce mode de diffusion nécessite la duplication d’un certain nombre d’informations (numéro d’adresse, nom des voies, etc.) qui peuvent alors présenter des incohérences ou ambiguïtés ayant une influence lors de la digestion des données. De plus, la digestion de ces incohérences se comportera différemment en fonction de la présence ou non d’identifiants BanID.
Il revient au fournisseur de donnée de fournir des informations fiables et de qualités.
En raison de la gestion Multiposition des objets de type Address, dans le cas où, au sein d’un fichier BAL, deux lignes de positions d’une même adresse indiqueraient les mêmes positions, alors cette position serait enregistrée comme toutes les autres avant elle (et sera donc stockée en doublon). Il reviendra alors au fournisseur de données de corriger les informations de son fichier BAL.
DRAFT : Exemple a venir
Les dates de mise à jours fournis au sein de la Ban sont uniques pour chaque objet de 'lieu' (et non par position).
Du fait de la gestion Multiposition des objets de type Address au sein d’un fichier BAL, deux lignes de positions d’une même adresse pourraient fournir des dates de mise à jour différentes.
En raison du traitement des données par ordre descendant, chaque ligne de position d'adresse mettra à jour les données d’adresses déjà traitées. En conclusion, pour chaque adresse, seule la dernière date de mise à jour indiquée dans le fichier BAL sera conservée. Il reviendra alors au fournisseur de données de corriger les informations de son fichier BAL.
On distingue la date de mise à jour fournie par le fichier BAL (dont il est ici question) de la date de mise à jour au sein de la Base De Données BAN. La première (issue du fichier BAL) qui correspond à la date de mise à jour du lieu (toponyme ou adresse) administré et fourni par le
districtet stocké (comme les autres données du fichier) au sein de la BAN. La seconde (produite directement par la BAN) correspond à la date de mise à jour au sein de la Base De Données BAN. Bien qu'étant également disponible, elle est générée automatiquement lors de l'enregistrement en Base De Données et ne relève pas de la responsabilité du producteur de la donnée.
Généralement rencontré lors de fusions de communes, un toponym homographe s’illustre par la présence, dans un fichier BAL, de plusieurs lieux Address aux attributs voie_nom (format BAL v1.x) ciblant des lieux différents, mais à l’orthographe semblable, au sein d’une même commune.
La digestion des données aboutirait sur la constitution d’un unique Toponym, sur la base de l’orthographe présente dans le fichier BAL. Il reviendra alors au fournisseur de données de corriger les informations de son fichier BAL (en modifiant la valeur de l’attribue, pour distinguer chaque toponyme).
DRAFT : Exemple a venir
La présence d’identifiant 'BanID toponym' distinct permettra au système d’identifier correctement les Toponym, indépendamment de leurs orthographes communes.
DRAFT : Exemple a venir
Un toponyme hétérographe s’illustre par la présence, dans un fichier BAL, de plusieurs lieux Address aux attributs voie_nom (format BAL 1.x) ou toponyme_principal (format BAL 2.x) ciblant un même lieu, mais selon différentes orthographes, au sein d’une même commune.
La digestion des données aboutirait sur la constitution de plusieurs toponymes, chacun correspondant à une orthographe présente dans le fichier BAL. Il reviendra alors au fournisseur de données de corriger les informations de son fichier BAL.
DRAFT : Exemple a venir
La présence d’un même identifiant 'BanID toponym' permettra au système d’identifier correctement les toponymes, indépendamment de leurs orthographes.
Cependant, en raison du traitement des données par ordre descendant, chaque ligne de toponyme mettra à jour le nom d’un objet toponym déjà traité. En conclusion, seule la dernière orthographe indiquée dans le fichier BAL sera conservée.
DRAFT : Exemple a venir
Les objets de type Toponym n’acceptent qu’une unique position.
En raison du traitement des données par ordre descendant, chaque ligne de toponyme mettra à jour la position d’un toponyme déjà traité. En conclusion, seule la dernière position indiquée dans le fichier BAL sera conservée.
DRAFT : Exemple a venir
Combinaison de plusieurs types d’incohérences sur un même objet de lieu. L’ensemble des traitements indiqués précédemment sont alors appliqués.
DRAFT : Exemple a venir
adresse.data.gouv.fr : Le site national des adresses
Référencer l’intégralité des adresses du territoire et les rendre utilisables par tous.