Le 3 mai 2015 13:17, dHuy Pierre <dh...@yahoo.fr> a écrit : > @Verdy: N'ayant pas vocation d'un débat de sémantique, je te laisse > débattre sur le sexe des anges. > > Je n'arrête pas de te répondre que je n'ai pas parlé de ça et encore moins des anges. Tu as une conception étrange de la sémantique, qui consiste à l'inventer pour lui faire tout dire. Arrête s'il te plait tes inventions et ne reprends que ce que j'ai posté réellement, pas ce que tu crois avoir lu en le rapportant ensuite aux autres, merci. J'ai été assez clair pour limiter la portée de ce que j'ai dit et préciser mes intentions.
D'ailleurs mon message initial avait eu une réponse similaire d'un autre utilisateur concernant l'usage des ; et des | et de leur interprétation ou prétendue "standardisation" qui n'existe pas et est trompeuse. Si tu revien à ce que j'ai écrit, j'ai précisé où était le problème dans la proposition initiale de Jérome: le fait qu'il utilisation deux tags séparés en imposant un ordre des valeurs dans un tag où d'évidence ce n'est quy'une liste non ordonnée, pour l'aligner avec l'ordre des éléments dans un second tag séparé (qui lui non plus n'a pas d'ordre, mais aligne ses éléments avec ceux du premier tag). En terme de description des données c'est un problème puisque dans OSM les tags ont vocation à être mainbtenus tous séparément. une première solution était de rassembler dans le même tag les valeurs qui doivent rester ensemble, mais alors ces valeurs ont un ordre intrinèque pour préciser quel champ correspond à quielquechose. On se retrouvait donc à mettre dans un même tag: le nom d'un opérateur, et la liste (elle-même non ordonnée) des réseaux utilisés, et créer donc autant de tags que d'opérateurs: compment les distinguer ? il faut une clé pour chaque tag mais il n'y a rien d'évident autre qu'un suffixe numérique (mais qui a le défaut d'imposer un ordre apparent par la valeur des indices numériques (qui sont ici arbitraires), cependant c'est un soucis relativement mineur. Reste à savoir comment représenter dans un même tag des champs de nature différente: nom de l'opérateur et ses réseaux. Et là on n'a pas grand chose de stadnardisé non plus dans OSM, et c'est à nous de l'inventer, sous une forme qui soit cependant lisible et compacte. Ce qui est à représenter est un type de données structuré (contenant plusieurs champs de nature différente). Le seul usage significatif correspondant à ce cas est celui des "lanes" mais il est très peu lisible. et malgré tout ce n'est pas encore une "norme" en tant que tel. Si on parle de normes en usage pour les types structurés, il y en a deux évidentes: XML et JSON; j'excluais tout de suite XML dont la syntaxe verbeuses est trop lourde pour être utilisée dans la valeur d'un tag, il restait donc seulement JSON mais qui a aussi une syntaxe un peu lourde, qu'on peut alléger car on n'a pas besoin de distinguer les types (numérique, chaine) des atomes et il est souhaitable alors de pouvoir s'abstenir des séparateurs de chaines. Mais je ne voulais pas, avant de proposer un autre système, en fait un truc spécifique pour un seul tag, car des types structurés, demandant un parseur spécifique pour les analyser, ajoute à la maintenance. µBref je ne me suis pas contenté de proposer quelquechose concernant les seules antennes, mais pour en parler de façon plus générale. C'était donc non pas une proposition formelle mais une analyse d'un problème plus général de modélisation et codification des données dans un domaine où il n'y a pour l'instant strictemetn rien de standardisé. Alors toi tu prends ça pour le sexe des anges si tu veux, mais ce n'est pas mon propos et pas le sujet. C'est plus sérieux.
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
