Faut-il un nouveau OpenStreetMap ?

Dans le cadre de mon dernier projet open source Kamo.social, j'utilise une carte OpenStreetMap pour permettre aux utilisateurs de choisir des lieux où rencontrer des personnes. Afficher une carte avec Leaflet.js fut facile. En revanche, implémenter des fonctionnalités un peu plus avancées est une autre paire de manche.

Mise à jour du 10 avril 2018 : j'ajoute le lien vers le toot de l'article sur Mastodon afin que vous puissiez aussi lire les commentaires en réaction.

Le fonctionnement de Kamo.social est plutôt simple : les utilisateurs au moment de l'inscription enregistrent une liste de leurs centres d'intérêt ainsi que des lieux, (des bars et des cafés par exemple) où ils souhaitent rencontrer des personnes. Lorsqu'il y a suffisamment de personnes qui partagent les mêmes centres d'intérêts et les mêmes lieux, alors Kamo.social leur envoie un email pour les inviter à se rencontrer.

Le fonctionnement du service peut paraître simple et je pensais que je pourrais le développer en un mois, mais que nenni. Parmi les différents obstacles à franchir, et que j'ai mal estimés, celui de la cartographie avec OpenStreetMap est plus coriace que prévu.

Les problèmes rencontrés avec OpenStreetMap

Avant de m'atteler à cette tâche, je m'imaginais avoir seulement besoin d'afficher une carte OpenStreetMap avec Leaflet.js, puis avoir un plugin pour afficher les POI (Points of Interests ou points d'intérêts en français). Les utilisateurs choisiraient les lieux et je n'aurais qu'à enregistrer l'identifiant du lieu dans la base de données de Kamo. Ce n'est finalement pas aussi facile.

Les plugins Leaflet

La bibliothèque Javascript Leaflet est plutôt agréable à utiliser pour afficher des cartes et des marqueurs sur une page web. La documentation qui l'accompagne permet de rapidement découvrir l'outil. Mais pour avoir des fonctionnalités plus avancées, il est nécessaire d'utiliser des plugins, ces derniers étant développés par des particuliers.

Pour avoir une barre de recherche permettant de chercher des POIs, pour centrer la carte sur la position géolocalisée de l'utilisateur, pour afficher les POIs et pour afficher ces POIs sous forme de clusters (pour des raisons de performances), il m'a fallu quatre plugins Leaflet différents. La qualité des plugins est hétérogène et la compatibilité entre eux est aussi variable.

J'ai passé beaucoup de temps à d'abord découvrir les plugins existants, puis comparer leurs fonctionnalités et enfin jauger leur qualité. Et une fois choisi j'ai eu parfois la mauvaise surprise de constater que finalement leur installation ne fonctionnait pas ou qu'utiliser plusieurs plugins en complément était compliqué.

Comme les développeurs de ces plugins sont des indépendants qui le font sur leur temps libre, on peut souvent lire dans les issues Github qu'ils n'ont pas le temps de corriger tel bug ou d'ajouter telle fonctionnalité. Il y a un souci de qualité sur les plugins Leaflet que j'ai pu utiliser et j'ai pris beaucoup de temps pour les installer pour un résultat finalement mitigé.

La qualité des données de POI

Il est possible d'enregistrer beaucoup de données diverses sur OpenStreetMap. Pour les POIs, il est possible d'enregistrer le nom, l'adresse, la latitude et la longitude, le type de commerce, etc. Cependant, la qualité de ces données est très variable.

Pour avoir regardé les données des cafés, bars et pubs dans la région parisienne (que j'estimais au départ de plutôt bonne qualité vu qu'il s'agit d'une zone urbaine dense et qu'il y aurait sûrement beaucoup de mappers qui auraient déjà bien cartographié les lieux), j'ai trouvé des données de toutes sortes. Des lieux avec les horaires d'ouverture, le site web, le type de cuisine (très bien), des lieux sans adresse (pas très bien) et même des lieux sans nom (vraiment pas bien).

Cette hétérogénité des données m'a obligé à prendre du temps supplémentaire pour filtrer ce qui est affiché (retirer les POIs qui n'ont même pas de nom) et pour faire des requêtes de reverse-geocoding via Nominatim pour afficher les adresses des lieux pour lesquels je n'avais que la latitude et la longitude.

Les identifiants des lieux

Vous vous rappelez lorsque j'écrivais plus haut que j'imaginais n'avoir besoin que de stocker un identifiant du lieu dans la base de données de Kamo.social pour savoir si les utilisateurs partagaient un même lieu ? Il semblerait que les identifiants dans OpenStreetMap ne soient pas si fiables que ça.

Les identifiants dans OpenStreetMap sont en fait des identifiants pour des points et des chemins et ceux-ci peuvent être amenés à changer. Pour éviter de perdre trace des lieux, j'ai donc préféré sauvegarder aussi l'adresse du lieu dans la base de données (mais si celle-ci peut parfois être approximative). Et je devrais peut-être plus tard faire des mises à jour de la base de données régulièrement pour être sûr d'avoir les derniers identifiants.

Comment corriger ça ?

Je ne suis pas le seul à rencontrer ces problèmes avec OpenStreetMap. Serge Wroclawski, qui de par ses précédents articles de blog semble avoir beaucoup contribué à OpenStreetMap, a écrit un récent article «Why OpenStreetMap is in serious trouble» où il détaille mieux que moi plusieurs points où le projet a des lacunes.

Et en réaction à cet article, nous pouvons lire dans les commentaires sur Hacker news Steve Coast, le fondateur d'OpenStreetMap, sous-entendre qu'il faudrait peut-être un nouveau projet pour reprendre sur des bases plus saines.

I think what really happens is that projects go through a lifecycle and something new comes along to replace them, rather than anything getting fixed. I'm not sure if this is a good example, but, you could try to "fix" Apache, or you could just do this new thing, "nginx". For all kinds of reasons, the new thing is more efficient. One of the few counter examples I think is going to be Amazon.» Source : Hacker News

Je ne suis pas un spécialiste d'OpenStreetMap car je ne l'ai utilisé que quelques fois en tant que développeur, mais j'ai le sentiment qu'en effet il faudrait faire un grand travail de fond sur le projet afin d'améliorer la qualité des données, d'améliorer la qualité des outils et de faciliter leur utilisation.

Comme Serge Wrocalswki l'a écrit dans un de ses articles de 2014, le choix d'utiliser OpenStreetMap au lieu d'une solution commerciale se fait surtout pour des raisons idéologiques. Il existera toujours des fervents défenseurs du projet mais si celui-ci ne se remet pas fondamentalement en cause, le pragmatisme des uns et autres choisira à terme seulement les solutions commerciales et risquera d'étouffer toute autre initiative de cartographie ouverte.