> Mais ça ne résoud pas la question des valeurs réellement trop longues Pour moi faire sauter la limite des 254 caractères est un prérequis.
> (dont opening_hours, qu'on ne peut toujours pas découper facilement […] alors > que opening_hours impose un ordre précis d'interprétation). Si avec une info dans DataItem qui indique quels tags acceptent les valeurs multiples (cf. message sur la limite des 255 caractères). Dans la concaténation de tag + tag_1 + tag_… l'ordre est respecté :) > , d'autant que cette proposition pour v0.7 ne concerne QUE les valeurs > multiples sans aucun ordre de tri significatif, alors que opening_hours > impose un ordre précis d'interprétation). Il y a effectivement un bief possible : que l'ordre des valeurs ne soit plus respecté. Ce n'est pas gênant si on indique des moyens de paiement (espèces, carte…) Ça peut-être problématique pour un bar, tabac, restaurant. Quel valeur va afficher le rendu ? > Si on doit respecter un ordre et pouvoir découper les valeurs longues,… Encore une fois, ce sont deux choses différentes. Peut-être qu'il faut faire une API v0.6.001 avec seulement la prise en compte des valeurs longues ? Puis une v0.6.002 plus tard pour les valeurs multiples ? L'article d'Allan a été écrit AVANT le confinement. Peut-être que maintenant c'est plus facile de réunir virtuellement tous les développeurs OSM pour un hack week end ? Et du coup le passage en v0.7 pourrait s'envisager à nouveau en mode "bourrin" (arrêter complètement l'API pendant ce temps de développement) ? Un mix peut-être envisagé : faire un hack par visio avec une petite modification à la fois, le tout en mode "doux". Ça permettrait de vérifier la faisabilité de la mise à jour de l'API sans trop de casse, et d'avancer… un peu :) __ Yves _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
