Mapocalypse : Migrer depuis Google Maps, Maintenant (2/2)

Si vous avez manqué le début:

Le 16 Juillet, Google Maps change ses pricings.
On ne parle pas d’une augmentation de 10%.
On parle d’un changement d’ordre de grandeur. Des quotas gratuits divisés par 30, des prix Pay-as-you-Go qui flambent (x14 sur le géocodage par exemple), bref, c’est la Mapocalypse.

Après quelques semaines d’échanges avec de nombreuses personnes, je m’essaye à écrire pour partager notre analyse de ce qu’il s’est passé, et vous aider à répondre à la question: Quelle alternative?

Dans le précédent article, il était question de la stratégie de Google Maps, et de pourquoi nous en sommes là. Aujourd’hui, on rentre dans le vif du sujet: quelles alternatives choisir pour mes différents services?

“Quoi? Mais non, la map c’est gratuit…”

Depuis quelques semaines, le téléphone ne cesse de sonner… Forcément, grâce à l’annonce de Google, on redevient visible sur un marché qui était difficilement intelligible pour les acteurs du digital (web et mobile).

Forcés de réaliser que la carte est un service à part entière (et souvent au coeur de son expérience), les entreprises commencent à faire leurs comptes.

Les services de maps que vous utilisez?

En fait, il se cache plusieurs métiers bien distincts avec la map. Très souvent, on retrouve les suivants:

  • Les fonds de cartes: tout ce qui nous permet d’afficher une map sur un site ou une app mobile
  • Les APIs géo-spatiales: l’API me permettant de servir les données (métier) que je souhaite au dessus de ma carte
  • Le géocodage: l’annuaire inversé qui me permet de trouver une {latitude, longitude} à partir d’un lieu, d’une adresse, d’une ville, etc…
  • Le routing: comment aller d’un point A à un point B? En voiture? A vélo? A moto? A pied? Mais aussi quelle est mon centre le plus proche du point X (matrix API)?

Allez, accroche ta ceinture, c’est parti

Un mot sur OpenStreetMap

Pour dessiner une carte, ou chercher une adresse, on a besoin de données. Beaucoup de données. Le cadastre, les rues, les points d’intérêt, les contours des régions, les administrations, etc…

Il y a 4 “bases de données” mondiales aujourd’hui (et plusieurs bases de données “nationales”): Google Maps, Here.com, TomTom, et OpenStreetMap.

Seule la dernière est OpenData.

Mais attends, OpenStreetMap ce n’est pas justement un provider de maps gratuites?

Eh bien non. OpenStreetMap c’est une base de données qui est maintenue par des dizaines de milliers de super contributeurs chaque minute. Voyez-le comme le Wikipédia de la carte, mais un peu plus spécialisé quand même ;-).

Les enjeux de la fondation OpenStreetMap sont de pouvoir donner le plus d’outils pour que leurs contributeurs puissent faire vivre ce jeu de données, afin que d’autres puissent développer et opérer des services en l’utilisant.

Parmi les outils, ils exposent notamment des flux de maps (qu’on appelle des tuiles) qu’ils ouvrent d’accès à tous. Attention cependant: ces flux ne sont pas destinés à être consommés à outrance. Ils sont en premier lieu un outil de visualisation pour les contributeurs. La communauté appréhende cette ruée vers le gratuit car elle risque d’en payer le prix.

Soyons clairs: La communauté OpenStreetMap n’a pas d’employé. Elle ne fournit pas de QoS, ne garantit pas son service, et n’a pas d’équipe qui surveille ses serveurs 24h/24. Ses serveurs sont opérés par des passionnés, généralement sur du matériel prêté ou donné par des hébergeurs ou sympathisants, et disponibles en l’état.

Mais attends Jean-Luc, moi tout le monde me dit de passer sur OpenStreetMap!

En fait, ce que tout le monde essaye de dire, c’est de passer sur un service “basé” sur les données OpenStreetMap. Parce que des entreprises (comme Mapbox, comme Carto, comme Jawg Maps) ont créé des services business-grade qui utilisent cette donnée en principale datasource.

Les fonds de carte

Avant:

  • Web: Google Maps Javascript API
  • Mobile: Google Maps SDK

Remplacé par:

  • Web: Leaflet | OpenLayers | Mapbox-GL-js
  • Mobile: Mapbox-GL-native
  • Tous: + Un fournisseur de flux de tuiles

Rassurez vous, le fond de carte est LA feature qui est au moins aussi bien implémentée que Google Maps.

Pour afficher une carte, il faut toujours:

  1. Une librairie (APIs et un client) pour ajouter vos géométries, et piloter votre carte: gérer les niveaux de zooms, etc…
  2. Un flux de “tuiles” (petites portions de carte) pour le fond de cartes

Avant, avec Google Maps, tout ça c’était mélangé et closed source.

Deux bonnes nouvelles:

  1. Les librairies de l’écosystème OpenStreetMap sont toutes Opensource et ont du coup au moins autant de features que celles de Google Maps. D’ailleurs, elles en ont souvent beaucoup plus!
  2. Le tile-provider (fournisseur du flux de tuiles) est dissocié de la librairie. Ca veut dire pas de vendor-lock! Vous pouvez tout à fait changer de fournisseur demain sans rien n’avoir à changer d’autre qu’un lien.

Quelle librairie choisir? C’est un beau débat, l’histoire est ici, et voici nos recommandations:

  • Si vous aimez la torture, que vous supportez encore IE8 ou tout navigateur qui ne supporte pas WebGL, vous ne pourrez pas avoir de maps vectorielles. A ce moment là, on recommande Leaflet.
  • Si vous voulez une expérience plus smooth, économiser des tuiles, et sauver des chatons, tentez plutôt Mapbox-GL-js.
  • Pour le mobile, la seule alternative intéressante et bien maintenue est Mapbox-GL. Libs natives Android, iOS, et React Native.

Et comme fournisseur? Mapbox ou Jawg Maps! (Je n’en dirai pas plus sur le sujet car je manque d’objectivité ;-) )

Les APIs géo-spatiales

Avant:

Chez vous

Après:

Pareil

Si tout se passe bien, vos APIs géo-spatiales ont toujours été gérées par vous et stockées chez vous. A priori, cela n’est pas voué à changer. Si vous avez des soucis de performance sur ces APIs ou que vous vous interrogez sur les solutions pour gérer de la géo-data de manière optimale, eh bien c’est un autre débat (je lis la déception sur vos visages). Mais n’hésitez pas à m’envoyer un mail ou un Tweet pour qu’on en discute!

Le géocodage

Le géocodage est un métier pour le moins… à part.

D’ailleurs, c’est aussi un mélange de plusieurs métiers: Auto-complétion, géocodage, reverse-géocodage, analyse sémantique etc…

Si vous devez passer un peu de temps à réfléchir sur un sujet, c’est bien celui-ci. Pourquoi?

Parce que le géocodage est toujours une problématique qui n’a pas été complètement résolue par les communautés OpenSource. Pourquoi?

  • Parce que l’on n’a pas de Google Cars qui déambulent les routes pour mettre toutes les données dans un référentiel structuré
  • Parce que c’est un beau challenge d’engineering: Une adresse, ça ne veut pas dire la même chose pour tous. Au Japon, il n’y a pas d’adresses. En France, on met les numéros avant la rue. Aux USA, on cherche souvent des intersections plutôt qu’une adresse (5th avenue & 44th street). Bref, l’analyse sémantique devient complexe dès l’instant où le géocodage sort du contexte national.

Je vous propose la grille d’analyse suivante, selon les usages:

Je géocode uniquement des adresses (pas des lieux) sur la France

=> Utilisez l’excellente API d’adresses data-gouv, opérée par Etalab et basée sur Addok. Attention aux limites d’utilisation de l’API

Je géocode des adresses via un géocodage structuré dans le monde

Un géocodage structuré, c’est un géocodage où l’on n’a pas besoin d’analyse sémantique. Tous les formulaires demandant l’adresse, puis la ville, puis le code postal sont des géocodages structurés, à l’opposé du champ unique.

=> Utilisez les services de Jawg Maps ou de Geocode.earth (basés sur Pelias)

=> Utilisez les services de MapQuest (basés sur une solution propriétaire)

=> Utilisez d’autres services comme Google Maps, Bing, OpenCage, Mapbox, Here ou LocationIQ

Je géocode des villes du monde ou des localités via un champ unique avec autocomplétion

Ex: Chercher un médecin dans “Paris 14e”

=> Tous les services cités ci-dessus sont valables

=> Algolia Places est très bon sur ce créneau (attention, pas de rooftop precision)

Je géocode des adresses ou des lieux via de l’autocomplétion dans le monde

C’est le cas qui n’est pas encore bien géré par tout le monde. Aujourd’hui, le top 3 sur ce marché est (par ordre d’efficacité décroissante): Google, Bing, Here. Attention aux conditions d’utilisation!

Le routing

Aujourd’hui, la seule chose qu’on ne peut pas apporter par rapport à un Google Maps est la donnée temps-réel. Pour le reste, il existe d’excellentes alternatives.

=> Les APIs basées sur OSRM: Jawg Maps, Mapbox

=> Les APIs basées sur Valhalla: Mapbox

Ces APIs supportent notamment tout ce qui est Matrix search (le lieu le plus proche de l’endroit X parmi une liste fournie), et déplacement uni-modal selon un profil choisi: à pied, en voiture, en vélo.

Pour les APIs de transport, il n’y en a qu’une qu’on peut vraiment plébisciter, c’est celle de Navitia.io

En bref

Les échanges que nous avons eu ces dernières semaines avec des entreprises inquiétées par les changements de prix se veulent plutôt rassurants.

La migration d’un service de Google Maps vers un service tiers est en général une question de jours.

Le plus souvent, les usages sont très orienté Web et Mobile Maps, des usages qui sont aujourd’hui facilement remplaçables sans compromis, et même avec des gains significatifs sur les fonctionnalités (des SDKs mobiles notamment), ainsi qu’une plus grande liberté sur le choix du fournisseur de service.

Parfois, les usages avancés nécessitent de prendre un peu de temps avec “ceux qui savent” pour trouver le bon chemin. J’espère que ces quelques lignes sauront au moins vous orienter dans vos choix.

Excellente migration à tous, et n’hésitez pas à solliciter l’équipe de Jawg Maps qui sera heureuse d’écouter vos besoins et de vous accompagner dans vos réflexions pré ou post Mapocalypse.

— — —

A lire aussi:

Un article qui détaille les tenants et aboutissant du “quand faire mes propres tuiles”

A regarder aussi:

Le talk du Devoxx 2018 sur les Maps et la performance applicative (davantage orienté DevOps et performance que carto à proprement parler)