Bonsoir Pierre, Il y a en effet encore quelques points qui n'ont pas encore de réponse, mais nous pourrons surement les trouver collectivement.
Ce fil doit continuer à vivre. Pour l'instant et tel qu'indiqué, ce que je propose ne solutionne pas la question des multiples antennes sur un même point. Il faut encore du temps pour y réfléchir. Nous ne pouvons pas le voter en l'état, tout n'est pas complet, il y a encore plein de cas à croiser. Il faut en premier lieu faire des photos et donner des cas pratiques en fin de document. Ensuite, tout traduire en anglais, pour le diffuser au plus grand nombre (je peux m'en charger sur une bonne partie, pour peu qu'on soit d'accord sur la version française). Là encore, au fur et à mesure. La page Key:antenna part surement d'un bon sentiment mais est mal nommée. Ce genre de page sert à la documentation d'un tag, une fois acceptée ou bien lorsque celui-ci est déjà largement utilisé (> 100k dans tag info). Pour ce qui nous concerne, il faut aller dans la catégorie Proposed_features avec une page comme celle-ci : https://wiki.openstreetmap.org/wiki/Proposed_features/Antennas_cartography C'est plutôt important, il y a des personnes qui sont plutôt directes sur @tagging Pour donner une idée, voici une proposition que je m’apprête à présenter au vote, sa rédaction a demandé 1 an et demi (même si le RFC a démarré début janvier, le document d'origine est apparu en 2013) https://wiki.openstreetmap.org/wiki/Proposed_features/Power_supports_refinement Dans notre cas, ce sera beaucoup plus court, ok, mais on doit encore prendre le temps de la réflexion pour proposer quelque chose de complet. Bonne soirée François *François Lacombe* fl dot infosreseaux At gmail dot com www.infos-reseaux.com @InfosReseaux <http://www.twitter.com/InfosReseaux> Le 3 mai 2015 22:50, dHuy Pierre <dh...@yahoo.fr> a écrit : > @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 > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
