[OSM-talk-fr] [OSM-Talk fr] [Proposition] Améliorer le processus de dépréciation des tags

[Noémie Lehuby]

Hello,

j'aime beaucoup cette idée de se donner les moyens de tuer des anciens 
tags après s'être mis d'accord.

Mais je pense au contraire que le point primordial n'est pas de dégommer 
à vue à la fin de la période mais plutôt de faire en sorte que les 
nouvelles données soient supportées systématiquement à la fin de cette 
période.
La période de transition serait alors surtout une période de migration, 
au moins pour les outils (doc, éditeurs, rendu et réutilisations).

Pour info, en préparant le projet du mois de mars 2020 sur les bornes de 
recharge électrique, on a changé le tag car=yes à motorcar=yes pour 
indiquer le fait qu'on puisse y brancher une voiture.
Après accord, la migration a nécessité

  * de modifier la page de wiki amenity=car_station, dans 8 langues
  * de modifier la page de wiki de la clef car, dans 2 langues
  * de lister le tag dans les deprecated_features du wiki
  * de vérifier toutes les autres pages de wiki qui mentionnaient ce tag
    (en utilisant la page spéciale qui liste toutes les pages qui ont un
    lien vers une page de wiki :
    https://wiki.openstreetmap.org/w/index.php?title=Special:WhatLinksHere/Key:car&limit=100)
  * de modifier les presets des principaux éditeurs (JOSM, ID, Vespucci,
    etc) et de ceux dédiés à la thématique (dans ce cas, un thème
    MapContrib et un thème OSM Contributor, mais la liste peut vite grossir)
  * de créer des validateurs qui signalent et suggèrent le changement
    (JOSM, ID, Osmose)


Tout ça avant de commencer à toucher aux données, automatiquement ou 
pas. Et là c'était un cas simple sans impact sur les rendus.

Si on se dit juste "on tue le tag dans 2 ans" sans mettre en place un 
plan de migration crédible, j'ai un peu peur qu'il ne se passe pas grand 
chose pendant ces deux ans (vu que l'ancien tag est potentiellement 
majoritaire dans les données et encore ok) puis qu'on fasse un edit auto 
mais que les vieux tags reviennent parce que certains éditeurs 
continuent de les proposer et que la doc est contradictoire en fonction 
de là où tu regardes.

Idéalement, une page de process de migration devrait être créée sur le 
wiki après le vote pour lister les choses à faire et permettre de suivre 
l'avancement.
Comme il y a déjà un paragraphe Features/Pages affected (List of wiki 
pages that would be edited if the proposal is approved) dans les 
Proposals, il pourrait y avoir un paragraphe pour la doc, les éditeurs, 
les rendus, etc
avec une note "si vous connaissez d'autres outils que ceux mentionnés 
ici qui utilisent ce tag, merci de les ajouter dans cette liste et/ou de 
leur envoyer cette page pour leur indiquer que le tag arrive en fin de vie"
Sachant que si on souhaite faire une période de transition, deux 
évolutions sont potentiellement à prévoir dans les éditeurs : une pour 
ajouter la nouvelle manière et signaler que l'ancienne est en fin de vie 
si l'outil le permet, puis une pour supprimer l'ancienne à la fin de la 
période de transition. Donc avoir une liste exhaustive des outils 
concernés semble assez primordiale pour que ça soit effectif.

Et ça permet aussi de moduler la transition : si on a déjà migré la doc 
et tous les outils connus, on peut commencer à faire des challenges 
maproulette pour migrer les données petit à petit sans passer par des 
edits automatiques. Ou à l'inverse se rendre compte qu'on n'y arrive pas 
et allonger la période en connaissance de cause.

-- 
Noémie Lehuby

Le 09/12/2021 à 11:37, Florian LAINEZ a écrit :
> Néanmoins, le cœur de la proposition est bien ici de réussir à "tuer" les
> anciens tags une bonne fois pour toute. Et donc de décider d'une date
> butoir après laquelle on peut les shooter à vue. Je pense que notre débat
> devrait tourner autour des avantages / inconvénients d'une telle
> proposition, les autres sujets restant, il me semble, annexes.