Réalisations

Nous réalisons des projets importants et complexes pour des clients exigeants (Mappy, Deezer, Too Good To Go...).

En réalisant des projets concrets, nous pouvons à la fois mettre en pratique notre expertise et nos valeurs, confronter notre expérience à celle d'autres professionnels, partager et élargir nos compétences.

Le client disposait d'un moteur de calcul d'itinéraires utilisé en production depuis de nombreuses années. Ce moteur devenait néanmoins difficile à maintenir et avait des temps de réponse trop longs, ce qui nécessitait une refonte complète.

On a d'abord choisi d'architecturer le nouveau moteur en plusieurs composants fonctionnels distincts et de faire tourner ces composants sur des serveurs indépendants et communiquant entre eux avec RabbitMQ. Cela a permis d'assurer à la fois la modularité du code et la scalabilité de la solution.

On a ensuite choisi Python pour tous les composants qui n'étaient pas sur le chemin critique en termes de performances, et de n'utiliser le C++ que pour les parties exigeantes en termes de CPU et d'empreinte mémoire.

Le projet consistait à développer un serveur web qui interroge différentes plates-formes de calculs d'itinéraires (routier, piéton, transports en commun, etc.) et les relaie au client sous un format unifié.

La première difficulté était de définir une API qui permette de rendre le service sur les différentes plates-formes clientes (web, iOS, Android) tout en restant simple, générique et évolutive.

La deuxième difficulté était d'obtenir des temps de réponse optimaux, ce qui a été résolu en utilisant un framework asynchrone, un composant d'accès rapide aux données et une architecture distribuée.

Les services d'affichage cartographique proposés par Google et OpenStreetMap sont fondés sur l'utilisation de tuiles, qui permettent de mettre en cache les données à plusieurs niveaux et de fournir des temps de réponse optimaux.

Le projet consistait à développer un serveur de tuiles proposant des fonctionnalités spécifiques tout en assurant des temps de réponse comparables à ceux des solutions standards.

L'architecture retenue s'est organisée de plusieurs composants:

  • Une base de données PostgreSQL/POSTGIS contenant les données cartographiques
  • Un moteur de rendu open-source (Mapnik) pour convertir les données cartographiques en images
  • Un cache applicatif
  • Un serveur web asynchrone
  • Un cache HTTP
  • Un répartiteur de charge

L'idée du projet était de créer un outil qui utilise la puissance de Python pour gérer la complexité des templates cartographiques de Mapnik.

Par ailleurs, le client souhaitait que le code soit mis à disposition de la communauté open-source, ce qui impliquait qu'il ne devait y avoir aucune dépendance à un composant propriétaire.

La solution retenue a été de mettre sur GitHub une application Django qui permet de développer facilement des templates Mapnik, en utilisant le rendu de n'importe quel serveur de tuiles, en prenant comme exemple Tilestache.

En utilisant son navigateur, l'utilisateur peut charger, modifier et sauvegarder son template et voir simultanément le rendu cartographique correspondant.

En interne, l'utilisation de cette cette application a permis d'accélérer considérablement la vitesse de création des templates.

Le client disposait d'un très grand volume de photos, qui devait devait subir régulièrement toute une chaîne de traitements automatisés.

Néanmoins, cette chaîne n'était pas complètement automatisée et, par ailleurs, il arrivait fréquemment qu'une des étapes échoue, ce qui obligeait à reprendre manuellement le traitement à l'endroit du dernier échec.

Le problème a été résolu en unifiant tout d'abord la manière dont les différentes tâches étaient définies et ensuite, en utilisant l'outil Python Luigi qui permet de gérer exactement ce type de problèmes.