Bonjour à tous !
Je pense qu’il ne serait pas inintéressant qu’on partage sur nos usages, nos contournements, nos configurations, nos petits ajustements, nos besoins, etc.
Je commence donc avec NexSIS, en prenant une approche plus fonctionnelle que technique…
Et je vais essayer de respecter au mieux la position de notre client (l’ANSC).
1. Données intégrées
Les adresses de la BAN
Nous intégrons bien évidemment les données de la BAN, à partir des fichiers JSON générés par Etalab. En effet, le tout premier objectif de NexSIS était d’avoir le même service que celui offert par api.adresse.data.gouv.fr, mais sans dépendre d’une connexion Internet.
À la cible, il est possible que l’on cherche à ne pas tout récupérer de la BAN. Par exemple, on pourrait se contenter des housenumbers et remplacer les locality/municipality par des données de l’IGN (voir plus bas).
Ce qu’on appelle des “Localisants”
Tous ces “localisants” sont typés. Le champ “type” exposé par Addok présente donc d’autres valeurs que les habituelles “street”, “housenumber”, etc. On y retrouve des valeurs comme “acces”, “activite”, “onf”, “pk”, etc.
Localisants métiers issus des SDIS
Dans Addok, nous intégrons également des données provenant des SDIS :
- Activités (ERP, ICPE, commerces, etc.)
- Points d’interet (POI)
- Adresses complémentaires (des adresses absentes de la BAN)
- Accès (PRM, etc.)
- etc.
Localisants issus de référentiels externes
Et nous intégrons aussi des données provenant de fournisseurs (comme la BD TOPO de l’IGN, par exemple) :
- Hydrographie (ponctuels et linéaires)
- Point d’activité ou d’interet (PAI)
- Point de Rencontre des Secours en Fôret (PRSF)
- Parcelles forestières (ONF)
- Points kilométriques (ne fonctionne pas vraiment pour le moment)
- Communes (pour remplacer les communes ponctuelles de la BAN ?)
- Routes nommées & numérotées (pour remplacer les routes ponctuelles de la BAN ?)
- etc.
Nous réfléchissons aussi à l’intégration de POI venant d’OSM, afin de compléter les données des SDIS et les données de l’IGN…
2. Champs supplémentaires
Nous avons ajouté un champ “localisation” (qui est indexé), afin de pouvoir différencier le “nom” d’un localisant et son “adresse”. Cela concerne surtout les localisants (voir 1.2). Exemple : un localisant peut avoir un nom (Gazechim) et une localisation (13 rue Denis Papin). Les adresses BAN, elles, n’ont donc qu’une localisation (pas de nom).
Nous avons ajouté un champ “wkt” pour pouvoir afficher autre chose que des points sur une carte. Ainsi, pour chaque document présents dans Addok, nous avons un lon/lat (centroïde) et un WKT (géométrie). Cela concerne surtout les localisants (voir 1.2).
Nous avons modifié le formatter afin qu’il retourne un tableau de tous les noms présents dans les documents (et pas juste le premier nom).
3. Services recréés
Effectuer une recherche “géographique”
Nous avons abandonné la fonction de géocodage inverse d’Addok et avons décidé de recréer (au sein de notre API) un service GET de recherche géographique via les fonctions de PostGIS.
Ce service propose les mêmes filtres que ceux proposés par Addok et nous permet de :
- trouver des résultats proches de coordonnées géographiques
- trouver des résultats intersectant un polygone
Cela nous oblige par contre à bien synchroniser le contenu d’Addok et le contenu de notre BDD (voir paragraphe 5 sur ArchiBAN).
Lister les numéros d’une rue donnée
Nous avons crée (au sein de notre API) un service GET qui nous permet, pour un id de voie (street), de lister tous les numéros de cette voie (et leurs attributs).
Du coup, lorsqu’un utilisateur sélectionne un résultat de type “street”, une liste déroulante lui propose de faire un choix parmi tous les numéros de cette rue (avec auto-complétion et possibilité de saisir un numéro qui n’existe pas).
4. Infrastructures
Pour plus de résilience, nous avons mis en place des clusters Redis avec 2~3 Redis et un HA Proxy. Cela étant, j’ai l’impression que nous sommes en train de revenir sur cette décision (overkill ?).
Par contre, nous nous posons des questions sur le fait d’avoir 2 instances d’Addok différentes :
- une pour les données froides (BAN, IGN, etc.)
- une pour les données chaudes (localisants, etc.)
Notre API, qui sert un peu de proxy, pourrait jouer le rôle de Y (comme le ferait Metaddok ?).
5. ArchiBAN
ArchiBAN est un outil développé en Python par Camptocamp pour NexSIS. Nous sommes sur le point d’ouvrir son code source, avec l’accord de notre client (ANSC). Il visait à répondre aux 3 problématiques suivantes.
Téléchargement de la BAN et import dans PgSQL
ArchiBAN vise à automatiser :
- le téléchargement des données de la BAN (HTTP)
- le fait de décompresser ces données (GZ)
- le fait de nettoyer ces données (présence d’ids en doublon !)
- de les importer dans une base PgSQL (deux tables + une vue matérialisée)
Indexation unitaire d’un document
ArchiBAN offre un endpoint PUT permettant d’indexer un document dans Addok, à chaud. Nous faisons des appels à cet endpoint PUT lorsqu’un nouveau document doit être disponible immédiatement dans les applications NexSIS.
Au sein de notre API, le service qui permet de créer/modifier un localisant (POST & PUT = INSERT INTO & UPDATE) va se charger de faire un appel à ce service PUT, afin que ce localisant soit disponible en recherche textuelle (Addok) et en recherche géographique (PostGIS) immédiatement et en même temps.
Synchronisation entre PgSQL et Addok
ArchiBAN vise à automatiser :
- la comparaison entre les données PgSQL et les donneés présentes dans Addok
- l’identification des données à créer/modifier/supprimer dans Addok (différentiel)
- l’indexation/désindexation de ces données identifiées (afin d’avoir un Addok synchronisé avec nos tables PgSQL)
On part du principe, en effet, que notre BDD PgSQL a raison (master) et qu’Addok doit suivre (sorte de replica ?). L’étape suivante, ce serait de lier fortement notre BDD à Addok (comme le fait le plugin pgstore).
6. Besoins
Enrichir les filtres sur les résultats
Notre urgence est de pouvoir mieux filtrer les résultats remontés par Addok.
Filtrer sur plusieurs valeurs pour un champ donné :
- … WHERE citycode IN (77288, 77487)
- … WHERE type IN (“housenumber”, “acces”)
- … WHERE type IN (“housenumber”, “acces”) AND citycode IN (77288, 77487)
Filtre en excluant des valeurs
- … WHERE citycode NOT IN (77288)
Retrouver lequel des noms a matché
Quand plusieurs noms sont indiqués dans un document (array), Addok retourne le premier nom (array[0]). On a fait en sorte de remonter tous les noms (voir paragraphe 2) mais on aimerait aussi pouvoir connaître lequel de ces noms a matché et a donc fait en sorte que le document soit pertinent pour la requête réalisée.
