Summary

  • Le 17 avril 2009, OpenStreetMap annonçait une API en lecture seule, parfois indisponible, pendant la migration vers 0.6. Les contributeurs ne pouvaient plus enregistrer de changements et Potlatch, l'éditeur en ligne, était arrêté.
  • La nouvelle API rangeait les modifications dans des changesets, contrôlait les versions des objets et ajoutait des identifiants numériques aux comptes publics. Une requête d'envoi différentiel pouvait être atomique ; le changeset entier, étalé sur plusieurs requêtes, ne l'était pas et ne disposait d'aucune annulation globale dans l'API.

Le crayon restait dans la main du cartographe, mais le serveur n'acceptait plus la correction. Dans son annonce du 17 avril 2009, OpenStreetMap déclarait l'API en lecture seule pour passer à la version 0.6, avec des moments où elle pourrait être totalement inaccessible. Les modifications ne pouvaient pas être sauvées dans la base et Potlatch était désactivé. La fin était envisagée pour le lundi 20 avril ; les utilisateurs d'autres logiciels devaient prévoir une mise à jour. Le calendrier annoncé était celui d'une intervention en cours, pas un constat de retour complet.

Pourquoi interrompre le geste qui fait vivre la carte ? Le document du projet sur les changements entre les versions 0.5 et 0.6 donne une première réponse. Il date la sortie de 0.6 du 20 avril et impose qu'une modification de nœud, de chemin ou de relation soit rattachée à un changeset. Celui-ci peut réunir plusieurs appels à l'API et porter un commentaire lisible. Une série de traits sur la carte acquiert ainsi un contexte commun, au lieu de n'apparaître que comme des objets changés isolément.

Le nom du mécanisme invite à une erreur. Le changeset complet n'est pas une transaction de base de données : plusieurs requêtes peuvent y entrer, et l'API ne peut pas l'annuler d'un seul mouvement. Un envoi différentiel effectué dans une requête, lui, peut être traité de façon atomique. L'historique regroupe le travail ; la garantie d'exécution porte sur une unité plus petite. Appeler le dossier un bouton « annuler » aurait promis une fonction que la spécification excluait.

La version de chaque objet devenait aussi une condition d'écriture. Le logiciel d'édition recevait un numéro avec le nœud, le chemin ou la relation qu'il téléchargeait. Au moment de renvoyer une correction, il devait présenter ce numéro. Si quelqu'un d'autre avait déjà enregistré une version plus récente, le serveur refusait l'ancienne. Le conflit sortait du flou : l'outil devait dire au contributeur que son dessin reposait sur un état dépassé.

L'attribution suivait la même recherche de précision. L'ancienne API exposait un nom affiché que l'utilisateur pouvait modifier, sans historique de ses changements de nom. La version 0.6 ajoutait l'identifiant numérique du compte pour les éditions publiques. Le document du projet précise qu'elle ne révélait pas pour autant l'identité des anciennes éditions anonymes. La nouvelle trace améliore les enregistrements futurs ; elle ne crée pas rétroactivement une personne derrière chaque champ vide.

La page conservée des essais de migration montre le travail imposé aux auteurs des outils. Des serveurs d'essai accueillaient les logiciels compatibles avec 0.6. Il fallait vérifier la création de changesets, le refus d'une version périmée, Potlatch, JOSM et les outils de réplication. Certaines anciennes versions de JOSM ne pouvaient simplement pas parler à la nouvelle API. La conversion du serveur central obligeait donc tout l'écosystème d'édition à se présenter au contrôle technique.

La base elle-même changeait de machine et de moteur. Dans le compte rendu du conseil de la fondation du 12 mai, Grant décrivait le passage de MySQL à PostgreSQL, des étapes de migration recommencées et un chantier plus long que prévu. Quelques corrections restaient à faire ; la surveillance et des disques supplémentaires étaient encore discutés. Ce compte rendu explique le dépassement, sans dater à la minute la reprise de chaque voie d'édition.

La nouvelle carte gardait mieux la mémoire du travail, mais cette mémoire exigeait un arrêt du travail lui-même. OpenStreetMap a demandé aux contributeurs d'attendre, aux développeurs de faire évoluer leurs outils et au serveur de refuser les corrections parties d'un état périmé. Une fois la barrière relevée, enregistrer un trait avait changé de sens.

Documents originaux