Ton avis compte peu, car la syntaxe n'est déjà pas digeste pour un humain. Les espaces non nécessaires sont facilement détectés par un humain, on n'a aucun cas dans cette syntaxe ou un même mot contient à la fois des chiffres et des lettres (on ne met aucune marque), hormis les chaines descriptives entre guillemets où on peut mettre presque ce qu'on veut maiq ne sera pas analysé, juste affiché tel quel dans un rendu, sous forme de note sous un tableau des horaires (en général ce n'est pas pour une marque, à moins d'avoir une restriction du genre: Mo off "réservé aux employés de Sport2000". Mais cs notes ont déjà le défaut d'être dans une langue non spécifiée alors qu'elles sont destinées à un humain (et à mon avis elles devraient être dans des tags séparés qualifiables par le code langue dans la clé).
J'ai aussi le droit d'en parler ici, ne serait -ce que pour récolter des avis et des gens pour soutenir cette modif simple qui pourrait résoudre le problème. En attendant on a des cas où il n'y a aucun moyen de rentrer ça en 255 caractères et le fait de concaténer toutes les règles dans l'ordre avec des ";" séparateurs est le principal problème: ces tags "opening_hours" auraient du être suffixés par un ":rang" numérique (de ":1" à ":n" sans "trou" de numérotation, avec ":1" facultatif dans la clé pour la première règle car implicite) dans la clé pour se passer du point-virgule pour compatibilité. Ceci fait ces tags seraient enfin plus lisibles que sous forme d'une longue chaîne, la plupart des règles étant très courtes. L'usage des ";" point les valeurs de tags dans OSM est criticable, depuis le début les tags à plusieurs valeurs auraient dû utiliser des clés numérotées avec une convention pour le suffixe à reconnaître, et la convention de validité impliquant qu'il ne devrait y avoir aucun trou de numérotation. Les tags pouvant avoir plusieurs valeurs pourraient être documentés comme tels. iD a utilisé sa propre convention avec "_2", etc. (et non ":2", etc.) quand il fusionne des objets avec des clés différentes. Je n'aime pas trop mettre dans OSM des tags sous forme d'URL quelconque demandant d'interroger une base tierce pour avoir les infos, les seules URLs étant plutôt les sites officiels des objets décrits (website=*) ou la mention de sources (mais là aussi on préfère des "ref:*=*") pour des liens vers des bases de données ouvertes (et pas n'importe quel site), y compris Wikipedia ou Wikidata (et je n'aime pas qu'on mette des URLs pour des images sur Commons, quand un nom de page Commons suffirait). Cela Le mar. 31 déc. 2019 à 00:45, marc marc <marc_marc_...@hotmail.com> a écrit : > Le 31.12.19 à 00:37, Philippe Verdy a écrit : > > Mais que penser de ma proposition de rendre tous les espaces facultatifs > > postée ici, elle n'a aucune chance d'être par les dev des différentes > applications. > postée sur tagging, dans une version digeste, elle aura sans doute du > soutient et des détracteurs. pas sur que cela suffise vu que d'autres > idées moins problématique n'ont pas abouti à être adpètées. > > moi je suis d'avis : si la valeur souhaité d'une clef est indigeste pour > un humain (parce que c'est cela la logique des clef/valeur d'osm), > alors c'est pas une bonne valeur (=faut faire autrement) > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
