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

[Florian LAINEZ]

Merci JY pour ta réponse.

Voilà mes réponses à tes suggestions :

Là encore, si le problème est qu'une valeur est trop générique style a=b et
> on peut plutôt dire a=b1 ou a=b2 il vaut mieux passer par l'affinement de
> tags.
>
Tu as raison, j'ai précisé ça dans ma proposition :
"Exception: the new tag should exactly describe the same object. For
example, the old, still in use highway=bus_stop tag is described in the
PT_v2 model as 2 different elements: public_transport=stop_position and
public_transport=* and should not be mechanically edited."

Et pour limiter les erreurs il est possible dans le wiki d'utiliser les
> data items
>
oui ! j'ai rajouté ça dans la checklist du plan de transition :
https://wiki.openstreetmap.org/wiki/Proposed_features/Deprecated_and_unsupported_status#Transition_plan

Peut-être que c'est au niveau du processus de modification qu'il faut
> préciser le cycle de vie choisi pour la dépréciation.
>
C'est une solution "community friendly" mais elle passe néanmoins à côté de
l'enjeux que je tente de régler ici : une meilleure visibilité du cycle. Il
me semble donc important pour cette raison de rester sur une deadline fixe.
Pour éviter tout problème, j'ai choisi un très longue période (2 ans),
c'est une période suffisante pour gérer tous les cas.

Le ven. 10 déc. 2021 à 21:51, <osm.sanspourriel at spamgourmet.com> a écrit :

> deprecated versus depreciated, rassure-toi (ou pas) : alors que je sais
> que le bon terme ici est deprecated, il m'arrive d'écrire depreciated.
>
> Le 09/12/2021 à 09:58, lejun - lejun at gmx.fr a écrit :
> > À propos de la cohabitation entre les deux tags, j’ai envie de dire
> > qu’on est clairement pas à une exception près (Il est possible que
> > j’ai passé beaucoup trop de temps à m’arracher les cheveux sur les
> > attributs pour les réseaux de transport en commun).
>
> Le schéma de transport V2 est l'exemple même de ce qu'il ne faut pas
> faire. Avoir des attributs dont la signification change et qui
> impliquent un autre attribut pour savoir comment le comprendre c'est
> juste du grand n'importe quoi.
>
> Pour les arrêts de bus qui étaient soit des positions d'arrêts des bus
> soit des positions des endroits où attendent les personnes on n'aurait
> pu par exemple ajouter automatiquement un public_transport=stop (c'est
> un arrêt), bus=yes (pour le bus), stop=position (pour le véhicule de
> transport) ou stop=passengers.
>
> Du coup on aurait passé les tous les arrêts en public_transport=stop
> (clé en double le temps que les outils s'adaptent).
>
> puis viré l'ancienne clé, lest stop=* étant ajoutés au fil de l'eau par
> les contributeurs.
>
> Et au pour d'un an ou deux destruction automatique des vieilles clés en
> ayant refait une passe pour ajouter si besoin la nouvelle clé générique.
>
> Le 09/12/2021 à 12:19, David Marchal via Talk-fr -
> talk-fr at openstreetmap.org a écrit :
> > Après, sur le tir à vue, quid des cas où la transition demande de la
> réflexion ? Je veux dire, si un ancien tag est remplacé par plusieurs
> nouveau tags concurrents, parmi lesquels il faut choisir en fonction du
> contexte (c-à-d qu’un programme ne peut pas le faire, un humain doit se le
> farcir), je crains que la proposition n’apporte pas grand chose : l’étape 2
> est plus ou moins ce qu’il se passe actuellement après le vote. Du moins,
> je comprends la proposition comme ça.
>
> Là encore, si le problème est qu'une valeur est trop générique style a=b
> et on peut plutôt dire a=b1 ou a=b2 il vaut mieux passer par
> l'affinement de tags.
>
> Style a=b, b= b1 ou a=b, b= b2.
>
> Comme ça on a une compatibilité et les outils continuent de fonctionner,
> au pire il manquera la possibilité de raffiner.
>
> Le 09/12/2021 à 14:48, Rpnpif - rpnpif at trob.eu a écrit :
> > Je plussoie ce qu'écrit Noémie.
> #MeToo ;-)
> >
> > Je voudrais aussi souligner les problèmes de JOSM qui n'est pas
> > toujours en phase avec le Wiki ou bien qui a des erreurs de traduction
> > (confusion entre deux termes, manque de précision, contresens, etc.)
> > dans les préréglages ou la traduction des attributs au moins en français.
> >
> > JOSM fait parfois introduire des erreurs ou des doublons (même mot
> > pour deux significations différentes).
> >
> > Par exemple : access=* est traduit par "Tous modes de transports" pour
> > un bâtiment ou une autre installation ou terrain ! Tout simplement
> > parce qu'il s'applique plus souvent à une voie.
>
> Si tu veux traduire pas "tous publics", fait un ticket ou fait un PR.
>
> Cependant ici JOSM EST en phase avec le wiki pour lequel access=* n'est
> défini que pour les modes de transport et pour lequel il n'existe pas de
> page pour access=*.
>
> Et pour limiter les erreurs il est possible dans le wiki d'utiliser les
> data items :
>
> https://wiki.openstreetmap.org/wiki/FR:Data_items
>
> Le 09/12/2021 à 15:27, Christian Quest - cquest at openstreetmap.fr a écrit :
> >
> > Et c'est plutôt "replace or update then remove deprecated tags"...
>
> Effectivement c'est plus diplomatique et plus proche de la réalité !
>
> Comme Christian, je suis pour accélérer les choses : soit c'est une
> modification de bon sens (*) et les outils s'adaptent soit c'est une
> modification plutôt à éviter.
>
> (*) style attributs synonymes mais il y a une nuance pas perçue : on met
> un attribut générique (éventuellement l'un ou l'autre) et on précise par
> une nouvelle clé (qui vaut la valeur générique).
>
> Donc pour avoir une dépréciation efficace c'est plus pour moi sur les
> propositions qu'il faut travailler.
>
> Peut-être que c'est au niveau du processus de modification qu'il faut
> préciser le cycle de vie choisi pour la dépréciation,. Ça oblige celui
> qui veut modifier de se poser la question et de proposer une transition.
> Et du coup à proposer des temps adaptés.
>
> Jean-Yvon
>
>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 

*Florian Lainez*
@overflorian <http://twitter.com/overflorian>