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

[Yves P.]

> Le 9 déc. 2021 à 09:18, Florian LAINEZ <winnerflo at free.fr> a écrit :
> 
> 1. donner plus de visibilité au processus post-vote avec une nouvelle
> période transitoire de 2 ans durant lesquelles le nouveau et l'ancien tags
> restent tous les deux utilisés

2 ans me parait trop long. Suite à lecture du fil, il faut probablement donner un délai adapté à chaque réforme.
 
> 2. tuer de manière plus déterminée les anciens tags : après 2 ans, seul le
> nouveau tag est utilisé et il est recommandé de supprimer l'ancien tag, en

Après vérification que les principaux outils ont effectivement basculés, je suis favorable à une édition de masse.
Ça même donc à la remarque primordiale de Noémie :

> Le 9 déc. 2021 à 12:45, Noémie Lehuby via Talk-fr <talk-fr at openstreetmap.org> a écrit :
> 
> 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).
Oui :)

> 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.
C’est un des problèmes.

Les principaux étant :
- la saisie (pas possible ou trop lourde suivant l’éditeur)
- les rendus qui n’incitent pas à utiliser le tag (cf. tags healtcare) ou provoquent de mauvaises pratiques (taguer pour le rendu)

> 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.
Oui c’est très important.

Comme l’a rappelé Jean-Yvon, un moyen universel et efficace est l’utilisation des DataItems (la version OSM du mécanisme Wikidata).
Une éditeur ou un outil QA qui l’utilisent pourront automatiquement signaler un tag déprécié.

Si un développeur ne veut pas ou ne peut pas mettre à jour une appli, un rendu… on aura au moins une base de connaissance centralisée pour lister les tags et outils impactés, ceux qui sont ou pas à jour.

Note : Il y a une ébauche de liste qui existe avec les projets associés à un tag dans TagInfo.
Le problème c’est que chaque développeur doit proposer une liste et la tenir à jour.
De plus vu la complexité de certains tags ou usages de tags, c’est parfois difficile de dire précisément comment un tag est réellement supporté par une appli, un rendu.

Regardez par exemple les descriptions dans TagInfo <https://taginfo.openstreetmap.org/tags/information=guidepost#projects> pour le tag information=guidepost.
Par toujours simple à comprendre pour un humain, quasi impossible pour une machine.
Dans le cas des rendus, les icônes utilisées sont parfois affichées, parfois non.

__
Yves