@Verdy: Je vois que ta maitrise de la langue française est presqu'aussi impressionnante que tes connaissances en général aussi je t'invite à consulter toute une série de sites pour ce qui est de la définition des différents mots que j'utilise ou pourrais être amener à utiliser. Pour quelqu'un qui a une réputation particulièrement mauvaise dans le monde des wikis et de la culture libre, je trouve que tu as beaucoup de mal à maitriser les principes de base de la dialectique.Autrement, je parlais de la formulation de ton "idée" (le terme te parait suffisamment clair?), peux tu donner un exemple concret de ta formulation json sur le wiki et ou sur le pad? Merci.
@Lacombe, j'ai mis sur le wiki entre temps, je t'invite à écrire desus. Je ne comprends toujours pas comment tu comptes modéliser quand plusieurs antennes occupe le même point exactement? Après je trouve que ça fait beaucoup d'info mais ça sera aux utilisateurs d'osm de voter :) @all: merci beaucoup à tous, la page wiki est ici: https://wiki.openstreetmap.org/wiki/Key:antenna. Je n'aurais jamais réussi à mettre ça sur pied sans vous. Je mets ça en proposition officielle cette semaine et j'espère vous voir voter quand le vote officiel commencera! (je reviendrai spammer la ML don't worry :) ) Merci encore à tous de votre aide et bonne semaine! (Et remerciement particulier à Eric qui m'a permis de peaufiner certains point sur le pad en live et à Lacombe pour ses idées que j'attends de voir au vote :p ) @cquest: Merci isolé pour travailler à la libération des données ;) Librement, Le Dimanche 3 mai 2015 21h59, Philippe Verdy <verd...@wanadoo.fr> a écrit : 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
