URL: https://linuxfr.org/users/gbetous/journaux/servir-ses-propres-tuiles-osm Title: Servir ses propres tuiles OSM Authors: gUI Date: 2020年11月21日T10:50:51+01:00 License: CC By-SA Tags: ubuntu, openstreetmap, osm et gps Score: 50 Salut les moule·e·s # Contexte Pour le boulot, j’avais besoin de représenter sur une carte les points d’implantation de nos produits. C’est un serveur interne avec très peu d’utilisateurs, quasiment pas d’accès concurrent (si on est 3 à s’en servir en même temps ce sera bien le bout du monde). Jusqu’à présent on faisait avec les cartes GoogleMaps. La représentation en elle-même est pas trop mal : on importe un CSV avec les coordonnées géographiques, on ajoute au CSV les colones qu’on veut, et ensuite on peut faire des règles de couleur des points en fonction des valeurs des colonnes. Là ou le bât blesse, c’est que je n’ai pas réussi à trouver d’API (payante ou pas) permettant de gérer ces cartes (ajouter des points, modifier les valeurs, etc.). Il en résulte pas mal d’opérations manuelles à chaque modification. J’ai donc décidé de regarder du côté de [OpenStreetMap](http://www.openstreetmap.org/) (OSM) pour le fond de carte. # Comment ça marche ## Applet En gros pour afficher quelques coordonnées GPS sur une carte OSM, il faut : – une page web à laquelle se connecter (dans mon cas c’est mon application qui propose quelques pages contenant une carte en encart) – sur la page utiliser un composant Javascript dédié ([Leaflet](https://leafletjs.com/) ou [OpenLayer](https://openlayers.org/) sont les deux stars) – donner à ce composant l’URL d’un serveur de tuiles pour qu’il télécharge les tuiles En effet le calcul du rendu n’est pas fait par le client à partir de données géographiques, mais par un serveur qui a pré-calculé (ou pas, nous y reviendront) des morceaux de la carte : les tuiles. ## Tuiles Ces tuiles sont donc une image au format [PNG](https://fr.wikipedia.org/wiki/Portable_Network_Graphics) généralement de 256x256 pixels et sont désignées par une coordonée à 3 valeurs : Z, X et Y. L’URL finale d’une tuile est sous la forme : https://url_de_votre_serveur/tiles/{z}/{x}/{y}.png Z est un niveau de zoom, X et Y sont des coordonnées (absices et ordonnées) dans ce niveau de zoom. ## Zoom Au niveau zéro de zoom, toute la carte du monde est représentée par une seule tuile, aux coordonnées X=0 et Y=0. La tuile {Z=0,X=0,Y=0} : ![Zoom 0](https://a.basemaps.cartocdn.com/light_all/0/0/0.png) Au niveau de **zoom 1**, la carte du monde est coupée en **4 tuiles**, les coordonnées étant {Z=1,X=0,Y=0}, {Z=1,X=0,Y=1}, {Z=1,X=1,Y=0}, {Z=1,X=1,Y=1} | --------|-------- ![image](https://a.basemaps.cartocdn.com/light_all/1/0/0.png) | ![image](https://a.basemaps.cartocdn.com/light_all/1/1/0.png) ![image](https://a.basemaps.cartocdn.com/light_all/1/0/1.png) | ![image](https://a.basemaps.cartocdn.com/light_all/1/1/1.png) Au niveau de **zoom 2**, la carte est coupée en **16 tuiles**, X et Y variant de 0 à 3, et ainsi de suite. Au niveau de **zoom 18** (qui est par défaut le plus gros niveau de zoom calculé, mais monter à 20 reste assez courant), il faut 4^18 soit environ **68 milliards** de tuiles pour représenter le monde. Au passage, le calcul qui, à partir d’une coordonnée GPS et un niveau de zoom donne les coordonnées X et Y de la tuile est assez chiadé : la représentation utilisée étant une [projection de Mercator](https://fr.wikipedia.org/wiki/Projection_de_Mercator), un pixel ne représentera pas la même distance au niveau de l’équateur ou aux pôles. Je vous laisse vérifier tout ça [ici](https://wiki.openstreetmap.org/wiki/Slippy_map_tilenames). # Trouver un fond de carte Assez rapidement je me rends compte de la chose suivante : autant sur OpenStreetMap les données géographiques sont librement téléchargeables (par exemple vous pouvez [télécharger ici](https://download.geofabrik.de/europe/france/) les données récentes de votre région française préférée, ou même l’[intégralité](https://planet.openstreetmap.org/) des données OSM), autant pour les tuiles, c’est un peu plus compliqué. En effet, les ressources demandées étant assez importantes, très peu d’organismes permettent à n’importe qui d’utiliser leurs cartes. On trouve des fournisseurs (par exemple [OpenStreetMapFr](https://www.openstreetmap.fr/)) mais rapidement une lecture des conditions d’utilisation des différents fournisseurs montre que si pour une utilisation personnelle il n’y a pas de problème, par contre, si le trafic doit être important, ou si on est dans un cadre pro, il faut soit payer une licence, soit aller voir ailleurs. Le mieux est donc de se monter un serveur de rendu, d’autant que mon outil étant destiné à un Intranet, éventuellement coupé de connexion Internet, ce peut être une excellente option. # Calculer son fond de carte Je commence à chercher et c’est un peu compliqué. Il faut une base de donnée dans laquelle on injecte les données géographiques téléchargées, [Mapnik](https://mapnik.org/) qui est une application de rendu, mettre tout ça sur un serveur Apache avec le module [mod_tile](https://github.com/openstreetmap/mod_tile). De plus Mapnik a besoin d'une [feuille de style](https://github.com/gravitystorm/openstreetmap-carto) décrivant les couleurs, les types de traits, les informations à afficher (en fonction des zooms) etc. Une idée de la variété de rendus possibles est disponible sur cette [jolie page](http://leaflet-extras.github.io/leaflet-providers/preview/). Une fois une tuile calculée, elle est stockée sur le disque du serveur, et elle sera ainsi resservie directement au prochain appel. On ne sollicite donc Mapnik qu’une fois par tuile (mais pour rappel, les tuiles étant différentes à chaque niveau de zoom, pour un même quartier on peut finir à calculer plusieur dizaines de tuiles). ## Switch2OSM En ayant à peu près compris l’enchaînement et en commençant à me documenter je trouve rapidement le site qu’il me fallait : [Switch2OSM.org](https://switch2osm.org/). Ce site destiné à promouvoir l’utilisation de OSM explique [pas à pas](https://switch2osm.org/serving-tiles/) comment monter son serveur de tuiles. Plusieurs bases sont proposées : – ubuntu 20.04 LTS (celle qui j’ai choisi) – ubuntu 18.04 LTS – ubuntu 16.04 LTS – une image Docker Les explications sont à jour, il faut suivre exactement la recette, et en quelques (dizaines de) minutes j’ai mon serveur de tuiles sur pied. ## Ressources Au niveau des ressources, on ne peut pas dire que j’ai utilisé un foudre de guerre : j’ai sorti d’un placard un PC à base de [i7-6700](https://ark.intel.com/content/www/fr/fr/ark/products/88196/intel-core-i7-6700-processor-8m-cache-up-to-4-00-ghz.html) avec 16Go de RAM et un SSD de 120Go sur lequel j’ai mis Proxmox pour maquetter tout ça. Ce serveur servira à tout mon projet : – Une VM (base Debian10, 4Go de RAM) sur laquelle va tourner mon application de gestion de nos produits. Une BdD locale et une application que je développe en Python – Une VM destinée à servir les tuiles OSM (base Ubuntu 20.04 LTS donc), avec 8Go de RAM C’est reparti pour un nouveau suivi (à la lettre, j’insiste, j’ai essayé de moufter, j’aurais pas dû) des instructions de Switch2OSM sur cette nouvelle VM. ### CPU/RAM Les premiers essais sont concluants : côté RAM et CPU, ça ira. On est loin de l’instantané (le calcul d’une tuile met quelque chose comme 5 à 10 secondes), mais une fois les tuiles les plus utilisées calculées, c’est très fluide côté client. Comme précisé en préambule, il y a très peu de traffic de prévu, usage interne uniquement... ça ira quoi. Par contre niveau espace disque, il va falloir voir plus grand. ### Disque Oui là c’est un peu compliqué, et mes 120Go ne suffiront pas. Lors du déroulé de la recette Switch2OSM, on utilise des régions du monde avec peu de données, comme la carte de l’Azerbaïdjan par exemple. Cela permet d’aller assez vite et de voir rapidement un résultat (et que tout fonctionne) : – taille du fichier télécharge : 24Mo – temps d’importation : 2 minutes (de mémoire) – taille de la base de donnée : je n’ai pas regardé (naïf, je ne me posais même pas la question) Une fois ceci fait, je suis parti pour ajouter la carte de Midi-Pyrénées (nos principales implantations actuelles): – taille du fichier téléchargé : 258Mo – temps d’importation : 20 minutes (de mémoire) – taille de la base de donnée : 8.8Go Ah quand même... non parce que je veux tout simplement faire la France (métropolitaine) entière. Pour la France : – taille du fichier téléchargé : 3.7Go – temps d’importation : ça a planté (plus d’espace disque) (si on fait une interpolation sur la taille du fichier téléchargé, on partirait sur 4-5h) – taille de la base de donnée : la même interpolation donnerait 120Go Pour info, le monde entier : – taille du fichier : 54Go – temps d’importation : compter 3 jours – taille de la base de données : 1.8To ? Et les tuiles ? Eh bien l’espace pris sera donc dépendant des zones visitées par les utilisateurs puisque ce n’est que le cache de ce qui a été demandé. Là, en ayant largement couvert la région Toulousaine, je ne suis qu’à 150Mo de tuiles pré-calculées. Donc ce n’est pas vraiment ça qui compte dans l’usage de l’espace disque, en tous cas dans mon cas. D’ailleurs OSM a une page sur ce sujet [sur son Wiki](https://wiki.openstreetmap.org/wiki/Tile_disk_usage) (attention, les chiffres datent de 2015), et il est amusant que constater que jusqu’aux niveaux de zoom 12 (voire 13), toutes les tuiles ont été calculées, par contre au niveau de zoom 18, c’est seulement 0,2% de tuiles possibles qui ont été téléchargées. Oui, on comprend facilement que personne n’est encore allé zoomer au maximum sur l’océan Pacifique ni sur les steppes d’Asie centrale. # Conclusion Va falloir demander une rallonge :), mais simplement sous la forme d’un espace de stockage. Avec 1To je devrais être tranquille pour servir la carte de France, et même un peu plus. Même si les débits demandés ne sont pas gigantesques, un SSD serait tout de même recommandé pour la multitude de petits accès qui y seront faits. Et à 100€ HT environ le cours actuel on ne va pas se gêner. Servir ses propres cartes OSM ce n’est finalement pas compliqué quand on est bien guidé, et c’est le cas avec Switch2OSM. Cela permet notamment de s’affranchir de la dépendance de fournisseurs tiers (GoogleMaps, mais aussi les différents fournisseurs de fond de carte OSM), mais aussi éventuellement de ne pas être dépendant de la disponibilité d’une connexion Internet. Une autre utilité sera de gérer exactement ce qui est affiché ou pas, ce qui sera le cas : je suis parti sur la feuille de style officielle OSM et on voit donc apparaître les commerces par exemple, qui n’ont rien à faire dans mon cas d’usage.

AltStyle によって変換されたページ (->オリジナル) /