Créer son propre miroir des données OpenStreetMap et un serveur de rendu des tuiles, avec Debian Wheezy

Introduction

Pour beaucoup de monde, OpenStreetMap est simplement une carte similaire à Google Maps, mais collaborative.

En réalité, c’est bien plus que cela.

La carte – ou plutôt les cartes, car il en existe une multitude – ne sont qu’une des applications possibles d’OSM.

OSM est avant tout une base de données géographique. Données à partir desquelles on peut, bien sûr, créer des cartes, mais pas seulement. On peut aussi les exporter et les traiter – par exemple à l’aide d’un logiciel de SIG comme QGIS – et obtenir ainsi bien d’autres choses : calcul de la surface boisée d’une région, du linéaire de voies ferrées ou des routes dans une zone donnée, du pourcentage de voies cyclables dans une ville, accessibilité à une gare…

Comme les données d’OSM sont libres, toute personne intéressée peut les copier et s’en servir comme bon lui semble. Les seules contraintes sont :

  • le respect de la licence (afin qu’elles restent libres),
  • la précision des données (mais vous pouvez les améliorer, en fonction des vos besoins et de vos possibilités),
  • vos propres contraintes techniques (compétences et matériel).

Par conséquent, il peut être tentant et utile de mettre en place son propre serveur OSM, pour plusieurs raisons :

  • garantir un accès rapide et fiable aux données, en local, sans dépendre de sa connexion à internet ni des serveurs d’OSM,
  • utiliser des données validées à une certaine date, et choisir soi-même quand les mettre à jour, évitant ainsi le risque – toujours possible – d’une mise à jour contre-productive (utilisateur débutant…),
  • faire des modifications sur les données, pour ses propres besoins, qu’il n’est pas souhaitable de faire sur le projet lui-même…

1. Architecture du projet

L’architecture du projet est présentée par le schéma suivant.

OSM Components.png

On peut le résumer ainsi :

L’import et l’édition des données du projet (en gris) permettent, via les outils en bleu d’alimenter la base de données principale du projet (PostgreSQL backend). À partir de celle-ci, sont générés à l’aide de l’outil Osmosis différents exports (dumps et diffs).

C’est à partir de ceux-ci qu’est construite, à l’aide de l’outil osm2pgsql, la base de données PostGIS qui sert à générer les tuiles (les images composant la carte). Cela se fait avec l’outil Mapnik. L’ensemble de ce processus est en jaune et entouré de traits pointillés.

Ensuite, ces tuiles sont exploitées par des outils permettant de gérer leur affichage (niveau de zoom, déplacement sur la carte…) afin d’aboutir à la carte que l’on connaît.

Ce qu’on voit plus à droite sur le schéma, en jaune, désigne d’autres façons de générer des tuiles, alternatives à Mapnik. En vert, on a également d’autres services qui s’appuient sur les exports de la base principale.

Ce qu’il faut retenir de ces quelques explications est que la mise en place de son propre serveur OSM ne consiste pas à répliquer la base de données principale (PostgreSQL backend) comme on aurait pu l’imaginer au premier abord. On n’a pas accès à cette base, qui est un outil interne au projet. Ce que fournit le projet, et qu’il faut aller chercher, ce sont les exports.

Cela peut surprendre, car ça revient à exporter une base de données PostgreSQL, pour recréer une base de données PostGIS à partir de cet export, et cela en utilisant deux outils différents. Mais c’est ainsi que cela fonctionne, y compris sur le site officiel.

2. Mise en place du serveur : installation des logiciels

À partir d’ici, cet article sera très fortement inspiré de cette documentation qui décrit la procédure la plus standard, celle utilisée sur les serveurs principaux du projet OSM.

Nous aurons besoin de cinq composants :

  • mod_tile, qui est un module pour Apache gérant l’envoi des tuiles au client, tout en décidant quand elles doivent être générées (soit parce qu’elles ne sont pas encore en cache, soit parce qu’elles sont obsolètes),
  • renderd, qui est un système de priorité pour optimiser le rendu en fonction des requêtes transmises par mod_tile et de façon à optimiser la charge du serveur,
  • mapnik, qui produit effectivement les tuiles,
  • osm2pgsql, qui servira à convertir les données des exports en une base de données PostGIS.
  • la base de données PostGIS en question.

Nous nous basons sur Debian Wheezy.

Nous créons un utilisateur système que nous nommons osm et qui sera utilisé pour toutes les opérations, hormis celles devant être effectuées obligatoirement avec les droits root.

Nous utilisons pour cela la commande

# adduser osm

et répondons aux questions.

Note : C’est notamment cet utilisateur qui génèrera les tuiles avec Mapnik.

2.1 Dépendances

Les dépendances s’installent par apt-get :

# apt-get install libboost-dev libboost-filesystem-dev libboost-program-options-dev libboost-python-dev libboost-regex-dev libboost-system-dev libboost-thread-dev subversion git-core tar unzip wget bzip2 build-essential autoconf libtool libxml2-dev libgeos-dev libgeos++-dev libpq-dev libbz2-dev proj-bin proj-data libproj-dev munin-node munin libprotobuf-c0-dev protobuf-c-compiler libfreetype6-dev libpng12-dev libtiff4-dev libicu-dev libgdal-dev libcairo-dev libcairomm-1.0-dev apache2 libagg-dev lua5.2 liblua5.2-dev ttf-unifont apache2-prefork-dev

2.2 PostgreSQL / PostGIS

On commence par installer l’ensemble…

# apt-get install postgresql-9.1-postgis postgresql-contrib postgresql-server-dev-9.1

Puis il faut créer une base de données PostGIS. Comme plusieurs programmes considèrent par défaut que la base de données s’appelle gis, on va garder ce nom. Mais ce n’est pas une obligation.

On va créer dans PostGIS l’utilisateur osm. Note : pour des raisons liées au fonctionnement de PostgreSQL, il est conseillé de garder le même nom que l’utilisateur système créé précédemment.

# su postgres
$ createuser osm # répondre oui pour super-utilisateur
$ createdb -E UTF8 -O osm gis
$ exit

Configurer PostGIS pour la base de données fraîchement créée.

# su osm
$ psql -f /usr/share/postgresql/9.1/contrib/postgis-1.5/postgis.sql -d gis

Cela doit vous renvoyer plusieurs lignes, se terminant par :

CREATE FUNCTION
COMMIT
DROP AGGREGATE
[...]
DROP FUNCTION

On donne ensuite à notre utilisateur la permission d’accéder à certaines extensions PostGIS.

psql -d gis -c "ALTER TABLE geometry_columns OWNER TO osm; ALTER TABLE spatial_ref_sys OWNER TO osm;"

Ce qui renvoie :

ALTER TABLE

2.3 Installation d’osm2pgsql

Même s’il existe probablement un paquet osm2pgsql, il est très fortement conseillé de compiler la dernière version. En effet, il arrive que le format des données d’OSM change et que les versions précédentes ne fonctionnent plus du tout.

$ mkdir ~/src
$ cd ~/src
$ git clone git://github.com/openstreetmap/osm2pgsql.git
$ cd osm2pgsql
$ ./autogen.sh
$ ./configure
$ make
$ su
# make install
# exit
$ psql -f /usr/local/share/osm2pgsql/900913.sql -d gis

(Note : Si comme moi vous êtes derrière un firewall qui ne laisse pas passer le protocole Git, alors remplacez git:// par http:// dans l’adresse du dépôt.)

2.4 Installation de Mapnik

Là encore, on va aller chercher les sources et les compiler.

$ cd ~/src
$ git clone git://github.com/mapnik/mapnik
$ cd mapnik
$ git branch 2.0 origin/2.0.x
$ git checkout 2.0
$ python scons/scons.py configure INPUT_PLUGINS=all OPTIMIZATION=3 SYSTEM_FONTS=/usr/share/fonts/truetype/
$ python scons/scons.py
$ su
# python scons/scons.py install
# ldconfig
# exit

On peut ensuite tester si Mapnik est bien installé en l’appelant depuis le shell Python.

$ python
>>> import mapnik
>>>

Si Python vous redonne la main sans message d’erreur, alors tout va bien.

2.5 Installation de mod_tile et renderd

On ne change pas une méthode qui fonctionne…

$ cd ~/src
$ git clone git://github.com/openstreetmap/mod_tile.git
$ cd mod_tile
$ ./autogen.sh
$ ./configure
$ make
$ su
# make install
# make install-mod_tile
# ldconfig
# exit

2.6 Installation du style OSM pour Mapnik

Il existe de nombreuses feuilles de style disponibles publiquement et librement, et on peut bien sûr créer son propre style (ce qui est notre but final). Mais dans cet article, nous allons utiliser celui par défaut d’OSM.

$ cd ~/src
$ svn co http://svn.openstreetmap.org/applications/rendering/mapnik mapnik-style

Pour des raisons de performances, Mapnik utilise des fichiers déjà prêts pour générer les océans et les côtes. Nous allons télécharger ces fichiers, qui représentent 400 Mo.

$ cd ~/src/mapnik-style
$ su
# ./get-coastlines.sh /usr/local/share
# exit

Note : Je pensais pouvoir sauter cette étape, car je travaille sur une petite zone non côtière. Par conséquent,j’ai édité le fichier ~/src/mapnik-style/osm.xml pour supprimer la ligne &layer-shapefiles (ligne 3351). Sans cette suppression, mon serveur de tuiles ne démarrait pas, car il cherchait ces fichiers que je n’avais pas téléchargés.

Après test, cela fonctionnait mais de l’eau apparaissait « par défaut » partout où l’occupation du sol n’était pas renseignée, ce qui était très ennuyeux. J’ai donc appliqué cette étape.

3. Mise en place du serveur : configuration

Maintenant que tous les logiciels sont installés, nous allons avoir besoin d’un peu de configuration pour que tout cela fonctionne.

3.1 Configurer la feuille de style Mapnik

Pour que Mapnik utilise notre base de données et nos données côtières, il va falloir configurer la feuille de style avec nos paramètres locaux.

La configuration est spécifique à la feuille de style utilisée. Nous allons voir ici comment configurer la feuille de style par défaut d’OSM que nous avons installée précédemment.

Pour ce faire, il va falloir adapter des fichiers (qui sont des « templates », c’est à dire des sortes de modèles) pour en faire des fichiers directement exploitables.

Cela se fait en allant dans le répertoire inc. Nous copions les trois fichiers templates, pour en faire des .inc dont nous nous servirons.

$ cd ~/src/mapnik-style/inc
$ cp fontset-settings.xml.inc.template fontset-settings.xml.inc
$ cp datasource-settings.xml.inc.template datasource-settings.xml.inc
$ cp settings.xml.inc.template settings.xml.inc

Une fois ces copies réalisées, nous allons leur appliquer quelques modifications.

settings.xml.inc

Nous remplaçons :

<!ENTITY symbols "%(symbols)s">

par :

<!ENTITY symbols "symbols">

Nous remplaçons :

<!ENTITY osm2pgsql_projection "&srs%(epsg)s;">

par :

<!ENTITY osm2pgsql_projection "&srs900913;">

Nous remplaçons :

<!ENTITY dwithin_node_way "&dwithin_%(epsg)s;">

par :

<!ENTITY dwithin_node_way "&dwithin_900913;">

Nous remplaçons :

<!ENTITY world_boundaries "%(world_boundaries)s">

par  :

<!ENTITY world_boundaries "/usr/local/share/world_boundaries">

Nous remplaçons :

<!ENTITY prefix "%(prefix)s">

par :

<!ENTITY prefix "planet_osm">

Note : Si comme moi vous vous demandez ce que c’est que la projection 900913, remarquez que ce nombre correspond à « Google » en écriture « l33t ».

Il s’agit tout simplement de la projection EPSG:3857 qu’on trouve aussi (par exemple, dans QGIS) sous le nom « WGS84 pseudo Mercator » (à ne pas confondre avec « WGS 84 » tout court).

Autrement dit, il s’agit tout simplement de la projection habituellement utilisée par Google Maps et OpenStreetMap.

datasource-settings.xml.inc

Ce fichier va contenir les paramètres de connexion à la base de données. Comme PostgreSQL tourne sur la même machine que nos outils de rendu, nous pouvons nous contenter de commenter les paramètres « password », « host », « port » et « user » (avec des commentaires style HTML). Ainsi, mapnik utilisera l’utilisateur système (« osm ») pour s’authentifier.

Nous remplaçons « %(dbname)s » par la nom de notre base de données (« gis »), mettons « estimate_extent » à « false » et donnons à « extent » les valeurs « -20037508,-19929239,20037508,19929239 » si nous voulons le monde entier. Le fichier contient désormais ceci :

<!--
Settings for your postgres setup.

Note: feel free to leave password, host, port, or use blank
-->

<Parameter name="type">postgis</Parameter>
<!-- <Parameter name="password">%(password)s</Parameter> -->
<!-- <Parameter name="host">%(host)s</Parameter> -->
<!-- <Parameter name="port">%(port)s</Parameter> -->
<!-- <Parameter name="user">%(user)s</Parameter> -->
<Parameter name="dbname">gis</Parameter>
<!-- this should be 'false' if you are manually providing the 'extent' -->
<Parameter name="estimate_extent">false</Parameter>
<!-- manually provided extent in epsg 900913 for whole globe -->
<!-- providing this speeds up Mapnik database queries -->
<Parameter name="extent">-20037508,-19929239,20037508,19929239</Parameter>

Dans mon cas, ne voulant que la Franche-Comté, les valeurs que j’ai données à extent sont les suivantes : « 558827,5797669,820419,6127364 » (ouest, sud, est, nord).

fontset-settings.xml.inc

Ce fichier contient des informations concernant les polices. Pour l’instant, nous n’avons pas de raison d’y toucher.

3.2 Configurer renderd

Nous changeons les paramètres de renderd en éditant /usr/local/etc/renderd.conf. Nous modifions les lignes suivantes comme ceci :

socketname=/var/run/renderd/renderd.sock
plugins_dir=/usr/local/lib/mapnik/input
font_dir=/usr/share/fonts/truetype/ttf-dejavu
XML=/home/osm/src/mapnik-style/osm.xml
HOST=localhost

Par ailleurs, j’ai pu constater au premier lancement que certaines lignes commentées existant déjà dans le fichier étaient interprétées comme des erreurs de syntaxe (!). Je les ai donc supprimées. Il s’agissait des lignes suivantes :

;[renderd01]
;[renderd02]
;** config options used by mod_tile, but not renderd **
;[style2]
;** config options used by mod_tile, but not renderd **

Soient les lignes 7, 14, 33, 44 et 51.

Nous créons maintenant les fichiers nécessaires au fonctionnement de mod_tile :

# mkdir /var/run/renderd
# chown osm /var/run/renderd
# mkdir /var/lib/mod_tile
# chown osm /var/lib/mod_tile

3.3 Configurer mod_tile

Afin qu’Apache prenne en compte notre installation de mod_tile, il faut créer le fichier /etc/apache2/conf.d/mod_tile et y mettre cette ligne :

LoadModule tile_module /usr/lib/apache2/modules/mod_tile.so

Il faut ensuite modifier le fichier /etc/apache2/sites-available/default pour y ajouter, après l’adresse e-mail de l’administrateur, les lignes suivantes :

LoadTileConfigFile /usr/local/etc/renderd.conf
ModTileRenderdSocketName /var/run/renderd/renderd.sock
# Timeout before giving up for a tile to be rendered
ModTileRequestTimeout 0
# Timeout before giving up for a tile to be rendered that is otherwise missing
ModTileMissingRequestTimeout 30

3.4 Optimiser PostgreSQL

(Note : Ce paragraphe est là à titre d’information, car il est présent dans la documentation sur laquelle je m’appuie. Toutefois, comme la zone sur laquelle je travaille est relativement petite, et qu’en plus le nombre de clients est limité et la carte rarement mise à jour, j’ai sauté cette étape.)

Un serveur de tuiles peut souffrir de charges importantes. La configuration par défaut peut donc ne pas être appropriée, et d’importantes améliorations des performances peuvent être obtenues en modifiant quelques paramètres de configuration de PostgreSQL.

Pour ce faire, nous éditons le fichier /etc/postgresql/9.1/main/postgresql.conf et y appliquons quelques changements :

shared_buffers = 128MB
checkpoint_segments = 20
maintenance_work_mem = 256MB
autovacuum = off

Ces changements nécessitent une modification de la configuration du noyau, qui doit être appliquée à chaque fois que l’ordinateur redémarre. En root, nous éditons /etc/sysctl.conf et ajoutons ceci vers le début, après les autres paramètres commençant par « kernel » :

# Increase kernel shared memory segments - needed for large databases
kernel.shmmax=268435456

Nous redémarrons l’ordinateur et, en root, tapons :

# sysctl kernel.shmmax

Cela doit nous afficher 268435456.

4. Téléchargement des données

Voici le moment que tout le monde attendait : celui d’aller chercher les données d’OpenStreetMap.

Les données peuvent être obtenues sur http://planet.openstreetmap.org/. Comme le monde entier pèse environ 20 Go (compressé), il y a des liens permettant d’obtenir des zones plus petites (pays, régions…). Le format PBF est préférable pour travailler, car il est moins lourd et plus rapide à traiter.

Si l’on veut le monde entier, il suffit de taper les commandes suivantes :

$ mkdir ~/planet
$ cd ~/planet
$ wget http://planet.openstreetmap.org/pbf/planet-latest.osm.pbf

Pour ma part, je me contenterai de la Franche-Comté, disponible chez Geofabrik.

$ mkdir ~/franchecomte
$ cd ~/franchecomte
$ wget http://download.geofabrik.de/europe/france/franche-comte-latest.osm.pbf

5. Importation des données

Nos outils sont compilés. Notre base de données est prête. Nos données sont téléchargées. Il ne reste plus qu’à importer ces dernières, à l’aide des premiers, dans la seconde.

Attention : cette étape est très gourmande en ressources (entrées-sorties disque). Pour la planète entière, elle prendra entre une dizaine d’heures et plusieurs jours, selon la rapidité du serveur sur lequel vous travaillez.

Pour de plus petits extraits, ça sera bien évidemment plus rapide. La Franche-Comté m’a pris 11 minutes sur un serveur Xeon 3 GHz 4 cœurs avec 4 Go de RAM (et lors d’autres tests : 36 minutes sur un Pentium IV 2,66 GHz avec 1 Go, et 1h sur un Pentium IV 1,7 GHz avec aussi 1 Go, donc une machine un peu datée peut suffire pour des tests sur des petites zones…).

Attention à la valeur de l’option -C. Cette option sert à spécifier la quantité de RAM (en Mo) qui pourra être utilisée pour mettre en cache les nœuds et donc accélérer l’import. D’après le manuel d’osm2pgsql, il est conseillé de s’approcher le plus possible de la RAM disponible.

Sur mon serveur, la commande free m’indique que j’ai 3543 Mo disponible, buffers et cache exceptés. Je décide donc de spécifier 3200.

$ osm2pgsql --slim -d gis -C 3200 --number-processes 3 ~/franchecomte/franche-comte-latest.osm.pbf

Nous avons largement le temps de regarder ce qui s’affiche au fur et à mesure de l’import. Les premiers messages peuvent faire un peu peur au premier abord, mais ils sont tout à fait normaux. Ils sont simplement dûs au fait que nos tables n’existent pas encore. Mais elles vont être créées.

Using projection SRS 900913 (Spherical Mercator)
Setting up table: planet_osm_point
NOTICE: table "planet_osm_point" does not exist, skipping
NOTICE: table "planet_osm_point_tmp" does not exist, skipping
Setting up table: planet_osm_line
NOTICE: table "planet_osm_line" does not exist, skipping
NOTICE: table "planet_osm_line_tmp" does not exist, skipping
Setting up table: planet_osm_polygon
NOTICE: table "planet_osm_polygon" does not exist, skipping
NOTICE: table "planet_osm_polygon_tmp" does not exist, skipping
Setting up table: planet_osm_roads
NOTICE: table "planet_osm_roads" does not exist, skipping
NOTICE: table "planet_osm_roads_tmp" does not exist, skipping
Mid: pgsql, scale=100, cache=4096MB, maxblocks=524289*8192
Setting up table: planet_osm_nodes
NOTICE: table "planet_osm_nodes" does not exist, skipping
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "planet_osm_nodes_pkey" for table "planet_osm_nodes"
Setting up table: planet_osm_ways
NOTICE: table "planet_osm_ways" does not exist, skipping
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "planet_osm_ways_pkey" for table "planet_osm_ways"
Setting up table: planet_osm_rels
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "planet_osm_rels_pkey" for table "planet_osm_rels"

Ensuite, osm2pgsql va lire notre fichier à importer.

Reading in file: /home/osm/franchecomte/franche-comte-latest.osm.pbf

Au fur et à mesure de la lecture, osm2pgsql indique où il en est. C’est très important lorsque l’on importe toute la planète et que cela prend plusieurs heures ou jours. Dans mon cas, cela n’a duré que trois minutes.

Processing: Node(10140k 200.1k/s) Way(0k 0.00k/s) Relation(0k 0.00/s)

En raison d’erreurs mineures pouvant exister dans les fichiers PBF, des exceptions comme celles-ci peuvent apparaître. Elles sont sans importance pour la suite. Pour ma zone, je n’en ai pas eu.

Processing: Node(593072k) Way(45376k) Relation(87k)
Exception caught processing way id=110802
Exception caught processing way id=110803
Processing: Node(593072k) Way(45376k) Relation(474k)

L’importation se termine par cette phrase.

Osm2pgsql took 664s overall

Bien sûr, 664 secondes c’est pour la Franche-Comté sur mon serveur avec 4 Go de RAM. Vous aurez compris que cela risque d’être beaucoup plus important pour vous si vous importez des zones plus vastes voire le monde entier.

6. Démarrage du serveur

Maintenant que tout est installé, configuré et chargé, il est temps de démarrer notre serveur. On va commencer par le faire manuellement, juste pour vérifier que tout fonctionne bien.

$ renderd -f -c /usr/local/etc/renderd.conf

Et dans un autre terminal, en root :

# /etc/init.d/apache2 restart

Si une erreur fatale apparaît, nous n’avons plus qu’à revérifier toute la procédure.

Sinon, tout va probablement bien. Pour le vérifier, nous appelons http://notreserveur/osm_tiles/0/0/0.png pour voir si une petite image du monde apparaît. Si comme moi vous n’avez pris que les données d’une petite région, cette image ne contiendra probablement rien, à part une couleur unie (celle des océans).

Si cela a fonctionné, nous pouvons stopper le processus renderd que nous avons lancé manuellement (ctrl-C) et faire le nécessaire pour qu’il démarre désormais automatiquement.

# cp /home/osm/src/mod_tile/debian/renderd.init /etc/init.d/renderd
# chmod u+x /etc/init.d/renderd

Editez nous éditons le fichier /etc/init.d/renderd en root, pour changer les lignes suivantes de cette façon :

DAEMON=/usr/local/bin/$NAME
DAEMON_ARGS="-c /usr/local/etc/renderd.conf"

Nous remplaçons également l’utilisateur www-data par l’utilisateur que nous avons créé (osm, dans mon cas).

Ensuite, nous démarrons renderd de la façon suivante :

# /etc/init.d/renderd start

Les logs sont dorénavant envoyés dans /var/log/syslog plutôt que sur le terminal.

Enfin, nous ajoutons un dernier lien pour automatiser le démarrage :

# update-rc.d renderd defaults

Nous redémarrons notre serveur, et rechargeons http://notreserveur/osm_tiles/0/0/0.png. Tout doit fonctionner ! Nous pouvons également tester la page http://notreserveur/mod_tile où nous trouvons quelques statistiques à propos de notre serveur de tuiles.

7. Gestion des mises à jour

Mirrorer OSM, c’est bien, mais encore faut-il mettre à jour pour que cela garde son intérêt.

Après m’être penché sur la question, je retiens deux solutions.

Plus votre base de données est petite, et plus vos mises à jours sont rares, et plus il est pertinent d’utiliser la méthode la plus simple : retélécharger l’export que vous avez utilisé, mis à jour, et le réimporter avec osm2pgsql (qui, par défaut, écrasera l’ancien).

Dans mon cas, cela revient à exécuter les commandes suivantes (la dernière servant à vider le cache des tuiles)  :

$ cd ~/franchecomte
$ rm franche-comte-latest.osm.pbf
$ wget http://download.geofabrik.de/europe/france/franche-comte-latest.osm.pbf
$ osm2pgsql --slim -d gis -C 3200 --number-processes 3 ~/franchecomte/franche-comte-latest.osm.pbf
$ rm -rf /var/lib/mod_tile/default/*

À l’inverse, si vous avez une grosse base de données et souhaitez la mettre à jour souvent, privilégiez plutôt la méthode des diffs.

Malheureusement pour certains lecteurs, je ne vais pas me pencher sur celle-ci pour l’instant, car après avoir commencé à le faire et constaté que cela était un peu complexe, j’ai découvert que je n’en avais pas besoin. En effet, la Franche-Comté n’est pas énorme et, surtout, il n’est pas prévu que je mette à jour bien souvent (une fois de temps en temps, en fonction de mes besoins…).

Si un jour j’en ai besoin, j’écrirai quelque chose sur le sujet.

Conclusion

Nous avons désormais un miroir local des données d’OpenStreetMap (ou d’une zone donnée), qui nous permet de générer des tuiles que nous pouvons utiliser à notre guise.

Sur le schéma du début de l’article, cela correspond au carré pointillé comprenant des éléments en jaune.

Par contre, vous l’aurez compris, cela n’est pas encore suffisant pour avoir sur notre serveur une carte utilisable et navigable accessible depuis un simple navigateur. Pour cela, il nous faudra, par exemple, réaliser une page web utilisant une bibliothèque comme OpenLayers ou Leaflet.

Mais cela ne fait pas l’objet du présent article, car pour l’instant je n’ai pas ce besoin : en effet, le serveur que je viens de réaliser va être utilisé par une application interne à une entreprise, qui est déjà développée et inclut déjà OpenLayers. Il suffira de modifier une ligne de code dans celle-ci pour utiliser mon serveur au lieu de ceux d’OSM par défaut.

Mais j’en profite pour signaler que, pour que cette application accepte mon serveur (et après test, c’est valable pour tout ce qui utilise OpenLayers), nous avons dû faire une dernière modification sur celui-ci, afin d’ajouter une ligne d’en-tête aux requêtes.

Nous avons dû en effet éditer le fichier /etc/apache2/sites-available/default pour y ajouter, près des lignes que j’avais précédemment ajoutées, la ligne suivante :

Header set Access-Control-Allow-Origin "*"

Puis, nous avons ajouté le module headers à Apache grâce à la commande suivante :

# a2enmod headers

C’est terminé.

Ce contenu a été publié dans Astuces, Informatique, Internet. Vous pouvez le mettre en favoris avec ce permalien.

22 réponses à Créer son propre miroir des données OpenStreetMap et un serveur de rendu des tuiles, avec Debian Wheezy

  1. Lann dit :

    Merci pour cette explication que je garde dans un coin.
    Une question tout de même :
    Est-ce que la base de données va se mettre à jour avec les dernières données ajoutées ?
    Si non, y-a-t-il une solution (Fichiers diff)?

    Merci

    • Adrien dit :

      Si on se contente de suivre la procédure que je décris dans cet article, il n’y aura aucune mise à jour.

      Je n’ai pas encore planché sur la question des mises à jour, mais j’attaque ça dès la semaine prochaine et il y aura donc un article sur le sujet.

      La procédure s’appuiera très probablement sur des fichiers diffs, en effet. C’est l’une des raisons pour lesquelles j’ai choisi de prendre toute la Franche-Comté sur Geofabrik, pour laquelle il existe des diffs, plutôt que de me limiter à la zone exacte dont j’avais besoin.

      J’ai modifié l’article pour parler des mises à jour. C’est succint mais pour l’instant je ne vais pas aller au delà car je n’en ai pas le besoin.

      • Etienne dit :

        Les diffs peuvent se découper si besoin (osmosis, …)

        • Adrien dit :

          Ah oui, c’est vrai. Tu me l’avais dit.

          C’est marrant : pas mal de monde m’avait pourtant dit qu’il n’était pas possible de faire ses propres diffs d’une zone donnée. Alors qu’il suffirait effectivement de découper un diff existant avec Osmosis…

          Peut-être qu’ils confondent télécharger un diff d’une zone donnée (impossible), et faire soi-même le diff de cette zone en découpant un diff plus grand existant (possible, selon toi).

    • Adrien dit :

      J’ai mis à jour mon article pour aborder succintement la question des mises à jour.

      En fait, pas besoin de diffs dans mon cas.

  2. Pan dit :

    Salut,
    J’ai suivi ton tuto et merci beaucoup. Je voudrais juste vérifier une chose.
    Quand je fais « renderd -f -c /usr/local/etc/renderd.conf », j’ai:
    ………
    renderd[26623]: Starting stats thread
    renderd[26623]: Using web mercator projection settings
    renderd[26623]: Using web mercator projection settings
    renderd[26623]: Using web mercator projection settings
    renderd[26623]: Using web mercator projection settings

    et il quitte pas. C’est normal ou pas? Est-ce que c’est la raison pour laquelle on doit ouvrir un autre terminal?
    Je sais pas si c’est un problème parce que d’après ce que j’ai compris, si l’on voit « Starting stats thread », ça marche.

    • Adrien dit :

      Désolé, je ne suis pas très rapide pour répondre aux commentaires.

      C’est normal qu’il ne quitte pas lorsqu’on lance renderd manuellement. Lorsqu’il est lancé ainsi, il tourne et ne rend pas la main tant qu’on ne l’a pas arrêté. Pour l’arrêter, il faut faire ctrl-C.

      Mais ça, c’est juste un moyen de tester. Après, il faut faire comme expliqué dans la suite du tuto pour que son lancement devienne automatique.

  3. RomainRogo dit :

    Bonjour, j’ai suivi le tutoriel et tout fonctionne bien. J’ai installé Leaflet de mon côté.
    J’ai une adresse de serveur qui me renvoie bien les données que je souhaite (du type http://175.xx.xx.xx/osm/romain.html)
    Je souhaite maintenant paramétrer un service WMS. Avez vous des informations sur ce point ? Il semble que Leaflet puisse gérer cela avec des lignes à ajouter au fichier html :
    var mywms = L.tileLayer.wms(« http://172.xx.xx.xx/osm/romain.html/planet_osm_roads/wms », {
    layers: ‘planet_osm_roads’,
    format: ‘image/png’,
    transparent: true,
    version: ’1.1.0′,
    attribution: « myattribution »
    });
    mywms.addTo(map);

    Je ne comprends pas bien cette partie WMS. Si vous avez des bons tutos, je prends, merci d’avance.

    • Adrien dit :

      Désolé. Je n’ai pas la moindre base en la matière.

      J’apprends en général en fonction de mes propres besoins, et j’écris des articles à mesure que j’apprends, pour en garder une trace. Or, je n’ai pas encore eu besoin d’installer un service WMS.

  4. Mat dit :

    Bonjour et merci pour ce tuto nickel !
    Cependant je ne parviens pas à installer mod_tile. make me renvoie toujours :
    Makefile:359: *** séparateur manquant. Arrêt.
    J’ai trouvé ça : https://github.com/openstreetmap/mod_tile/issues/84 mais cela ne m’aide pas.
    Avez-vous une idée du problème ?
    Par avance merci,
    Mat.

    • Adrien dit :

      Pas de solution toute faite. Jamais eu le souci. Mais j’irais déjà voir la ligne en question dans le Makefile pour voir ce qui coince.

  5. Mat dit :

    Bonjour,
    ayant trouvé la solution j’ai bien évidemment oublié de revenir la partager… Désolé.
    Il n’y a rien à faire dans le Makefile, ça bloque à tous les coups…
    La version 2.0 de mapnik est tout simplement beaucoup trop veille (plus de 3 ans).
    Il suffit donc de compiler et d’installer la version 2.2 de Mapnik et tout fonctionne à merveille. Tout le reste du tuto reste valide et fonctionnel.
    @+
    Mat.

    • Adrien dit :

      Merci pour ce retour. La prochaine fois que j’applique le tuto, je teste ta solution et modifie mon article en conséquence.

      Par contre, je garantis qu’en juin j’ai installé trois miroirs avec ce tuto, en copiant-collant les commandes (en plus du premier miroir que j’ai fait en rédigeant le tuto), et ça a marché à chaque fois.

      Étrange que tu aies eu cette erreur.

  6. Xavro dit :

    Bonjour…super Tuto !!
    Merci, et encore d actualité…sur debian 7 et script leaflet côté client.
    Cependant j ai bien importé une partie de carto, elle s affiche bien mais tout le fond de carte est bleu…noyé dans les océans.
    Problème d import ou de configuration ?
    Merci

  7. Robert dit :

    Bonjour,
    je vais tester une installation de ce type donc merci pour le tuto.
    Juste une petite question, j’ai vu qu’osm pouvait avoir des api pour obtenir la géolocalisation d’une adresse et la distance entre 2 points de géolocalisations par exemple. L’installation de ce serveur peut-il répondre aussi à ce besoin ?

    Un grand merci à l’auteur

  8. Bonjour
    Je suis à la recherche d’une solution pour parvenir à ce résultat :
    -afficher depuis un serveur distant des données osm sur une zone précise
    -lors d’un zoom de l’utilisateur, revenir automatiquement au serveur osm « réel ».
    Votre tutoriel donne beaucoup d’infos permettant de construire un serveur, mais en interne (comme vous l’expliquez, c’est en fonction de vos propres besoins).
    Pensez-vous possible de :
    -créer cette base sur un serveur distant (je pense à alwaysdata qui est bien équipé pour la carto)
    -générer des tuiles sur une zone perso
    -passer aux tuiles osm en sortie de cette zone perso ?
    Merci beaucoup !
    Cordialement
    CS

    • Adrien dit :

      Je doute que ça soit possible de manière simple.

      Créer la base sur un seveur distant, ça n’est pas un souci si c’est un dédié et qu’on a tous les droits pour tout installer. Dans le cas contraire, il faut voir avec l’administrateur ce qu’il est d’accord d’installer.

      Générer des tuiles sur une zone donnée, c’est possible. Il suffit de ne télécharger que la zone qui nous intéresse, comme je l’ai moi-même fait dans le tuto (le fichier Franche-Comté au lieu du monde entier).

      Par contre, limiter l’affichage à cette zone et passer aux serveurs officiels OSM au delà, je ne dis pas que ça n’est pas possible, mais je pense qu’il va falloir écrire du code vous-même. Ça m’étonnerait qu’OpenLayers propose ça, et je ne sais pas trop ce qui pourrait être utilisé à part OpenLayers.

      • Bonjour
        et merci de votre réponse.
        Je peux voir avec Alwaysdata ce qu’ils peuvent installer ; mais le vrai souci est le passage d’un serveur à l’autre !
        Je suis ennuyé : je pensais pour ma part que c’était une opération simple. Si je comprends bien, dans votre cas, pour votre besoin, l’extérieur de la zone n’a pas d’utilité, donc vous n’avez pas eu à faire face à ce problème…
        Pour vous expliquer rapidement mon objectif, il est simple : je veux créer une carto fictive à la place de la réelle, mais que le passage de cette « fiction » à la réalité ne soit pas visible (bien sûr la fiction est annoncée, ce n’est pas pour tromper).
        Il ne me reste plus (vu mon modeste niveau en prog.) qu’à créer une surcouche, par exemple avec Umap. Limité mais simple…
        Si jamais une idée vous vient, je suis preneur !
        Merci beaucoup.
        Cordialement
        CS

Répondre à Adrien Annuler la réponse.

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>