Installation d’un moteur de recherche pour du géocodage

Magazine
Marque
GNU/Linux Magazine
Numéro
189
|
Mois de parution
janvier 2016
|
Domaines


Résumé
Le géocodage c’est associer des coordonnées géographiques à une adresse. Cela permet de savoir avec précision où se situe l’adresse. Il faut donc avoir les adresses et un moyen de chercher dans cette énorme base de données.

Body


Dans ce court article, nous allons voir comment installer addok, un moteur de recherche d’adresses. Nous verrons ensuite où trouver les données et comment les mettre dans ce moteur de recherche. Il n’y aura ensuite plus qu’à lancer le service Web pour répondre aux requêtes.

1. Installation d’Addok

Il y a plus de 20 millions d’adresses dans la BANO, donc pour avoir des performances acceptables l’auteur a choisi d’utiliser Redis [2] qui est une base NoSQL qui stocke ses données en RAM. Cela implique que :

1. c’est rapide ;

2. ça consomme beaucoup de RAM.

Le reste du logiciel est développé en Python3 (le futur est arrivé \o/). Nous allons donc travailler dans un virtualenv.

On va installer les logiciels sur notre ubuntu 14.04 :

$ sudo apt-get install redis-server python3.4 python3.4-dev python-pip python-virtualenv virtualenvwrapper

On va se créer un dossier dans lequel on va faire notre tambouille :

$ mkdir ~/ban && cd ~/ban

On crée ensuite notre virtualenv qui va accueillir addok :

$ virtualenv addok --python=/usr/bin/python3.4

On active le virtualenv puis on installe addok :

$ source addok/bin/activate

$ pip install addok

Maintenant, addok devrait être installé.

2. Téléchargement des données

On va donc télécharger les données de la BANO. Je vous laisse choisir quelles données vous souhaitez avoir dans votre moteur de recherche, mais faites attention, plus on met de données, plus Redis va consommer de la mémoire vive. Pour toute la France, Redis a besoin de plus de 20 Gio de RAM.

Pour télécharger les données du département 14, on utilise la commande suivante :

$ wget http://bano.openstreetmap.fr/data/bano-14.json.gz

Notez que si vous voulez télécharger plusieurs départements, vous n’êtes pas obligé de taper plusieurs fois la commande, vous pouvez mettre les numéros entre accolades séparés par des virgules. Par exemple, pour télécharger les données de la Basse-Normandie, soit les départements 14, 50, et 61, on peut le faire comme ça :

$ wget http://bano.openstreetmap.fr/data/bano-{14,50,61}.json.gz

On décompresse le(s) fichier(s) téléchargé(s) et on met tout dans un fichier qu’on va importer :

$ gzip -d *gz

$ cat *json > data.json

2.1 Code INSEE

Il se peut que vous ayez besoin des codes INSEE des communes. Pour cela, il suffit de rajouter un fichier de configuration qu’on va appeler local.py. Dedans il suffit de mettre :

EXTRA_FIELDS = [

            {'key': 'citycode'},

            ]

FILTERS = ["type", "postcode", "citycode"]

Addok appelle le code INSEE « citycode » (c’est ce que vous devrez chercher dans le JSON contenant les réponses). Ensuite, on indique ce fichier à addok avec :

$ export ADDOK_CONFIG_MODULE=chemin/vers/le/fichier/local.py

Donc si local.py est dans le répertoire courant, il suffit de faire :

$ export ADDOK_CONFIG_MODULE=local.py

Lorsque vous lancerez les deux commandes suivantes, vous devriez avoir le message qui vous indique qu’il l’a bien pris en compte :

Loaded local config from local.py

3. Import des données

On va pouvoir importer les données maintenant que tout est en place :

$ addok batch data.json

Cela va mettre un petit moment, plus ou moins long suivant la quantité de données que vous lui faites ingérer. Vous allez aussi voir la quantité de RAM utilisée exploser. Pire que quand on lance du Java... enfin presque.

Pour les départements du 14, 50 et 61, la vm ubuntu qui me sert à vérifier l’intégralité des commandes que je donne consomme 994Mio de RAM.

Maintenant que les données sont dans Redis, on va calculer les n-gram [3]. Un n-gram est une partie de n éléments d’une suite de mots. Pour faire simple, c’est l’autocomplétion, c’est-à-dire que quand on lui donne « infant » il va nous proposer les adresses ayant le mot « infanterie ». Cette étape va prendre un peu de temps. :

$ addok ngrams

4. Lancement du service Web

On va lancer gunicorn qui va gérer les requêtes. Par défaut il écoute sur localhost ce qui n’est pas très pratique pour un serveur ; on surcharge donc cette adresse. Par défaut il écoute sur le port 8000 :

$ gunicorn addok.server:app --bind 0.0.0.0

On teste avec un navigateur en allant sur http://adresse-ip:8000/search/?q=Ville en remplaçant Ville par une ville présente dans les données que vous lui avez fournies. Dans mon cas, http://adresse-ip:8000/search/?q=Caen renvoie un fichier json avec toutes les informations qu’il trouve liées au mot Caen.

Maintenant, pour lancer gunicorn, le plus simple est d’écrire un script d’init pour que systemd (ou un autre init si vous êtes réticent au progrès :)) le lance au démarrage.

Conclusion

On vient donc d’installer un moteur permettant d’effectuer des recherches dans toutes les adresses que l’on souhaite, et ce très rapidement.

Références

[1] Dépôt Github d’addok : https://github.com/etalab/addok

[2] Page Wikipédia anglophone de Redis : https://en.wikipedia.org/wiki/Redis

[3] Page Wikipédia anglophone des n-gram : https://en.wikipedia.org/wiki/N-gram


Sur le même sujet

Apprenez à utiliser kubeadm

Magazine
Marque
GNU/Linux Magazine
Numéro
236
|
Mois de parution
avril 2020
|
Domaines
Résumé

Combien de fois m'avez-vous entendu dire « nous allons utiliser kubeadm pour faire ceci ou faire cela », et puis boum, un kubeadm init plus tard, tout est prêt ? Souvent ? Très souvent ? Trop souvent ? Alors pour une fois, pourquoi ne pas consacrer un article entier à ce merveilleux projet ?

Le DevOps dans le monde réel

Magazine
Marque
Linux Pratique
Numéro
118
|
Mois de parution
mars 2020
|
Domaines
Résumé

Cela fait environ cinq ans que les demandes de « DevOps » sont de plus en plus nombreuses dans le milieu professionnel. Souvent, lors des entretiens, on s'aperçoit que chaque client, ou presque, a sa propre définition du mot. Nous allons essayer de donner ici notre vision, tirée de notre expérience de terrain, de cette fonction.

KeeRest : mettez du DevOps dans votre KeePass

Magazine
Marque
MISC
Numéro
108
|
Mois de parution
mars 2020
|
Domaines
Résumé

Nous avions vu dans MISC n°103 comment déployer une base KeePass en mode SaaS ciblant les particuliers ou de petits périmètres professionnels. Dans un autre monde, les pratiques DevOps se démocratisent et demandent d’augmenter l’agilité des développements tout en réduisant les délais de mise en production. Cet article est le fruit d’une collaboration entre un DevOps et un ingénieur SSI pour voir de quelle manière il est possible de tirer profit de KeePass dans ces environnements.

LXC : les options avancées utiles en production

Magazine
Marque
Linux Pratique
Numéro
118
|
Mois de parution
mars 2020
|
Domaines
Résumé

La présentation de LXC faite dans le précédent numéro [1] nous a permis de mettre en œuvre les fonctionnalités de base et de créer rapidement des conteneurs fonctionnels. Cependant, les capacités de LXC ne s’arrêtent pas là et nous allons pouvoir étudier ici plusieurs options bien utiles en production.

Les alternatives à Git

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
107
|
Mois de parution
mars 2020
|
Domaines
Résumé

Dans le petit monde des gestionnaires de versions concurrentes, il n'existe pas que Git. D'autres projets permettent également de conserver les différentes versions d'un code et cet article permettra d'en faire un petit tour d'horizon.

Git, un tour d’horizon

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
107
|
Mois de parution
mars 2020
|
Domaines
Résumé

Le vocabulaire et les concepts-clés de Git ayant été définis dans le précédent article, nous allons maintenant nous intéresser à la manière dont les concepts présentés se réalisent à l’aide des commandes de l’outil. Bref, passons à la pratique !

Par le même auteur

Service de calcul d'itinéraire

Magazine
Marque
GNU/Linux Magazine
Numéro
189
|
Mois de parution
janvier 2016
|
Domaines
Résumé
Il peut être très utile de savoir comment se rendre d'un point A à un point B. C'est encore plus utile quand on connaît le temps de trajet estimé. Installons ça chez nous.

Installer son propre serveur de tuiles

Magazine
Marque
GNU/Linux Magazine
Numéro
188
|
Mois de parution
décembre 2015
|
Domaines
Résumé
D'un côté, le projet OpenStreetMap (ou OSM) fournit des données, de l'autre il y a les différentes cartes. Qu'y a-t-il entre les deux ? Le serveur de tuiles ! Et si on en installait un ?

Le nouveau système de queueing de Packet Filter

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
74
|
Mois de parution
septembre 2014
|
Domaines
Résumé
Si vous avez déjà joué avec un BSD, vous devez certainement connaître (et apprécier) Packet Filter (PF), le firewall développé sur OpenBSD. Si ce n'est pas le cas, on a déjà sûrement dû vous en vanter la syntaxe claire par rapport à celle incompréhensible d'iptables (certes, au bout de la 15ème fois qu'on utilise une commande, on commence à se rappeler à quoi sert l'obscure option -machin). Mais quid du queueing avec PF ?