Le portail francophone de la géomatique

Bonjour,

La réponse est oui dans les deux cas.
C'est aussi valable si vous faites le choix de publier une Base Adresse Locale.

Tout dépend de ce qu'on appelle la BAN...

Pour moi, c'est la base publique accessible à tout le monde, et oui, cette BAN là n'a pas été mise à jour pendant de nombreux mois.

Si vous parlez à d'autres personnes, leur BAN sera celle que vous alimentez avec le guichet adresse, mais avant que son contenu ne soit diffusé au public... autant dire une base fermée, bien loin du principe de diffusion publique de la BAN.

Pour le passage en licence ouverte, allumons un cierge pour que ça se passe effectivement comme l'a écrit le premier ministre en réponse à la cour des comptes... car tant que c'est pas fait tout peut encore changer vues les tensions entretenues par certains "partenaires".

Bonjour,
nous sommes revenus à une situation "nominale" (j'y reviens) début juillet, avec un export des données de la BAN diffusé sur https://adresse.data.gouv.fr/donnees-nationales.
Perso, je ne peux parler que pour la colonne de gauche (les 2 autres sont offertes par la maison pour clarifier les choses...).
Cette "colonne de gauche", c'est un export des données de la BAN (qui, en vrai, contient un peu plus d'informations, parfois).
Ce qui est particulièrement cool avec cet export:
- Le produit intègre la valeur ajoutée de « multipositionnement ». Donc une adresse donnée (73 avenue de Paris à Saint Mandé, par exemple) peut avoir plusieurs XY, qui correspondent à différents type de localisation : parcelle, entrée, accès-secours… En revanche, pour une adresse donnée et un type de localisation donné, il ne peut y avoir qu’une seule source. On a retenu, dans les rares cas où la situation se présente, la plus récente.
- Le produit est voisin, dans sa structure, de la base adresse locale…
- Le produit est plein d’identifiants : des ID_BAN (position, adresse, groupe), un ID_Fantoir, une clé d’interopérabilité…
- Pour les habitués des données IGN ou pour les utilisateurs de la version précédente de ces "exports", on a mis aussi des tables de lien entre ID_BAN et ID_IGN...

Et l'autre truc cool, c'est que cet export existe et est mis à jour régulièrement (chaque semaine).

Pour autant, cette situation "nominale" n'est pas pleinement satisfaisante, mais on y travaille. En particulier:
- la licence. Sans trahir de secret, et sans m'avancer beaucoup non plus, les données de cet "export" seront en licence ouverte Etalab 2.0 au 1er janvier 2020;
- la relation avec les BAL. Comme indiqué ci-dessus, le produit est (très) voisin, dans sa structure des BAL. Mais surtout, dans pas longtemps (teasing), il y aura une fonction d'import massif dans le guichet adresse.

Bref. Ca avance! Et d'une part, OUI, déjà aujourd'hui, quand vous alimentez le guichet adresse ou quand vous transmettez vos données à l'IGN (mais autant alimenter le guichet adresse, c'est plus direct), ça apparaît dans les exports (y compris via API); et d'autre part, ça ira encore mieux demain.

Matthieu (IGN)

Bonjour,
j'avous que je veux bien des éclaircissements par ce que vous entendez par là:

Matthieu (IGN)

Bonjour,

si j'ai compris l'idée dans un futur proche c'est pouvoir déposer une base au standard BAL pour l'importer dans la BAN.

Dans ce cas, je présume que l'IGN récupérera les données directement dans la BAN pour les ajouter dans la BD Adresse ?

Il serait intéressant pour les gestionnaires de données de comprendre à partir d'un schéma les différentes synchronisations réalisées avec information sur la fréquence.
A ce jour je sais qu'il y a :
- l'API de la BAN
- l'API de l'IGN ( si j'ai bien cherché, look4).
- Je ne connais pas, il y a peut-être aussi l'API BANO ?

Tout ça fait plusieurs outils qui utilisent des bases de données différentes.
Ca me semble un peu compliqué d'avoir une idée claire pour savoir quelle API utilisée.
Et le fait de ne pas avoir la vue d'ensemble des différentes synchronisations et fréquences de synchro complique également la prise de décision.

A moins d'alimenter à chaque fois plusieurs bases (nécessite plusieurs exports à chaque fois).

Bonjour,

effectivement ça me parait le plus efficace le dépôt standard BAL sur data.gouv.fr.
Le problème par contre c'est que dans ce système on maîtrise pas quand les données seront disponibles dans les bases de données telles que la BAN, la BANO, la BD Adresse ...
Du coup, si on développe une appli sur une thématique pour laquelle on veut se baser sur la recherche adresse, le plus efficace pour pouvoir fournir les meilleurs résultats est de mettre en place l'API chez soit et utilisant sa propre base de données.

Exemple : je créé une appli sur un thème quelconque basée sur une recherche adresse.
Quand une erreur est remontée : voie et adresse manquante, ou uniquement adresse manquante. Je corrige mais pour que je puisse informer quand est-ce que celle-ci sera effective dans l'application je ne peux pas le dire si je me base sur un dépot BAL dans data.gouv.fr. Je suis obligé de mettre en place ma propre API pour répondre à cette question.
J'espérais que l'API mis à disposition par api-adresse.data.gouv.fr me permettrait d'éviter tout ce temps de mise en place, et de maintenance ensuite. Sachant qu'il faut avoir les ressources techniques en mesure de savoir déployer le composant addok et toute la config qu'il doit falloir réaliser

Si le besoin est d'avoir un géocodeur le plus exhaustif possible, malheureusement aujourd'hui on est obligé de s'appuyer sur plusieurs référentiels.

Pour géocoder la base SIRENE, j'utilise trois instances (locales) d'addok:
- une instance BAN
- une instance BANO (plus complète sur les lieux dits, potentiellement plus fraiches sur certaines adrsses ajoutée dans OSM mais encore absentes de la BAN)
- une instance complémentaire avec les POI pour retrouver des "adresses" comme "Hôtel de Ville" ou "Centre commercial Leclerc"

Si votre besoin est d'avoir un géocodeur répondant sur les données de votre collectivité, oui, déployer da propre instance d'addok est la meilleure solution, c'est simple et léger pour une petite base comme ça.
J'avais écrit un article à ce sujet: https://medium.com/@cq94/serveur-de-g%C … e142ea59b2
C'est aussi le seul moyen d'être sûr que ce sont "vos" adresses qui sont retournées, car la sélection faite par les bases agrégées comme BAN ou BANO ne le garantit pas. Vous maîtrisez de plus le cycle de mise à jour.

Sinon, comme jérôme, l'explique, le circuit le plus court est la publication de votre BAL sur datagouv, ce qui fera que ces données seront intégrées chaque début de semaine dans api-adresse.data.gouv.fr.

Dernière modification par cquest (Wed 25 September 2019 09:31)

Bonjour,
Nous sommes de nombreux acteurs à envisager l’utilisation croissante de la BAN – d’autant que la licence ouverte sera un facteur facilitant et accélérant.
Au fil des échanges, on voit bien se dessiner le paysage concernant l’alimentation par les collectivités créatrices et gestionnaires de ces adresses.

En revanche, nous nous posons quelques questions concernant le dispositif pour un organisme « consommateur » de la BAN.

Dans le cas nous concernant, pour un gestionnaire de réseau comme ENEDIS :
La BAN sera utilisée pour rechercher/se localiser sur une adresse.
Selon la volumétrie/la fréquence/la criticité de ces usages, il est probable qu’une duplication régulière dans notre SI soit organisée.
D’autant qu’elle pourra également être utilisée pour associer une adresse/une référence BAN à des objets métier gérés en interne.
Notre interrogation majeure concerne le cycle de vie des adresses BAN et le cas où des adresses qui pourraient nous être mentionnées en avance – en particulier lors des demandes de futur raccordement ou de projets de lotissement. Quel rôle envisageable pour les organismes consommateurs ? 
Est-il souhaitable de développer des remontées ? En intégrant par exemple des fonctions de signalement dans certaines de nos collectes métier associant une adresse ?  Dans les outils la BAN gérant les signalements, est-il envisageable de proposer un service à des acteurs « de confiance » permettant d’obtenir un identifiant BAN (adresse) dès ce signalement ? (Pouvant s’accompagner d’une fourniture de position par un acteur « non gestionnaire »).
Ou est-ce vu comme une source complémentaire peu pertinente car susceptible de déclencher des analyses chronophages de signalements « inutiles » , en doublon. Et devons-nous simplement observer/constater les évolutions et mises à jour de la BAN (pour éventuellement la synchroniser avec nos données métier) ?

D’avance merci de vos retours / avis sur le sujet,

Cordialement,
Loïc REBOURS

Remarque sur la gouvernance Adresse : beau thème de travail qui pourrait être instruit dans un GT adresse d’un CNIG rénové associant des organismes producteur mais également utilisateurs…

Les fichiers disponibles sur http://bano.openstreetmap.fr/BAN_odbl/ sont bien les fichiers BAN et pas BANO.

Depuis l'arrêt pendant de nombreux mois, puis la reprise de diffusion sous une autre forme, les nouveaux fichiers équivalent sont bien ceux sur  https://adresse.data.gouv.fr/donnees-nationales

La nouvelle base de laquelle sont issues les données utilise de nouveaux identifiants et les fichiers housenumber-id-ign-XX.csv.gz permettent de passer des anciens ID aux nouveaux.

Je n'ai par contre pas ma boule de cristal pour savoir:
1) si la BAN sera en LO en janvier
2) si son contenu va changer
3) l'avenir des identifiants.

L'identifiant le plus stable reste dans bien des cas la clé d'interopérabilité, même si c'est pas du 100%.
Là aussi des tables de mise à jour seraient utiles pour prendre en compte les fusions de communes, les changements de codes FANTOIR ou  l'attribution de codes FANTOIR en remplacement des codes temporaires...

Les réutilisateurs apprécieraient sûrement beaucoup !

Bonjour

Pour cetre complet (?) sur ces sources d'adresses, qui pourrait me dire si les adresses disponibles sur http://bano.openstreetmap.fr/data/ sont toujours mises à jour?

Est ce les mêmes sources que le site mentionné par christian http://bano.openstreetmap.fr/BAN_odbl/

Merci

Fabrice

Bonjour,

12 minutes de fraîcheur dans ce mon de brutes!
https://blog.geo.data.gouv.fr/comment-u … 5cb7238b0e

Ce qui m'a donné le plaisir de lire également cet article:
http://hypergeo.eu/spip.php?article725

Bruno

On respire un grand coup et on reprend...

La BAN ne peut accepter de données ODbL en entrée, car elle n'est pas rediffusée QUE sous cette licence (ce que l'ODbL impose).
Elle peut (et doit même par la convention de 2015, qui n'a pas été dénoncée) être diffusée sous ODbL.

On peut donc compléter la BAN "sortie" par des données ODbL qui n'ont pu y être versées "en entrée" comme certaines BAL publiées par des collectivités qui ne diffusent leur opendata qu'en ODbL (cas de Paris).

Je ne sais pas par contre aujourd'hui quelles données complémentaires sont ajoutées et quels traitements spécifiques sont faits. Quand je m'en occupait, il y avait toute une passe de nettoyage qui était faite, de compléments sur les libellés, de croisements pour sortir les noms des anciennes communes ou régions voire de dédoublonnage. Voir par exemple: https://github.com/etalab/ban-data/blob … /clean.sql


Si le géocodeur utilise la version ODbL c'est parce que la licence "gratuite de repartage", ne permettait pas de diffuser les données via une API de géocodage vues les contraintes qu'elle comportait. Ceci a peut être évolué avec la dernière rédaction, mais j'avoue que j'ai abandonné tout intérêt à son sujet il y a bien longtemps.


Plus que quelques semaines (au pire) à attendre vu que le premier ministre a assuré que la BAN serait en LO avant la fin de cette année dans une réponse faite à un référé de la cour des comptes.

Il y aura donc disparition de la licence exotique, mais toujours potentiellement une version LO et une ODbL potentiellement plus complète (on ne peut pas mettre de l'ODbL dans la LO, mais on peut faire l'inverse).

On travaille à la clarification de l'offre en terme de données.
Ce qui est certain c'est que le fichier le plus exhaustif en terme d'adresses est Adresses ODbL, puisqu'il contient les deux autres.
C'est celui qui est utilisé dans le géocodeur, pour cette raison, mais aussi en raison de la licence de réutilisation.

Les post-traitements sont nombreux et sont essentiellement tournés vers la qualité et l'enrichissement (dédoublonnage, libellés AFNOR, lieux-dits, contexte géographique, anciennes communes, correction FANTOIR…).

Au 1er janvier 2020, les fichiers Adresses ODbL et Adresses LO seront confondus en "Adresses", le fichier sera sous Licence Ouverte.

L'IGN et La Poste se sont engagés à alimenter la BAN en LO, tous les fichiers changeront donc simplement de licence, ou seront rendus caduques.

La DINUM et l'IGN se sont par ailleurs engagés à converger vers un tronc commun, à terme. Mais il y a beaucoup de travail avant d'y arriver.

Vous parlez des voies ne comportant que des numéros virtuels en 5000-9000 ?
Si c'est le cas elles ont été ajoutées samedi dans le fichier addok-json, et le seront dans un fichier CSV distinct d'ici une quinzaine de jours.

Bonjour à tous,

Dominique voici qui devrait t'éclairer sur les 3 bases J'ai été très contente de trouver ça pour y voir plus clair.
Ces éléments sont disponibles dans le MOOC Adresse sur France Université Numérique.

https://imagizer.imageshack.com/img922/3586/yuWedl.png
https://imagizer.imageshack.com/img921/7263/cgLblv.png
https://imagizer.imageshack.com/img921/9987/cvJRe7.png

Dernière modification par Gaëlle G (Tue 19 November 2019 12:16)