S'abonner au Flux RSS

mercredi, mai 7 2014

Monitorer OSRM

Avoir une application en production implique d'en assurer un monitoring de suivi afin de savoir si tout est au vert, cela permet de s'y mettre quand on a un système de qualité. Mais passons ces considérations philosogeek et revenons au sujet du jour à savoir le monitoring d'une instance OSRM, pour ma part j'utilise Nagios depuis de longues années et en suis toujours assez satisfait. J'ai pris un peu de temps ces derniers jours pour publier ma configuration sur le dépôt nagios-plugins-osrm.

Les appels API de base utilisent la fonction standard check_http cela permet de savoir si le service est up, mais sans analyse de la réponse.

En utilisant check_osrm_viaroute_result qui nécessite un check non standard (voir le README du dépôt) vous avez non seulement un retour sur le bon fonctionnement du service mais également sur les données retournée. Dans ce cas vous savez si OSRM trouve une route entre les deux points de coordonnées.

Dans la suite de cette publiucation je vais également prochainement publier mes sondes pour Nominatim.

mardi, novembre 26 2013

Test de GraphHopper

GraphHopper est outil de routage comme OSRM qui a été traité dans un précédent billet.

La sortie hier la version 0.2 est l'occasion de tester ce nouvel outil, dont le développement a été commencé il y a un peu plus d'un an, et de le comparer à OSRM.

L'environnement de test est comme à mon habitude une distribution Debian, afin de minimiser le travail de déploiement on va se reposer au maximum sur les paquets. Graphhopper requiert une version 7 ou 8 de JRE, ce qui va nous obliger à utiliser la version testing aka Jessie, il faut tout d'abord installer le paquet default-jre.

apt-get install default-jre

La suite de la procédure décrite dans le Quickstart est claire et permet le lancement de GraphHopper après quelques récupérations de fichier en ligne dont jetty runner et le war de GraphHopper. La méthode de déploiement avec jetty runner est peu propice à une mise en production bien que fonctionnelle, j'ai bien essayé de déployer le .war avec Jetty ou Tomcat7 mais en vain, n'étant pas un expert java cela semble normal ; il sera sage d'attendre un peu de packaging autour de l'outil avant d'en envisager une exploitation sereine.

Le résultat obtenu diffère de OSRM qui ne fournit qu'une API quand GraphHopper propose une solution tout en un, on obtient directement une interface web interrogeable sur le port configuré (ici 8989), il est également possible d'interroger directement l'API sur l'url /api/route, pour un aperçu le résultat est identique à la démo en ligne. Basé sur Leaflet la fond de carte est agréablement complété d'un cadre matérialisant la bounding-box des données traitées.

Autre différence notoire est le temps de préparation des données, bien que l'on travaille directement avec des fichiers .pbf dans les deux cas sans passer par une base de données, GraphHopper comme osrm nécessite de construire les arbres de données. GraphHopper fait ceci directement lors du lancement quand osrm nécessite de passer par les étapes osrm-extract et osrm-prepare.

La différence majeure va venir du temps de précompilation, sur une machine avec 6 core, 12Gb de RAM et des disques SSD j'ai obtenu les résultats suivants. J'ai utilisé une première fois le fichier de la ville de Berlin et en second celui de la France, tous deux obtenus sur Geofabrik.

BerlinFrance
GraphHopper17 sec 32min
osrm37sec71min

Le résultat est assez net, le temps de précompilation des données est deux fois inférieur avec GraphHopper ce qui lui donne un avantage considérable pour qui voudrait mettre à jour ses données régulièrement sur une emprise de taille conséquente.

La prochaine étape sera de mesurer les temps de réponses des deux API, ce que je vais m'employer à faire rapidement avec Tsung, je publierai les résultats ici.

dimanche, juin 3 2012

Le routage avec OpenStreetMap

Dans l'ecosystème OpenStreetMap je n'avais pas encore testé le processus de Routage en général et encore moins le projet OSRM qui monte en ce moment. Actuellement en pleine phase de développement, la dernière version 0.3 n'en est pas moins utilisable. Ce billet sera un retour d'expérience sur l'installation et l'utilisation de ce projet, j'ai utilisé pour cela la version de développement disponible sur GitHub.

Installation

Plutôt que de décrire ici l'installation et la compilation d'OSRM j'ai mis à jour la partie Debian/Squeeze du wiki officiel.

Préparation des données

Les données OSM doivent être préparées et mises en forme pour que OSRM puisse les exploiter, c'est dans certes partie de formatage des données que OSRM tire sa rapidité dans les calculs d'itinéraires, vous pouvez vous en rendre compte en utilisant la démo officielle basée sur une base mondiale. Cette préparation se fait avec les commandes osrm-extract et osrm-prepare. Prenons pour exemple le fichier de la Croatie téléchargé depuis les exports de Geofabrik, la première commande sera :

./osrm-extract croatia.osm.pbf 

Cette commande d'extraction va générer 2 nouveaux fichiers dans le répertoire courant, croatia.osrm.names et croatia.osrm.restrictions, le deuxième sera utilisé de suites pour la préparation des données :

./osrm-prepare croatia.osrm croatia.osrm.restrictions

Une fois ces 2 étapes passées nous avons les fichiers nécessaires à l'utilisation d'OSRM.

Optimisation des traitements

Comme de nombreux process lié à OSM la manipulation des données requiert de la RAM et de l'espace disque de façon significative, OSRM utilise un fichier temporaire qui peut rapidement dépasser la centaine de Giga Octets si vous travaillez sur les zones de la taille de l'Europe ou équivalent. Pour spécifier à OSRM où placer son fichier de travail temporaire créez un fichier .stxxl contenant la ligne :

disk=/home/tmp/stxxl,50000,mmap

qui indique, l'emplacement, la taille en Go et la méthode utilisée pour y accéder, pour plus de détails voir la page Running OSRM du wiki officiel. Enfin la prise en compte du fichier se fait par la déclaration d'une variable d'environnement :

export STXXLCFG=/home/www/osrm/Project-OSRM/.stxxl

Exécution du serveur

Nous avons nos fichiers, lançons le serveur. Le pararamétrage de celui-ci se fait dans le fichier server.ini, il est à noter que pour le moment le nom et l'emplacement de ce fichier n'est pas paramétrable, il est définit en dur dans [Routed.cpp| https://github.com/DennisOSRM/Project-OSRM/blob/master/routed.cpp#L95] on note la jeunesse du projet à ce genre de détail. Le fichier de configuration permet de définir :

  • le nombre de thread lancés
  • l'adresse IP d'écoute pour le démon
  • le port d'écoute

Il définit de même l'emplacement des fichiers de données qui ont été préparés lors des étapes précédentes :

  • hsgrData=/home/osrm-data/croatia.osrm.hsgr
  • nodesData=/home/osrm-data/croatia.osrm.nodes
  • edgesData=/home/osrm-data/croatia.osrm.edges
  • ramIndex=/home/osrm-data/croatia.osrm.ramIndex
  • fileIndex=/home/osrm-data/croatia.osrm.fileIndex
  • namesData=/home/osrm-data/croatia.osrm.names
  • timestamp=/home/osrm-data/croatia.osrm.timestamp

On note que le fichier de données original n'est pas utilisé pas OSRM, seuls les fichiers générés le sont. Il faut avant de se lancer dans du routage mondial s'attarder un peu sur le poids de ces fichiers. On est partit avec un fichier .pbf de 28Mo et on obtient :

24M     croatia.osrm.edges
53M     croatia.osrm.fileIndex
75M     croatia.osrm.hsgr
168K    croatia.osrm.names
11M     croatia.osrm.nodes
8.1M    croatia.osrm.ramIndex
8.0K    croatia.osrm.restrictions

Soit un total de 207Mo pour les 28 de départ, je vous laisse faire la règle de 3 adequat sur un full planet ! Mais une fois de plus le jeu en vaut la chandelle.

Utilisation

OSRM implémente en partie HTTP/1.1, l'interrogation se fait au travers de requête GET, les résultats sont renvoyés sous forme de fichier JSON, l'API est décrite sur la wiki dans la page Server API. Il existe 3 commandes à ce jour locate, nearest et viaroute qui servent respectivement à trouver le noeud le plus proche, identifier le noeud le plus proche sur une route, et obtenir le trajet entre 2 points. Je ne détaille pas le format JSON de retour obtenu, c'est très bien expliqué dans Server API. Un service web classique se basera donc sur 3 appels successifs, un premier pour trouver le point de départ en utilisant nearest, un appel pour le point d'arrivée également avec nearest et la route entre ces points avec viaroute. Il faut noter que le format de résultat de viaroute suit celui utilisé par Navengine de Cloudmade

Exemples de requête :

http://server:5000/nearest?52.555485441735&13.342227642887

http://server:5000/viaroute?loc=52.5,&13.34&loc=49.25,16.32

Pour la mise en forme de la route sur un fond de carte, viaroute renvoit un multiline encodé avec le polylinealgorithm de Google Maps. Un exemple de décodage en JS est disponible dans l'implémentqion OSRM-Web OSRM.RoutingGeometry.js

Normalement vous avez tout pour monter votre service de routage, je me suis fait pour ma part une rapide implémentaiton http://carto.quiedeville.org/osrm/. Basée sur une partie de l'Europe vous pouvez l'utiliser en gardant à l'esprit que c'est du POC, donc souvent ça bug.

Bilan

Projet jeune par son manque de packaging et de personnalisation dans l'utilisation, mais très prometteur. J'ai particulièrement apprécié la possibilité de faire du multi-modal route / ferry par exemple.