Re: [OSM-talk-fr] Normalisation du tag antenne
Bonjour, La nuit a porté conseil : j'ai essayé de mettre ce dont je parlais hier sur un schéma https://wiki.openstreetmap.org/w/images/d/de/Radio_antennas_mapping_proposal.png Il n'y a pas de référence précise aux fichiers de l'ANFR. Voici le cas de figure : Le CG a installé un mat sur ses fond propres pour accueillir des antennes mobiles et d'autres services radio (PMR, radio privée typiquement ou pour les équipes d’entretien routières...). Étant isolé, le site radio est relié aux réseaux par un faisceau hertzien, le 3ième type d'antenne visible sur le support. L'ARCEP appelle ça un site zone blanche où les investissement d'infrastructure de téléphonie sont mutualisées. Le support est ici de la responsabilité du CG ou d'une autre autorité publique, la chaine antennaire (antennes + câbles coaxiaux) de téléphonie mobile de celle d'un opérateur identifié (les autres opérateurs de téléphonie mobile sont bien présents mais virtuellement en partageant le réseau d'accès). Le système PMR est exploité par la DIR parallèlement. Il est aussi possible de voir s'installer d'autres opérateurs en partageant la chaine antennaire par couplage : une chaine antennaire, plusieurs stations d'émission au sens ANFR et donc plusieurs opérateurs exploitant la même antenne (cf les sites du métro parisien). C'est théoriquement l'une des situations les plus complexes à cartographier. On peut donc utiliser des relations pour matérialiser les stations, acceptant des membres antennes et supports, voire les baies/équipements actifs si ils sont connus et matérialisables. Ceci nous permet principalement : - D'indiquer les opérateurs à plusieurs niveaux, ceux qui installent/maintiennent les antennes et ceux qui les utilisent, l'exemple pris montrent qu'ils peuvent être différents. - D'indiquer les services à plusieurs niveaux, le GSM900 et l'UMTS900 en téléphonie mobile peuvent par exemple utiliser les mêmes antennes 900 Mhz. - D'indiquer les différentes références ANFR du fichier publié. Ce qui pose encore problème : - Comment poser différentes antennes sur les mats/pylônes ? Il y a beaucoup d'informations par antenne, Jean-Marc disait à juste titre que le support ne supporterai pas le poids des tags ;) Il est aussi possible que j'ai oublié quelque chose. Bonne fin d'aprem 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 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. @all: D'un autre coté et basé sur vos réflexion à tous, j'ai créé un modèle n'associant aucunement les usages, les shapes et les operateurs pour l'antenne ou les antennes. J'exclus pour le moment l'usage d'une organisation dans le tag mais appelle ceux qui avaient proposé à mettre en forme leur proposition que j'intégrerai avec plaisir dans la page wiki Un d'entre vous a mentionné a mentionné la hauteur de la base de l'antenne, s'il peut expliquer un peu plus ici. Je partage sur le wiki aujourd'hui. Le Samedi 2 mai 2015 23h36, Philippe Verdy verd...@wanadoo.fr a écrit : Le 2 mai 2015 23:14, dHuy Pierre dh...@yahoo.fr a écrit : Pour ta norme pour cartographier les données associées aux antennes si tu veux. Je n'ai pas parlé de ma norme... ___ 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
Re: [OSM-talk-fr] Normalisation du tag antenne
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. Tu continues à divaguer sur des sujets qui n'ont rien à voir avec ce dont j'ai parlé (alors que ce dont je parlais a été aussi repris par d'autres comme idées intéressantes, et que d'autres ont aussi soulevé les mêmes problèmes). Je t'ai dit d'arrêter d'inventer ce que je n'ai pas dit. Mais tu continues à propager des propos clairement mensongers et à sortir du sujet pour des attaques personnelles en plus. La définition des mots tu l'as largement interprétée à ta propre guise en déguisant mes propos et en les rapportant de façon détournée à plusieurs reprises (en public comme sur des messages envoyés à plusieurs autres en copie hors liste). Ma réputation sur les wikis est aussi bonne que n'importe qui, pas la peine d'inventer là encore de telles divagations qui sont hors de propos ici. Ce n'est pas parce qu'il y a un ou deux individus qui s'opposent que tout le monde les suit, ils sont une infime minorité et il est totalement inévitable dans un mode collaboratif où il y a beaucoup de monde, que tout le monde ne soit pas d'accord, sans que ça dégénère comme tu le fais ici en conflits personnels sur la scène publique. Tu te permets d'interpréter mes connaissances de la langue sur la seule base des fautes de frappe ça et là dans un simple email qui n'a rien d'un document. Si tu te bases là-dessus, alors personne n'est à l'abri de tes aprioris clamés publiquement comme des jugements personnels... Un mail ou une page de dosucssion n'est pas une page maintenue, Et je suis largement au dessus de la moyenne de l'immensité des contributeurs en terme de respect de la langue. Bref ta réponse est TOTALEMENT hors sujet. Mais si tu pinaille je reprends tes propres fautes, dans maîtrise par exemple où tu omets le circonflexe. Je t'invites donc à relire un dictionnaire pusique que tu me défies là-dessus (ce qui est totalement hors sujet). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Normalisation du tag antenne
Arf, je corrige dès demain effectivement. Je pensais que l'avoir mis en proposal suffisait. Hum l'objectif était de mettre les propositions de normage pour les éléments dans la discussion et dans des sous parties de la propale. Je delete du coup. Le Dimanche 3 mai 2015 23h10, François Lacombe fl.infosrese...@gmail.com a écrit : 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 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
Re: [OSM-talk-fr] Normalisation du tag antenne
Le 3 mai 2015 22:50, dHuy Pierre dh...@yahoo.fr a écrit : 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. Avant de formuiler ça sur le wiki ou le JSON, je répète que je ne faisais AUCUNE proposition, juste des remarques générales sur la codification des données structurées. JSON pas la peine de le document on sait ce que c'est. Pour le reste j'avais juste évoqué l'idée de le compacter un peu plus pour correspondre à nos usages plus limités (un seul type d'atome: chaines, pas de nombres; séparateur point-virgule conservé pour les listes de valeurs non ordonnées (mais uniquement au plus haut niveau de la structure, PAS dans des sous-listes) Et j'avais donné des exemples ici dans le cadre d'une simple discussion, pas d'une proposition. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Normalisation du tag antenne
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
Re: [OSM-talk-fr] Normalisation du tag antenne
@Verdy: N'ayant pas vocation d'un débat de sémantique, je te laisse débattre sur le sexe des anges.@all: D'un autre coté et basé sur vos réflexion à tous, j'ai créé un modèle n'associant aucunement les usages, les shapes et les operateurs pour l'antenne ou les antennes.J'exclus pour le moment l'usage d'une organisation dans le tag mais appelle ceux qui avaient proposé à mettre en forme leur proposition que j'intégrerai avec plaisir dans la page wiki Un d'entre vous a mentionné a mentionné la hauteur de la base de l'antenne, s'il peut expliquer un peu plus ici. Je partage sur le wiki aujourd'hui. Le Samedi 2 mai 2015 23h36, Philippe Verdy verd...@wanadoo.fr a écrit : Le 2 mai 2015 23:14, dHuy Pierre dh...@yahoo.fr a écrit : Pour ta norme pour cartographier les données associées aux antennes si tu veux. Je n'ai pas parlé de ma norme... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Normalisation du tag antenne
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
Re: [OSM-talk-fr] Normalisation du tag antenne
On ne tag pas les bandes, on unifie les émetteurs par opérateur et les opérateurs et les formes par station. Le Samedi 2 mai 2015 14h30, Eric Debeau eric.deb...@gmail.com a écrit : Oups, le mulot avait dérapé... Salut Je suis un peu perdu. J'ai mis des commentaires dans le pad. Concrètement, j'ai compris que l'on veut intégrer dans OSM des infos sur les supports et les antennes. J'ai compris que la proposition de Phlippe Verdy vise à intégrer dans le même tag différentes informations liées à un même support et pas à une antenne au sens ANFR ! Je trouve aussi très bien le modèle de représentation proposé par Philippe. Du coup, je ne comprends pas bien l'intérêt de proposer des tags liés à une antenne (au sens ANFR). Ce serait bien de clarifier le modèle de données de ANFR. 1 support support n station 1 station supporte n antennes 1 antenne supporte n émetteur 1 émetteur supporte n bandes Cas concret. Le support 687819 supporte 3 stations (sur un chateau d'eau) 0220220007 (FH) 022033 (E-Message) 090003 (Telecom) La station 090003 supporte 6 antennes (2 * 3 antennes panneau : une antenne par secteur) 325425 2487083 2487081 2487079 162468 162466 L'antenne 325425 supporte 2 émetteurs 3220894;GSM 1800 3220896;UMTS 2100 L'émetteur 3220896 supporte 3 bandes 1964,9;1979,7 1910,1;1915,1 2154,9;2169,7 Concrètement, on taggue comment ? Eric 2015-05-02 13:53 GMT+02:00 dHuy Pierre dh...@yahoo.fr: @Verdy: Je soutiens ton idée, je dis juste qu'il faudrait la voter ensemble, comme tu l'a dit, c'est l'affaire de la communauté. Le Samedi 2 mai 2015 13h43, Eric Debeau eric.deb...@gmail.com a écrit : Salut J'a Eric 2015-05-02 5:04 GMT+02:00 Philippe Verdy verd...@wanadoo.fr: Le 2 mai 2015 00:21, dHuy Pierre dh...@yahoo.fr a écrit : L'idée de Verdy est pas al en la matière mais non normalisé encore, OSM non plus n'est pas normalisé dans ses données: il crée lui même ses propres standards avec nous tous. J'ai proposé un truc générique proche de JSON mais plus compact et adapté aux usages d'OSM, rien de plus, mais assez générique pour coder des données structurées sans avoir pléthore de tags et de codages spécifiques pour chaque tag particulier (celui des lanes est actuellement une horreur, tout le monde s'y trompe). ___ 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 ___ 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
Re: [OSM-talk-fr] Normalisation du tag antenne
Le 2 mai 2015 00:09, dHuy Pierre dh...@yahoo.fr a écrit :
@Jérome: Merci de l'avoir expliqué. Je suis opposé au tag communication:*=
cependant, en effet je trouve que ces tags surchargeraient trop en cas de
données multiples et ne serons jamais assez exhaustif, on risquerait de se
retrouver avec des key user defined...). Pour le type d'antenne, je propose
déjà antenna:shape (antenna:type éventuellement, j'étais partagé en
écrivant). Mais on reste sur le même set d'info a taguer.
@Lacombe, comme précisé plus haut, les commentaires sont souhaités entre
crochet, j'ai donc rajouté pour les tiens mais du coup j'y réponds ici. Ah
et si possible sur le pad les commentaires sont plus intéressants s'ils
constituent un texte à compléter et pas une remarque qui nécessite débat,
plus approprié à la ML (ou au canal de communication si subitement on s'y
connecte en masse), je supprimerai du texte les superflus mais il sera
possible d'en retrouver la trace dans l'interface.
Désolé, c'est nouveau pour moi.
- radio=repeater|relay ou autre: Non il s'agit d'élément immatériel,
difficile à vérifier en pratique et peu utile en carto, mais si quelqu'un
d'autre les souhaite, je suis à l'écoute de vos raisonnements. Je propose
antenna=yes seul sur un node en cas d'absence de support ponctuel (comme
sur un immeuble)
Il s'agit de stations au sens ANFR.
Au sens OSM, ces stations seraient plutôt des relations entre les supports
et les antennes.
Les stations supportent le service, notre principal problème quand on veut
ajouter ces infos sur l'antenne directement.
On évite les chaines de ce genre :
operator={[TDF{FM|FH}][Opérateur privé{PMR}][SNCF{GSM R}][FREE MOBILE{UMTS
900|UMTS 2100|LTE 2600}]}
En indiquant l'opérateur sur les stations plus que sur le support ou
l'antenne.
yes est une valeur par défaut, il faudrait utiliser le tag antenna pour y
ajouter d'autres infos (comme le type directement, au lieu de
antenna:type=*, on s'évite de créer une clé supplémentaire).
- tower:type=communication_tower conduisait jusqu'alors implicitement à
l'existence d'une antenne, ce que je défend c'est un tag unifié pour les
antennes. Mais donc non pas de confusions...
Implicitement, on peut affirmer plein de choses.
Que se passe-t-il si toutes les antennes ont été désinstallées ? On a
toujours un tower:type=communication_tower sans antennes.
Ces valeurs trappes font dire plein de choses et on a finalement pas l'info
qu'on cherche.
Avec les explications de cette nuit, je comprends mieux antenna=*, d'autant
que cette clé-ci est quand même moins sujette aux interprétations comme
pour la plupart des valeurs tower:type.
- Le fichier ANFR ne permettrait pas le placement: Relis ce qu'à écrit
Jérôme.
Non en effet : c'est bien ce que je disais. C'était une affirmation.
- Une antenne radar/ une antenne onde courte... etc sont des antennes
colossales qui se remarque facilement en milieu urbain et qui constituent
toujours un repère, de même à la campagne.
On est d'accord là-dessus, l'objet du commentaire n'était pas sur le côté
représentatif de l'antenne ou non mais dans sa place dans le modèle.
Bref, en relisant c'était un peu HS, autant pour moi.
- La base de données opencellid/mozstumbler est approximative, mais elle
peut etre utile dans des pays qui ne possède pas un équivalent de l'anfr ou
dont la base serait non libre. Cela donne une position approximative d'une
antenne télécom. d'où la précision déjà présente sur la localisation.
Pas forcément : ce genre de base recense des endroits où on capte, mais
l'antenne peut être à des dizaines de km.
Le GSM fixe un rayon de cellule de 35 km pour que la communication puisse
s'effectuer
Cependant on peut capter la cellule bien plus loin si l'opérateur ne prend
pas les dispositions nécessaires.
C'est pour ca qu'il y a toujours un problème avec openCellID et autres :
sans infos plus précises, on ne sais toujours pas où sont les antennes en
question.
On peut aussi être à côté d'une et en capter une bien plus loin.
J'ai laissé un commentaire parce que je ne comprends pas ce que tu veux y
dire. (J'ai intégré certains commentaires au texte aussi)
Les stations au sens ANFR ont pour principale utilité de savoir quel
service est derrière l'antenne.
L'antenne est uniquement faite pour une bande de fréquence. Après tu y fait
transiter ce que tu veux.
La preuve : GSM et GSM-R (communications sol/trains dans le ferroviaire)
sont tout de même deux choses bien différentes, pourtant les mêmes antennes
sont utilisées.
Donc si on ne sais pas ce qu'il y a derrière l'antenne, on ne peut pas dire
réellement quel service elle offre.
D'où l'utilité de mettre les stations ANFR sous forme de relation dans
laquelle on ajouterai les antennes, principaux objets physiques sur le
terrain on est d'accord.
Ce genre de relation permet d'éviter de surcharger en clé des objets
node/way (ici les antennes).
Peut-on commencer à compléter une page de proposition sur le wiki avec
Re: [OSM-talk-fr] Normalisation du tag antenne
Avant la proposition j'attends au moins une unité dans le camp talk-fr
:pOpencellid se base sur des séries de mesures cumulés pour estimé la position
de l'antenne en fonction de la réception. Ces estimations donnent une précision
de 100m (donc contestable mais intéressant).Bon je crois crois qu'on se
comprend pas pour les données du set ANFR, il y a la position GPS.Pour ta
relation je te laisse proposer ton modèle alternatif clairement avec la
relation. Et une fois le consens obtenu je le poste sur le wiki.
Le Samedi 2 mai 2015 15h37, François Lacombe fl.infosrese...@gmail.com a
écrit :
Le 2 mai 2015 00:09, dHuy Pierre dh...@yahoo.fr a écrit :
@Jérome: Merci de l'avoir expliqué. Je suis opposé au tag communication:*=
cependant, en effet je trouve que ces tags surchargeraient trop en cas de
données multiples et ne serons jamais assez exhaustif, on risquerait de se
retrouver avec des key user defined...). Pour le type d'antenne, je propose
déjà antenna:shape (antenna:type éventuellement, j'étais partagé en écrivant).
Mais on reste sur le même set d'info a taguer.
@Lacombe, comme précisé plus haut, les commentaires sont souhaités entre
crochet, j'ai donc rajouté pour les tiens mais du coup j'y réponds ici. Ah et
si possible sur le pad les commentaires sont plus intéressants s'ils
constituent un texte à compléter et pas une remarque qui nécessite débat, plus
approprié à la ML (ou au canal de communication si subitement on s'y connecte
en masse), je supprimerai du texte les superflus mais il sera possible d'en
retrouver la trace dans l'interface.
Désolé, c'est nouveau pour moi.
- radio=repeater|relay ou autre: Non il s'agit d'élément immatériel, difficile
à vérifier en pratique et peu utile en carto, mais si quelqu'un d'autre les
souhaite, je suis à l'écoute de vos raisonnements. Je propose antenna=yes seul
sur un node en cas d'absence de support ponctuel (comme sur un immeuble)
Il s'agit de stations au sens ANFR.
Au sens OSM, ces stations seraient plutôt des relations entre les supports et
les antennes.
Les stations supportent le service, notre principal problème quand on veut
ajouter ces infos sur l'antenne directement.
On évite les chaines de ce genre :
operator={[TDF{FM|FH}][Opérateur privé{PMR}][SNCF{GSM R}][FREE MOBILE{UMTS
900|UMTS 2100|LTE 2600}]}
En indiquant l'opérateur sur les stations plus que sur le support ou l'antenne.
yes est une valeur par défaut, il faudrait utiliser le tag antenna pour y
ajouter d'autres infos (comme le type directement, au lieu de antenna:type=*,
on s'évite de créer une clé supplémentaire).
- tower:type=communication_tower conduisait jusqu'alors implicitement à
l'existence d'une antenne, ce que je défend c'est un tag unifié pour les
antennes. Mais donc non pas de confusions...
Implicitement, on peut affirmer plein de choses.
Que se passe-t-il si toutes les antennes ont été désinstallées ? On a toujours
un tower:type=communication_tower sans antennes.
Ces valeurs trappes font dire plein de choses et on a finalement pas l'info
qu'on cherche.
Avec les explications de cette nuit, je comprends mieux antenna=*, d'autant que
cette clé-ci est quand même moins sujette aux interprétations comme pour la
plupart des valeurs tower:type.
- Le fichier ANFR ne permettrait pas le placement: Relis ce qu'à écrit Jérôme.
Non en effet : c'est bien ce que je disais. C'était une affirmation.
- Une antenne radar/ une antenne onde courte... etc sont des antennes
colossales qui se remarque facilement en milieu urbain et qui constituent
toujours un repère, de même à la campagne.
On est d'accord là-dessus, l'objet du commentaire n'était pas sur le côté
représentatif de l'antenne ou non mais dans sa place dans le modèle.
Bref, en relisant c'était un peu HS, autant pour moi.
- La base de données opencellid/mozstumbler est approximative, mais elle peut
etre utile dans des pays qui ne possède pas un équivalent de l'anfr ou dont la
base serait non libre. Cela donne une position approximative d'une antenne
télécom. d'où la précision déjà présente sur la localisation.
Pas forcément : ce genre de base recense des endroits où on capte, mais
l'antenne peut être à des dizaines de km.
Le GSM fixe un rayon de cellule de 35 km pour que la communication puisse
s'effectuer
Cependant on peut capter la cellule bien plus loin si l'opérateur ne prend pas
les dispositions nécessaires.
C'est pour ca qu'il y a toujours un problème avec openCellID et autres : sans
infos plus précises, on ne sais toujours pas où sont les antennes en question.
On peut aussi être à côté d'une et en capter une bien plus loin.
J'ai laissé un commentaire parce que je ne comprends pas ce que tu veux y dire.
(J'ai intégré certains commentaires au texte aussi)
Les stations au sens ANFR ont pour principale utilité de savoir quel service
est derrière l'antenne.
L'antenne est uniquement faite pour une bande de fréquence. Après tu y fait
transiter ce que tu
Re: [OSM-talk-fr] Normalisation du tag antenne
Oups, le mulot avait dérapé... Salut Je suis un peu perdu. J'ai mis des commentaires dans le pad. Concrètement, j'ai compris que l'on veut intégrer dans OSM des infos sur les supports et les antennes. J'ai compris que la proposition de Phlippe Verdy vise à intégrer dans le même tag différentes informations liées à un même support et pas à une antenne au sens ANFR ! Je trouve aussi très bien le modèle de représentation proposé par Philippe. Du coup, je ne comprends pas bien l'intérêt de proposer des tags liés à une antenne (au sens ANFR). Ce serait bien de clarifier le modèle de données de ANFR. 1 support support n station 1 station supporte n antennes 1 antenne supporte n émetteur 1 émetteur supporte n bandes Cas concret. Le support 687819 supporte 3 stations (sur un chateau d'eau) 0220220007 (FH) 022033 (E-Message) 090003 (Telecom) La station 090003 0220220007 supporte 6 antennes (2 * 3 antennes panneau : une antenne par secteur) 325425 2487083 2487081 2487079 162468 162466 L'antenne 325425 supporte 2 émetteurs 3220894;GSM 1800 3220896;UMTS 2100 L'émetteur 3220896 supporte 3 bandes 1964,9;1979,7 1910,1;1915,1 2154,9;2169,7 Concrètement, on taggue comment ? Eric 2015-05-02 13:53 GMT+02:00 dHuy Pierre dh...@yahoo.fr: @Verdy: Je soutiens ton idée, je dis juste qu'il faudrait la voter ensemble, comme tu l'a dit, c'est l'affaire de la communauté. Le Samedi 2 mai 2015 13h43, Eric Debeau eric.deb...@gmail.com a écrit : Salut J'a Eric 2015-05-02 5:04 GMT+02:00 Philippe Verdy verd...@wanadoo.fr: Le 2 mai 2015 00:21, dHuy Pierre dh...@yahoo.fr a écrit : L'idée de Verdy est pas al en la matière mais non normalisé encore, OSM non plus n'est pas normalisé dans ses données: il crée lui même ses propres standards avec nous tous. J'ai proposé un truc générique proche de JSON mais plus compact et adapté aux usages d'OSM, rien de plus, mais assez générique pour coder des données structurées sans avoir pléthore de tags et de codages spécifiques pour chaque tag particulier (celui des lanes est actuellement une horreur, tout le monde s'y trompe). ___ 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 ___ 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
Re: [OSM-talk-fr] Normalisation du tag antenne
Salut J'a Eric 2015-05-02 5:04 GMT+02:00 Philippe Verdy verd...@wanadoo.fr: Le 2 mai 2015 00:21, dHuy Pierre dh...@yahoo.fr a écrit : L'idée de Verdy est pas al en la matière mais non normalisé encore, OSM non plus n'est pas normalisé dans ses données: il crée lui même ses propres standards avec nous tous. J'ai proposé un truc générique proche de JSON mais plus compact et adapté aux usages d'OSM, rien de plus, mais assez générique pour coder des données structurées sans avoir pléthore de tags et de codages spécifiques pour chaque tag particulier (celui des lanes est actuellement une horreur, tout le monde s'y trompe). ___ 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
Re: [OSM-talk-fr] Normalisation du tag antenne
@Nicolas: mea culpa, je vis en milieu urbain dense dans ce cas! Je ne parlais
que d'un doublement de vérification des données en cas de cartographie visuelle
pour les pays sans opendata sur cette base.@Debeau: je viens de voir ton
message dans le pad, mais du coup je ne suis pas sûr que ça soit pertinenet
pour la page du tag antenna.@Lacombe, @Verdy @Amagat: du coup j'attends de voir
une propal clairement définie pour les associations. Je la formulerai au mieux
(ou copie/collerai si vous avez vraiment bien expliqué)
Le Samedi 2 mai 2015 17h53, Nicolas CORBEL nicolas.cor...@gmail.com a
écrit :
OCID n'est pas précis à 100m, je t'assure. Ou alors ponctuellement sur des
endroits où énormément de mesures ont été faites, dans des zones très denses.
Et surtout, OCID est plus qu'incomplet. Je ne pense pas qu'il faille continuer
dans cette voie.
Je crois que le propos de François c'est qu'il n'était pas possible de placer
précisement les antennes, et que seul le support dispose de coordonnées GPS
dans le jeu de données dont on parle ici.
2015-05-02 17:48 GMT+02:00 dHuy Pierre dh...@yahoo.fr:
Avant la proposition j'attends au moins une unité dans le camp talk-fr
:pOpencellid se base sur des séries de mesures cumulés pour estimé la position
de l'antenne en fonction de la réception. Ces estimations donnent une précision
de 100m (donc contestable mais intéressant).Bon je crois crois qu'on se
comprend pas pour les données du set ANFR, il y a la position GPS.Pour ta
relation je te laisse proposer ton modèle alternatif clairement avec la
relation. Et une fois le consens obtenu je le poste sur le wiki.
Le Samedi 2 mai 2015 15h37, François Lacombe fl.infosrese...@gmail.com a
écrit :
Le 2 mai 2015 00:09, dHuy Pierre dh...@yahoo.fr a écrit :
@Jérome: Merci de l'avoir expliqué. Je suis opposé au tag communication:*=
cependant, en effet je trouve que ces tags surchargeraient trop en cas de
données multiples et ne serons jamais assez exhaustif, on risquerait de se
retrouver avec des key user defined...). Pour le type d'antenne, je propose
déjà antenna:shape (antenna:type éventuellement, j'étais partagé en écrivant).
Mais on reste sur le même set d'info a taguer.
@Lacombe, comme précisé plus haut, les commentaires sont souhaités entre
crochet, j'ai donc rajouté pour les tiens mais du coup j'y réponds ici. Ah et
si possible sur le pad les commentaires sont plus intéressants s'ils
constituent un texte à compléter et pas une remarque qui nécessite débat, plus
approprié à la ML (ou au canal de communication si subitement on s'y connecte
en masse), je supprimerai du texte les superflus mais il sera possible d'en
retrouver la trace dans l'interface.
Désolé, c'est nouveau pour moi.
- radio=repeater|relay ou autre: Non il s'agit d'élément immatériel, difficile
à vérifier en pratique et peu utile en carto, mais si quelqu'un d'autre les
souhaite, je suis à l'écoute de vos raisonnements. Je propose antenna=yes seul
sur un node en cas d'absence de support ponctuel (comme sur un immeuble)
Il s'agit de stations au sens ANFR.
Au sens OSM, ces stations seraient plutôt des relations entre les supports et
les antennes.
Les stations supportent le service, notre principal problème quand on veut
ajouter ces infos sur l'antenne directement.
On évite les chaines de ce genre :
operator={[TDF{FM|FH}][Opérateur privé{PMR}][SNCF{GSM R}][FREE MOBILE{UMTS
900|UMTS 2100|LTE 2600}]}
En indiquant l'opérateur sur les stations plus que sur le support ou l'antenne.
yes est une valeur par défaut, il faudrait utiliser le tag antenna pour y
ajouter d'autres infos (comme le type directement, au lieu de antenna:type=*,
on s'évite de créer une clé supplémentaire).
- tower:type=communication_tower conduisait jusqu'alors implicitement à
l'existence d'une antenne, ce que je défend c'est un tag unifié pour les
antennes. Mais donc non pas de confusions...
Implicitement, on peut affirmer plein de choses.
Que se passe-t-il si toutes les antennes ont été désinstallées ? On a toujours
un tower:type=communication_tower sans antennes.
Ces valeurs trappes font dire plein de choses et on a finalement pas l'info
qu'on cherche.
Avec les explications de cette nuit, je comprends mieux antenna=*, d'autant que
cette clé-ci est quand même moins sujette aux interprétations comme pour la
plupart des valeurs tower:type.
- Le fichier ANFR ne permettrait pas le placement: Relis ce qu'à écrit Jérôme.
Non en effet : c'est bien ce que je disais. C'était une affirmation.
- Une antenne radar/ une antenne onde courte... etc sont des antennes
colossales qui se remarque facilement en milieu urbain et qui constituent
toujours un repère, de même à la campagne.
On est d'accord là-dessus, l'objet du commentaire n'était pas sur le côté
représentatif de l'antenne ou non mais dans sa place dans le modèle.
Bref, en relisant c'était un peu HS, autant pour moi.
- La base de données opencellid/mozstumbler est
Re: [OSM-talk-fr] Normalisation du tag antenne
OCID n'est pas précis à 100m, je t'assure. Ou alors ponctuellement sur des
endroits où énormément de mesures ont été faites, dans des zones très
denses. Et surtout, OCID est plus qu'incomplet. Je ne pense pas qu'il
faille continuer dans cette voie.
Je crois que le propos de François c'est qu'il n'était pas possible de
placer précisement les antennes, et que seul le support dispose de
coordonnées GPS dans le jeu de données dont on parle ici.
2015-05-02 17:48 GMT+02:00 dHuy Pierre dh...@yahoo.fr:
Avant la proposition j'attends au moins une unité dans le camp talk-fr :p
Opencellid se base sur des séries de mesures cumulés pour estimé la
position de l'antenne en fonction de la réception. Ces estimations donnent
une précision de 100m (donc contestable mais intéressant).
Bon je crois crois qu'on se comprend pas pour les données du set ANFR, il
y a la position GPS.
Pour ta relation je te laisse proposer ton modèle alternatif clairement
avec la relation. Et une fois le consens obtenu je le poste sur le wiki.
Le Samedi 2 mai 2015 15h37, François Lacombe fl.infosrese...@gmail.com
a écrit :
Le 2 mai 2015 00:09, dHuy Pierre dh...@yahoo.fr a écrit :
@Jérome: Merci de l'avoir expliqué. Je suis opposé au tag communication:*=
cependant, en effet je trouve que ces tags surchargeraient trop en cas de
données multiples et ne serons jamais assez exhaustif, on risquerait de se
retrouver avec des key user defined...). Pour le type d'antenne, je propose
déjà antenna:shape (antenna:type éventuellement, j'étais partagé en
écrivant). Mais on reste sur le même set d'info a taguer.
@Lacombe, comme précisé plus haut, les commentaires sont souhaités entre
crochet, j'ai donc rajouté pour les tiens mais du coup j'y réponds ici. Ah
et si possible sur le pad les commentaires sont plus intéressants s'ils
constituent un texte à compléter et pas une remarque qui nécessite débat,
plus approprié à la ML (ou au canal de communication si subitement on s'y
connecte en masse), je supprimerai du texte les superflus mais il sera
possible d'en retrouver la trace dans l'interface.
Désolé, c'est nouveau pour moi.
- radio=repeater|relay ou autre: Non il s'agit d'élément immatériel,
difficile à vérifier en pratique et peu utile en carto, mais si quelqu'un
d'autre les souhaite, je suis à l'écoute de vos raisonnements. Je propose
antenna=yes seul sur un node en cas d'absence de support ponctuel (comme
sur un immeuble)
Il s'agit de stations au sens ANFR.
Au sens OSM, ces stations seraient plutôt des relations entre les supports
et les antennes.
Les stations supportent le service, notre principal problème quand on veut
ajouter ces infos sur l'antenne directement.
On évite les chaines de ce genre :
operator={[TDF{FM|FH}][Opérateur privé{PMR}][SNCF{GSM R}][FREE
MOBILE{UMTS 900|UMTS 2100|LTE 2600}]}
En indiquant l'opérateur sur les stations plus que sur le support ou
l'antenne.
yes est une valeur par défaut, il faudrait utiliser le tag antenna pour y
ajouter d'autres infos (comme le type directement, au lieu de
antenna:type=*, on s'évite de créer une clé supplémentaire).
- tower:type=communication_tower conduisait jusqu'alors implicitement à
l'existence d'une antenne, ce que je défend c'est un tag unifié pour les
antennes. Mais donc non pas de confusions...
Implicitement, on peut affirmer plein de choses.
Que se passe-t-il si toutes les antennes ont été désinstallées ? On a
toujours un tower:type=communication_tower sans antennes.
Ces valeurs trappes font dire plein de choses et on a finalement pas
l'info qu'on cherche.
Avec les explications de cette nuit, je comprends mieux antenna=*,
d'autant que cette clé-ci est quand même moins sujette aux interprétations
comme pour la plupart des valeurs tower:type.
- Le fichier ANFR ne permettrait pas le placement: Relis ce qu'à écrit
Jérôme.
Non en effet : c'est bien ce que je disais. C'était une affirmation.
- Une antenne radar/ une antenne onde courte... etc sont des antennes
colossales qui se remarque facilement en milieu urbain et qui constituent
toujours un repère, de même à la campagne.
On est d'accord là-dessus, l'objet du commentaire n'était pas sur le côté
représentatif de l'antenne ou non mais dans sa place dans le modèle.
Bref, en relisant c'était un peu HS, autant pour moi.
- La base de données opencellid/mozstumbler est approximative, mais elle
peut etre utile dans des pays qui ne possède pas un équivalent de l'anfr ou
dont la base serait non libre. Cela donne une position approximative d'une
antenne télécom. d'où la précision déjà présente sur la localisation.
Pas forcément : ce genre de base recense des endroits où on capte, mais
l'antenne peut être à des dizaines de km.
Le GSM fixe un rayon de cellule de 35 km pour que la communication puisse
s'effectuer
Cependant on peut capter la cellule bien plus loin si l'opérateur ne prend
pas les dispositions nécessaires.
C'est pour ca qu'il y a
Re: [OSM-talk-fr] Normalisation du tag antenne
Pour ta norme pour cartographier les données associées aux antennes si tu veux.
Le Samedi 2 mai 2015 23h08, Philippe Verdy verd...@wanadoo.fr a écrit :
Ou ai-je parlé d'association, je n'ai même pas vu ce terme utilisé dans
cette discussion...
Le 2 mai 2015 18:00, dHuy Pierre dh...@yahoo.fr a écrit :
@Nicolas: mea culpa, je vis en milieu urbain dense dans ce cas! Je ne parlais
que d'un doublement de vérification des données en cas de cartographie visuelle
pour les pays sans opendata sur cette base.@Debeau: je viens de voir ton
message dans le pad, mais du coup je ne suis pas sûr que ça soit pertinenet
pour la page du tag antenna.@Lacombe, @Verdy @Amagat: du coup j'attends de voir
une propal clairement définie pour les associations. Je la formulerai au mieux
(ou copie/collerai si vous avez vraiment bien expliqué)
Le Samedi 2 mai 2015 17h53, Nicolas CORBEL nicolas.cor...@gmail.com a
écrit :
OCID n'est pas précis à 100m, je t'assure. Ou alors ponctuellement sur des
endroits où énormément de mesures ont été faites, dans des zones très denses.
Et surtout, OCID est plus qu'incomplet. Je ne pense pas qu'il faille continuer
dans cette voie.
Je crois que le propos de François c'est qu'il n'était pas possible de placer
précisement les antennes, et que seul le support dispose de coordonnées GPS
dans le jeu de données dont on parle ici.
2015-05-02 17:48 GMT+02:00 dHuy Pierre dh...@yahoo.fr:
Avant la proposition j'attends au moins une unité dans le camp talk-fr
:pOpencellid se base sur des séries de mesures cumulés pour estimé la position
de l'antenne en fonction de la réception. Ces estimations donnent une précision
de 100m (donc contestable mais intéressant).Bon je crois crois qu'on se
comprend pas pour les données du set ANFR, il y a la position GPS.Pour ta
relation je te laisse proposer ton modèle alternatif clairement avec la
relation. Et une fois le consens obtenu je le poste sur le wiki.
Le Samedi 2 mai 2015 15h37, François Lacombe fl.infosrese...@gmail.com a
écrit :
Le 2 mai 2015 00:09, dHuy Pierre dh...@yahoo.fr a écrit :
@Jérome: Merci de l'avoir expliqué. Je suis opposé au tag communication:*=
cependant, en effet je trouve que ces tags surchargeraient trop en cas de
données multiples et ne serons jamais assez exhaustif, on risquerait de se
retrouver avec des key user defined...). Pour le type d'antenne, je propose
déjà antenna:shape (antenna:type éventuellement, j'étais partagé en écrivant).
Mais on reste sur le même set d'info a taguer.
@Lacombe, comme précisé plus haut, les commentaires sont souhaités entre
crochet, j'ai donc rajouté pour les tiens mais du coup j'y réponds ici. Ah et
si possible sur le pad les commentaires sont plus intéressants s'ils
constituent un texte à compléter et pas une remarque qui nécessite débat, plus
approprié à la ML (ou au canal de communication si subitement on s'y connecte
en masse), je supprimerai du texte les superflus mais il sera possible d'en
retrouver la trace dans l'interface.
Désolé, c'est nouveau pour moi.
- radio=repeater|relay ou autre: Non il s'agit d'élément immatériel, difficile
à vérifier en pratique et peu utile en carto, mais si quelqu'un d'autre les
souhaite, je suis à l'écoute de vos raisonnements. Je propose antenna=yes seul
sur un node en cas d'absence de support ponctuel (comme sur un immeuble)
Il s'agit de stations au sens ANFR.
Au sens OSM, ces stations seraient plutôt des relations entre les supports et
les antennes.
Les stations supportent le service, notre principal problème quand on veut
ajouter ces infos sur l'antenne directement.
On évite les chaines de ce genre :
operator={[TDF{FM|FH}][Opérateur privé{PMR}][SNCF{GSM R}][FREE MOBILE{UMTS
900|UMTS 2100|LTE 2600}]}
En indiquant l'opérateur sur les stations plus que sur le support ou l'antenne.
yes est une valeur par défaut, il faudrait utiliser le tag antenna pour y
ajouter d'autres infos (comme le type directement, au lieu de antenna:type=*,
on s'évite de créer une clé supplémentaire).
- tower:type=communication_tower conduisait jusqu'alors implicitement à
l'existence d'une antenne, ce que je défend c'est un tag unifié pour les
antennes. Mais donc non pas de confusions...
Implicitement, on peut affirmer plein de choses.
Que se passe-t-il si toutes les antennes ont été désinstallées ? On a toujours
un tower:type=communication_tower sans antennes.
Ces valeurs trappes font dire plein de choses et on a finalement pas l'info
qu'on cherche.
Avec les explications de cette nuit, je comprends mieux antenna=*, d'autant que
cette clé-ci est quand même moins sujette aux interprétations comme pour la
plupart des valeurs tower:type.
- Le fichier ANFR ne permettrait pas le placement: Relis ce qu'à écrit Jérôme.
Non en effet : c'est bien ce que je disais. C'était une affirmation.
- Une antenne radar/ une antenne onde courte... etc sont des antennes
colossales qui se remarque facilement en milieu
Re: [OSM-talk-fr] Normalisation du tag antenne
Ou ai-je parlé d'association, je n'ai même pas vu ce terme utilisé dans
cette discussion...
Le 2 mai 2015 18:00, dHuy Pierre dh...@yahoo.fr a écrit :
@Nicolas: mea culpa, je vis en milieu urbain dense dans ce cas! Je ne
parlais que d'un doublement de vérification des données en cas de
cartographie visuelle pour les pays sans opendata sur cette base.
@Debeau: je viens de voir ton message dans le pad, mais du coup je ne suis
pas sûr que ça soit pertinenet pour la page du tag antenna.
@Lacombe, @Verdy @Amagat: du coup j'attends de voir une propal clairement
définie pour les associations. Je la formulerai au mieux (ou copie/collerai
si vous avez vraiment bien expliqué)
Le Samedi 2 mai 2015 17h53, Nicolas CORBEL nicolas.cor...@gmail.com a
écrit :
OCID n'est pas précis à 100m, je t'assure. Ou alors ponctuellement sur des
endroits où énormément de mesures ont été faites, dans des zones très
denses. Et surtout, OCID est plus qu'incomplet. Je ne pense pas qu'il
faille continuer dans cette voie.
Je crois que le propos de François c'est qu'il n'était pas possible de
placer précisement les antennes, et que seul le support dispose de
coordonnées GPS dans le jeu de données dont on parle ici.
2015-05-02 17:48 GMT+02:00 dHuy Pierre dh...@yahoo.fr:
Avant la proposition j'attends au moins une unité dans le camp talk-fr :p
Opencellid se base sur des séries de mesures cumulés pour estimé la
position de l'antenne en fonction de la réception. Ces estimations donnent
une précision de 100m (donc contestable mais intéressant).
Bon je crois crois qu'on se comprend pas pour les données du set ANFR, il
y a la position GPS.
Pour ta relation je te laisse proposer ton modèle alternatif clairement
avec la relation. Et une fois le consens obtenu je le poste sur le wiki.
Le Samedi 2 mai 2015 15h37, François Lacombe fl.infosrese...@gmail.com
a écrit :
Le 2 mai 2015 00:09, dHuy Pierre dh...@yahoo.fr a écrit :
@Jérome: Merci de l'avoir expliqué. Je suis opposé au tag communication:*=
cependant, en effet je trouve que ces tags surchargeraient trop en cas de
données multiples et ne serons jamais assez exhaustif, on risquerait de se
retrouver avec des key user defined...). Pour le type d'antenne, je propose
déjà antenna:shape (antenna:type éventuellement, j'étais partagé en
écrivant). Mais on reste sur le même set d'info a taguer.
@Lacombe, comme précisé plus haut, les commentaires sont souhaités entre
crochet, j'ai donc rajouté pour les tiens mais du coup j'y réponds ici. Ah
et si possible sur le pad les commentaires sont plus intéressants s'ils
constituent un texte à compléter et pas une remarque qui nécessite débat,
plus approprié à la ML (ou au canal de communication si subitement on s'y
connecte en masse), je supprimerai du texte les superflus mais il sera
possible d'en retrouver la trace dans l'interface.
Désolé, c'est nouveau pour moi.
- radio=repeater|relay ou autre: Non il s'agit d'élément immatériel,
difficile à vérifier en pratique et peu utile en carto, mais si quelqu'un
d'autre les souhaite, je suis à l'écoute de vos raisonnements. Je propose
antenna=yes seul sur un node en cas d'absence de support ponctuel (comme
sur un immeuble)
Il s'agit de stations au sens ANFR.
Au sens OSM, ces stations seraient plutôt des relations entre les supports
et les antennes.
Les stations supportent le service, notre principal problème quand on veut
ajouter ces infos sur l'antenne directement.
On évite les chaines de ce genre :
operator={[TDF{FM|FH}][Opérateur privé{PMR}][SNCF{GSM R}][FREE
MOBILE{UMTS 900|UMTS 2100|LTE 2600}]}
En indiquant l'opérateur sur les stations plus que sur le support ou
l'antenne.
yes est une valeur par défaut, il faudrait utiliser le tag antenna pour y
ajouter d'autres infos (comme le type directement, au lieu de
antenna:type=*, on s'évite de créer une clé supplémentaire).
- tower:type=communication_tower conduisait jusqu'alors implicitement à
l'existence d'une antenne, ce que je défend c'est un tag unifié pour les
antennes. Mais donc non pas de confusions...
Implicitement, on peut affirmer plein de choses.
Que se passe-t-il si toutes les antennes ont été désinstallées ? On a
toujours un tower:type=communication_tower sans antennes.
Ces valeurs trappes font dire plein de choses et on a finalement pas
l'info qu'on cherche.
Avec les explications de cette nuit, je comprends mieux antenna=*,
d'autant que cette clé-ci est quand même moins sujette aux interprétations
comme pour la plupart des valeurs tower:type.
- Le fichier ANFR ne permettrait pas le placement: Relis ce qu'à écrit
Jérôme.
Non en effet : c'est bien ce que je disais. C'était une affirmation.
- Une antenne radar/ une antenne onde courte... etc sont des antennes
colossales qui se remarque facilement en milieu urbain et qui constituent
toujours un repère, de même à la campagne.
On est d'accord là-dessus, l'objet du commentaire n'était pas sur le
Re: [OSM-talk-fr] Normalisation du tag antenne
Le 2 mai 2015 23:14, dHuy Pierre dh...@yahoo.fr a écrit : Pour ta norme pour cartographier les données associées aux antennes si tu veux. Je n'ai pas parlé de ma norme... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Normalisation du tag antenne
On 01/05/2015 23:05, Jérôme Amagat wrote: Il y a 5 fichier texte [Supports, Stations, Antennes, Emetteurs, Bandes] On peut passer d'un fichier a l'autre avec differents id. Voilà ce que fournit donc l'anfr. Bien sur, RIEN N'OBLIGE DE TOUT INTÉGRÉ DANS OSM. Mon opinion est que l'intérêt d'OSM réside dans Supports et Antennes et que le reste a plutôt vocation à rester externe. C'est le consensus ou y-a-t-il d'autres opinions ici ? Bon - j'ai vu quelques mentions de bandes de fréquences dans le débat... Pour les supports, je pense qu'il faut utiliser les tag déjà en circulation les différents man_made (mast , tower, communications_tower) et ne rien mettre pour immeuble,batiment... qui sont déjà présent en surfacique. plus height= et owner=. jusque là on n'est pas sur des choses nouvelles Ca me paraît bien - le fichier des Supports est une source supplémentaire pour qualifier les objets identifiés dans l'imagerie orbitale par le cartographe distant, donc un gain pour OSM avant-même toute considération spécifique aux télécommunications. (peut être reparler de mast , tower, communications_tower, moi je comprends pas les différences) Tu n'es pas seul... First question: Is it a mast or a tower ? http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dcommunications_tower#First_question:_Is_it_a_mast_or_a_tower.3F http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dcommunications_tower : man_made=communications_tower has stairs and a lift inside, whereas as man_made=tower, tower:type=communication has to be climbed on the outside http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dmast montre un exemple où man_made=mast et man_made=tower sont tous les deux valides - la limite est floue. Pour le reste, déjà il peut bien il y avoir 30 antennes sur un pylône, dans osm les antennes et le pylône c'est un node donc il faut mettre les tags sur ce node. il faut choisir le niveau de detail que l'on veut et que l'on peut mettre dans osm et le niveau de complexité. Pour illustrer, pour ceux qui n'ont pas l'habitude d'en voir... http://wiki.openstreetmap.org/w/images/a/a5/Frazier_Peak_microwave_relay_tower.jpg Aucun pylone ne résistera au poids d'autant d'étiquettes Openstreetmap... [..] Le tag antenna = yes peut permettre aussi d'indiquer le type d'antenne : antenna = multi lorsque'il y a différentes antennes antenna = panneau ou antenne parabolique ... quand il n'y a qu'une antenne Une solution envisageable serait de distinguer le cas de l'antenne isolée de celui de l'antenne sur pylône multifonctions: - Dans le cas de l'antenne isolée, on étiquette l'antenne dans toute sa splendeur - Dans le cas du méga-pylône, on énumère les fonctions du pylône sans détailler chaque antenne Bon... J'avoue qu'il ne s'agit que d'un contournement du problème et non d'une solution - mais ça permet de commencer et on pourra toujours se pencher ultérieurement sur le cas des méga-pylône... D'ici là peut-être qu'une idée géniale sera apparue pour les traiter. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Normalisation du tag antenne
L'idée de Verdy est pas al en la matière mais non normalisé encore, donc ta solution parait pas mal.Pour te répondre le consensus est clairement sur operator, usage (avec GPS, GLONASS, GSM, LTE... etc), l'apparence de l'antenne shape/type (à choisir). Sinon pour ton mégapylone, je ne connais pas les données sur ce point mais combien d'opérateurs et quel type d'usage? Le Samedi 2 mai 2015 0h14, Jean-Marc Liotier j...@liotier.org a écrit : On 01/05/2015 23:05, Jérôme Amagat wrote: Il y a 5 fichier texte [Supports, Stations, Antennes, Emetteurs, Bandes] On peut passer d'un fichier a l'autre avec differents id. Voilà ce que fournit donc l'anfr. Bien sur, RIEN N'OBLIGE DE TOUT INTÉGRÉ DANS OSM. Mon opinion est que l'intérêt d'OSM réside dans Supports et Antennes et que le reste a plutôt vocation à rester externe. C'est le consensus ou y-a-t-il d'autres opinions ici ? Bon - j'ai vu quelques mentions de bandes de fréquences dans le débat... Pour les supports, je pense qu'il faut utiliser les tag déjà en circulation les différents man_made (mast , tower, communications_tower) et ne rien mettre pour immeuble,batiment... qui sont déjà présent en surfacique. plus height= et owner=. jusque là on n'est pas sur des choses nouvelles Ca me paraît bien - le fichier des Supports est une source supplémentaire pour qualifier les objets identifiés dans l'imagerie orbitale par le cartographe distant, donc un gain pour OSM avant-même toute considération spécifique aux télécommunications. (peut être reparler de mast , tower, communications_tower, moi je comprends pas les différences) Tu n'es pas seul... First question: Is it a mast or a tower ? http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dcommunications_tower#First_question:_Is_it_a_mast_or_a_tower.3F http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dcommunications_tower : man_made=communications_tower has stairs and a lift inside, whereas as man_made=tower, tower:type=communication has to be climbed on the outside http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dmast montre un exemple où man_made=mast et man_made=tower sont tous les deux valides - la limite est floue. Pour le reste, déjà il peut bien il y avoir 30 antennes sur un pylône, dans osm les antennes et le pylône c'est un node donc il faut mettre les tags sur ce node. il faut choisir le niveau de detail que l'on veut et que l'on peut mettre dans osm et le niveau de complexité. Pour illustrer, pour ceux qui n'ont pas l'habitude d'en voir... http://wiki.openstreetmap.org/w/images/a/a5/Frazier_Peak_microwave_relay_tower.jpg Aucun pylone ne résistera au poids d'autant d'étiquettes Openstreetmap... [..] Le tag antenna = yes peut permettre aussi d'indiquer le type d'antenne : antenna = multi lorsque'il y a différentes antennes antenna = panneau ou antenne parabolique ... quand il n'y a qu'une antenne Une solution envisageable serait de distinguer le cas de l'antenne isolée de celui de l'antenne sur pylône multifonctions: - Dans le cas de l'antenne isolée, on étiquette l'antenne dans toute sa splendeur - Dans le cas du méga-pylône, on énumère les fonctions du pylône sans détailler chaque antenne Bon... J'avoue qu'il ne s'agit que d'un contournement du problème et non d'une solution - mais ça permet de commencer et on pourra toujours se pencher ultérieurement sur le cas des méga-pylône... D'ici là peut-être qu'une idée géniale sera apparue pour les traiter. ___ 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
Re: [OSM-talk-fr] Normalisation du tag antenne
Le 2 mai 2015 00:09, dHuy Pierre dh...@yahoo.fr a écrit : @Verdy: un jour faudra que tu lances une encyclopédie :) A l'heure où les encyclopédies arrêtent les unes après les autres... Wikipédia est là pour durer (même s'il ne peut répondre à tout et si on le critique beaucoup c'est devenu le point d'entrée universel pour trouver autre chose via les références externes... car oui on ne doit pas s'en contenter et passer le contenu en revue en cherchant les références et en s'en servant). Il ne restera plus que les ouvrages spécialisés et guides pour les nuls (d'ailleurs de moins en moins vendus sous forme imprimée mais juste en ligne sous forme d'eBook ou de service de questions à la demande). Sinon il restera juste les ouvrages universitaires pour la recherche et les publications privées industrielles (quand elles sont accessibles... sinon il faut attendre la publication d'un brevet), même même eux maintenant copient (ou plagient) Wikipédia sans forcément le citer. Le plagiat ça n'a jamais été mon truc, j'ai un regard critique sur tout et forcément ce que je dis ou écrit est forcément orienté, et tant pis si d'autres ne sont pas d'accord, au moins je ne suis pas là pour copier les autres et je les incite à user de leurs propre esprit critique et leur originalité pour me contredire. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Normalisation du tag antenne
@Jérome: Merci de l'avoir expliqué. Je suis opposé au tag communication:*= cependant, en effet je trouve que ces tags surchargeraient trop en cas de données multiples et ne serons jamais assez exhaustif, on risquerait de se retrouver avec des key user defined...). Pour le type d'antenne, je propose déjà antenna:shape (antenna:type éventuellement, j'étais partagé en écrivant). Mais on reste sur le même set d'info a taguer.@Lacombe, comme précisé plus haut, les commentaires sont souhaités entre crochet, j'ai donc rajouté pour les tiens mais du coup j'y réponds ici. Ah et si possible sur le pad les commentaires sont plus intéressants s'ils constituent un texte à compléter et pas une remarque qui nécessite débat, plus approprié à la ML (ou au canal de communication si subitement on s'y connecte en masse), je supprimerai du texte les superflus mais il sera possible d'en retrouver la trace dans l'interface. - radio=repeater|relay ou autre: Non il s'agit d'élément immatériel, difficile à vérifier en pratique et peu utile en carto, mais si quelqu'un d'autre les souhaite, je suis à l'écoute de vos raisonnements. Je propose antenna=yes seul sur un node en cas d'absence de support ponctuel (comme sur un immeuble) - tower:type=communication_tower conduisait jusqu'alors implicitement à l'existence d'une antenne, ce que je défend c'est un tag unifié pour les antennes. Mais donc non pas de confusions... - Le fichier ANFR ne permettrait pas le placement: Relis ce qu'à écrit Jérôme.- Une antenne radar/ une antenne onde courte... etc sont des antennes colossales qui se remarque facilement en milieu urbain et qui constituent toujours un repère, de même à la campagne.- La base de données opencellid/mozstumbler est approximative, mais elle peut etre utile dans des pays qui ne possède pas un équivalent de l'anfr ou dont la base serait non libre. Cela donne une position approximative d'une antenne télécom. d'où la précision déjà présente sur la localisation.J'ai laissé un commentaire parce que je ne comprends pas ce que tu veux y dire. (J'ai intégré certains commentaires au texte aussi)@Verdy: un jour faudra que tu lances une encyclopédie :) Le Vendredi 1 mai 2015 23h06, Jérôme Amagat jerome.ama...@gmail.com a écrit : Le 1 mai 2015 21:42, François Lacombe fl.infosrese...@gmail.com a écrit : Je ne comprends toujours pas le lien entre ce qui est dans le fichier ANFR et un possible inventaire des antennes dans OSM. Le fichier ANFR décris au mieux une station d'émission pouvant comprendre plusieurs antennes. Le support de l'ANFR n'est pas l'antenne. La plupart des supports sont occupés par une multitude d'antennes. Du coup, si on pouvait avoir quelques explications supplémentaires sur le raisonnement, elles sont les bienvenues. Tu n'as pas du regarder entièrement ce qu'a libérer l’anfr. Il y a 5 fichier texte qui liste chaque'un quelque chose de différent : les Supports (pylône, mat, immeuble ...) accueillant des antennes avec position, hauteur, propriétaire, ça c'est sur ça doit être intégrer dans osm. ensuite les Stations (il peut il y en avoir plusieurs par support) avec l’opérateur (orange,sncf,tdf...) et des dates (implantation,mise en service et modification). Puis les Antennes (il peut il y en avoir plusieurs par station) avec son type (panneau, antenne parabolique...) et des info sur cette antenne (dimension, azimute...). Puis les émetteurs (il peut il y en avoir plusieurs par antenne) avec le système (GSM 900, FM,). Et enfin les Bandes (il peut il y en avoir plusieurs par émetteur) avec le début et la fin d'une bande de fréquence.On peut passer d'un fichier a l'autre avec differents id. Voilà ce que fournit donc l'anfr. Bien sur, RIEN N'OBLIGE DE TOUT INTÉGRÉ DANS OSM. Pour les supports, je pense qu'il faut utiliser les tag déjà en circulation les différents man_made (mast , tower, communications_tower) et ne rien mettre pour immeuble,batiment... qui sont déjà présent en surfacique. plus height= et owner=. jusque là on n'est pas sur des choses nouvelles (peut être reparler de mast , tower, communications_tower, moi je comprends pas les différences).Pour le reste, déjà il peut bien il y avoir 30 antennes sur un pylône, dans osm les antennes et le pylône c'est un node donc il faut mettre les tags sur ce node.il faut choisir le niveau de detail que l'on veut et que l'on peut mettre dans osm et le niveau de complexité.operator=reseau =FM. FH; UMTS 900; LTE 260... ou faire comme proposer là : http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dmastcommunication:mobile_phone=yes; LTE 260;...communication:radio=yescommunication:television=yescommunication:microwave=yes Le tag antenna = yes peut permettre aussi d'indiquer le type d'antenne :antenna = multi lorsque'il y a différentes antennes antenna = panneau ou antenne parabolique ... quand il n'y a qu'une antenne ___ Talk-fr mailing list
Re: [OSM-talk-fr] Normalisation du tag antenne
Je ne comprends toujours pas le lien entre ce qui est dans le fichier ANFR et un possible inventaire des antennes dans OSM. Le fichier ANFR décris au mieux une station d'émission pouvant comprendre plusieurs antennes. Le support de l'ANFR n'est pas l'antenne. La plupart des supports sont occupés par une multitude d'antennes. Du coup, si on pouvait avoir quelques explications supplémentaires sur le raisonnement, elles sont les bienvenues. J'ai ajouté quelques commentaires dans le pad. Bonne soirée. *François Lacombe* fl dot infosreseaux At gmail dot com www.infos-reseaux.com @InfosReseaux http://www.twitter.com/InfosReseaux Le 1 mai 2015 13:55, dHuy Pierre dh...@yahoo.fr a écrit : Désolé de l'erreur de fenêtre Je t'invite à écrire une propal là desus en attendant je propose la combinaison pie/point virgule. Vu qu'il s'agitde listes associées simple c'est nickel, mais ta propal est extremement intéressant surtout que les bases tournent très bien avec de l'orienté document. Tu auras mon vote :) Le Vendredi 1 mai 2015 11h06, Philippe Verdy verd...@wanadoo.fr a écrit : Le 1 mai 2015 10:20, dHuy Pierre dh...@yahoo.fr a écrit : @Verdi: Hum je pense que tu pousses un peu loin le format initial de Jérome me paraissait bien Jérome avait plutôt été séduit par ma première proposition, cependant je parlais du problème plus général des infos structurées pour lesquelles on n'a pas de schéma clair permettant de les représenter de façon compacte mais lisible et parsable avec un système unique et non ambigu, et sans forcément multiplier le nombre de tags quand ce n'est pas toujours nécessaire (car des infos optionelles qui complètent un tag de base). Dans un proemier tmeps j'avais évoqué JSON (aussi XML mais trop verbeux), alors qu'on a moyen de faire un format JSON light reprenant les conventions habituelles d'OSM où tout est codé avec des valeurs atomiques de type chaine, et où on a des séparateurs point-virgule et pipe mais pas très lisibles quand on les combine et pas non plus suffisant au delaà des listes simples ! ___ 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
Re: [OSM-talk-fr] Normalisation du tag antenne
Le 1 mai 2015 10:20, dHuy Pierre dh...@yahoo.fr a écrit : @Verdi: Hum je pense que tu pousses un peu loin le format initial de Jérome me paraissait bien Jérome avait plutôt été séduit par ma première proposition, cependant je parlais du problème plus général des infos structurées pour lesquelles on n'a pas de schéma clair permettant de les représenter de façon compacte mais lisible et parsable avec un système unique et non ambigu, et sans forcément multiplier le nombre de tags quand ce n'est pas toujours nécessaire (car des infos optionelles qui complètent un tag de base). Dans un proemier tmeps j'avais évoqué JSON (aussi XML mais trop verbeux), alors qu'on a moyen de faire un format JSON light reprenant les conventions habituelles d'OSM où tout est codé avec des valeurs atomiques de type chaine, et où on a des séparateurs point-virgule et pipe mais pas très lisibles quand on les combine et pas non plus suffisant au delaà des listes simples ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Normalisation du tag antenne
@Verdi: Hum je pense que tu pousses un peu loin le format initial de Jérome me
paraissait bien@Lioter, on dispose déjà d'une liste je te la mets ci dessous:
le problème c'est que je voudrais éviter le jargons techniques pour des mots
compréhensibles et je ne connais pas la moitié de ses antennes. J'ai fait une
liste avec le nombre d'apparition dans le fichier:
211822 : Panneau (16)
83318 : Antenne parabolique (17)
12407 : Réseaux d'antennes panneaux (19)
10711 : Yagi (21)
8129 : Cierge/Perche (18)
4257 : Dipôle/Doublet (32)
4044 : Panneau Ran-Sharing (75)
3038 : Réseau vertical (26)
2712 : Tube (76)
2387 : Groundplane (12)
1513 : Logarithmique/Log périodique (14)
1392 : Active (directionnelle ou omnidirectionnelle) (2)
1126 : Dipôle large bande (5)
1082 : Antenne indoor pour téléphonie mobile (59)
777 : Trombone (33)
567 : Dièdre (50)
516 : Plan passif ou miroir (44)
472 : Fouet (9)
335 : Antenne à fentes (24)
199 : Cornet (46)
188 : Cylindre (49)
133 : Cable rayonnant (antenne coaxiale) (60)
114 : Discone (52)
112 : Helicoidal (56)
107 : Antenne Grille (45)
100 : Globe (51)
99 : Cigare (3)
95 : Multi Doublets/Multi dipoles (64)
94 : Colinéaire (35)
77 : Panneau bi-bandes (47)
66 : Antenne Gonio (31)
62 : Antenne radar (54)
59 : Sans type (0)
53 : Panneau bi-mode (74)
51 : Filaire (8)
41 : Antenne trisectorielle (58)
32 : Aérien issu de reprise des données électroniques (9)
21 : Réseau circulaire 49 antennes (25)
15 : Antenne à faisceau (65)
14 : Pylone Rayonnant (72)
12 : Antenne directive (7)
10 : Réseau linéaire 13 antennes (22)
10 : Antenne Plane (39)
9 : Obus (55)
9 : Antenne à jupe (66)
6 : Antenne HF (38)
4 : Antenne Parapluie (30)
4 : Antenne Marguerite (29)
3 : Panneau tri-bandes (48)
3 : Fuseau (10)
3 : Antenne biconique (67)
3 : Accordable (1)
2 : Système antennaire (20)
2 : Corolle (4)
2 : Antenne équidirective dans un plan (61)
1 : HLO (13)
1 : Antenne à rayonnement zenithal (63)
Le Vendredi 1 mai 2015 1h40, Philippe Verdy verd...@wanadoo.fr a écrit :
Note: je n'ai rien précisé concernant la façon de créer un échappement pour
les crochets, accolades, guillemets, apostrophes, et les pipe, virgules ou
point-virgules : il faudrait juste réserve le backslash ou d'un caractère
conventionel non réservé :- \\ pour le backslash \ lui même
- \| pour le pipe |- \= pour le signe égal =- \[ et \] pour les crochets [ et ]
- \{ et \} pour les accolades { et }- \s (semicolon) pour le point-virgule ; et
non pas \; afin de ne pas entrer en conflit avec les point-virgules séparateurs
par défaut des listes non ordonnées d'OSM)
Et pour le cas où des chaines déjà entre guillemets ou entre 'apostrophes'
sont utilisées:- \q (quote) pour les guillemets doubles ASCII - \a (apos) pour
les guillemets doubles ASCII '
Rien de prévu pour les échappements Unicode (ceux qui y tiennent pourront
ajouter \xNN ou \u ou \UNN), le but étant de coder directement les
caractères du texte si possible et d'utiliser sinon les échappements plus
compacts à deux caractères...
Avec ça on a tout pour imiter JSON, mais en plus compact et sans distinguer les
types numériques et chaines (il n'y a qu'un seul type d'atome : les chaînes).
Les schémas qui voudraient distinguer les types d'atomes devraient coder ça
dans les atomes-chaines par une convention comme type:valeur (un peut comme
le fait PHP pour sérialiser ses données), par exemple i:10 pour indiquer
l'entier 10 (nombre de bits non limité), n:10 pour le nombre flottant 10
(précision non limitée), s:10 pour indiquer la chaîne 10, n: pour
indiquer une valeur nil, d:date pour une date dans un format compatible
ISO8601 (avec séparateurs de champs de date optionnels pour que ce soit encore
plus compact)...
Le 1 mai 2015 01:17, Philippe Verdy verd...@wanadoo.fr a écrit :
Le 1 mai 2015 00:35, dHuy Pierre dh...@yahoo.fr a écrit :
@Verdy: Heureux de te voir enfin, j'étais presqu'étoné de ne pas te lire. Cette
propal de nomenclature est vraiment bonne.
Note: je n'ai pas voulu taper gags mais tags (mais sur le coup le
smartphone que j'ai utilisé temporairement, le temps d'une indisponibilité du
système sur PC, n'en a fait qu'à sa tête malgré plusieurs corrections
successives de ce mot, il a encore été remplacé contre ma volonté lors de
l'envoi...)
Personnellement je n'ai jamais aimé le fait de mêler deux types de séparateurs
dans les tags lanes, c'est très peu lisible et trompeur. Et j'aurais préféré un
codage de type JSON (mais encore un peu plus compact), sans aucun point-virgule
(sauf si la structure principale est celle d'une liste non ordonnée: aucun
point-virgule dans les éléments)
Bref si on veut tout mettre dans un seul tag, permettre alors l'usage des
accolades, et dans ce cas dans les accolades permettre d'utilier guillements et
apostrophes ASCII pour
Re: [OSM-talk-fr] Normalisation du tag antenne
Le 1 mai 2015 21:42, François Lacombe fl.infosrese...@gmail.com a écrit : Je ne comprends toujours pas le lien entre ce qui est dans le fichier ANFR et un possible inventaire des antennes dans OSM. Le fichier ANFR décris au mieux une station d'émission pouvant comprendre plusieurs antennes. Le support de l'ANFR n'est pas l'antenne. La plupart des supports sont occupés par une multitude d'antennes. Du coup, si on pouvait avoir quelques explications supplémentaires sur le raisonnement, elles sont les bienvenues. Tu n'as pas du regarder entièrement ce qu'a libérer l’anfr. Il y a 5 fichier texte qui liste chaque'un quelque chose de différent : les *Supports *(pylône, mat, immeuble ...) accueillant des antennes avec position, hauteur, propriétaire, ça c'est sur ça doit être intégrer dans osm. ensuite les *Stations *(il peut il y en avoir plusieurs par support) avec l’opérateur (orange,sncf,tdf...) et des dates (implantation,mise en service et modification). Puis les *Antennes* (il peut il y en avoir plusieurs par station) avec son type (panneau, antenne parabolique...) et des info sur cette antenne (dimension, azimute...). Puis les *émetteurs *(il peut il y en avoir plusieurs par antenne) avec le système (GSM 900, FM,). Et enfin les *Bandes *(il peut il y en avoir plusieurs par émetteur) avec le début et la fin d'une bande de fréquence. On peut passer d'un fichier a l'autre avec differents id. Voilà ce que fournit donc l'anfr. Bien sur, RIEN N'OBLIGE DE TOUT INTÉGRÉ DANS OSM. Pour les supports, je pense qu'il faut utiliser les tag déjà en circulation les différents man_made (mast , tower, communications_tower) et ne rien mettre pour immeuble,batiment... qui sont déjà présent en surfacique. plus height= et owner=. jusque là on n'est pas sur des choses nouvelles (peut être reparler de mast , tower, communications_tower, moi je comprends pas les différences). Pour le reste, déjà il peut bien il y avoir 30 antennes sur un pylône, dans osm les antennes et le pylône c'est un node donc il faut mettre les tags sur ce node. il faut choisir le niveau de detail que l'on veut et que l'on peut mettre dans osm et le niveau de complexité. operator= reseau =FM. FH; UMTS 900; LTE 260... ou faire comme proposer là : http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dmast communication:mobile_phone=yes; LTE 260;... communication:radio=yes communication:television=yes communication:microwave=yes Le tag antenna = yes peut permettre aussi d'indiquer le type d'antenne : antenna = multi lorsque'il y a différentes antennes antenna = panneau ou antenne parabolique ... quand il n'y a qu'une antenne ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Normalisation du tag antenne
Désolé de l'erreur de fenêtre Je t'invite à écrire une propal là desus en attendant je propose la combinaison pie/point virgule. Vu qu'il s'agitde listes associées simple c'est nickel, mais ta propal est extremement intéressant surtout que les bases tournent très bien avec de l'orienté document. Tu auras mon vote :) Le Vendredi 1 mai 2015 11h06, Philippe Verdy verd...@wanadoo.fr a écrit : Le 1 mai 2015 10:20, dHuy Pierre dh...@yahoo.fr a écrit : @Verdi: Hum je pense que tu pousses un peu loin le format initial de Jérome me paraissait bien Jérome avait plutôt été séduit par ma première proposition, cependant je parlais du problème plus général des infos structurées pour lesquelles on n'a pas de schéma clair permettant de les représenter de façon compacte mais lisible et parsable avec un système unique et non ambigu, et sans forcément multiplier le nombre de tags quand ce n'est pas toujours nécessaire (car des infos optionelles qui complètent un tag de base). Dans un proemier tmeps j'avais évoqué JSON (aussi XML mais trop verbeux), alors qu'on a moyen de faire un format JSON light reprenant les conventions habituelles d'OSM où tout est codé avec des valeurs atomiques de type chaine, et où on a des séparateurs point-virgule et pipe mais pas très lisibles quand on les combine et pas non plus suffisant au delaà des listes simples ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Normalisation du tag antenne
Le 29/04/2015 20:02, Jérôme Amagat a écrit : J'ai pris un exemple dans les données pressentes sur data.gouv.fr http://data.gouv.fr de lanfr voila ou se trouve le pylone : https://www.openstreetmap.org/node/3487062694 toutes les donnée sur cette station sont là : https://docs.google.com/spreadsheets/d/1Q2I5QfX0imcOyFI2BQlBSA8Y3rM3eVUY9w3EI1gFYXA/edit?usp=sharing c'est un pylône autostable appartenant à TDF, dessus il y a 8 supports exploités par différentes personnes ( 3*TDF, SNCF, FREE, Bouygues,...) et sur ces supports il y a des antennes, 29 ! en tout sur ce pylône (16 pour bouygues, 3 pour free, 2 sncf, 4 TDF, ...) et certaines antennes peuvent émettre sur plusieurs fréquences (par exemple pour une antenne free : UMTS 2100, LTE 2600 et UMTS 900 avec à chaque fois 2 bandes de fréquence). Maintenant comment intégré ça (ou au moins une parti) dans osm? tout ça est sur un pylône (d’après la vue aérienne) donc normalement 1 point dans osm, a moins d’empiler les nœuds les uns sur les autres. Des données métier aussi précises ont elles un réel intérêt dans OSM alors qu'elles sont librement accessible ? Je verrai bien un résumé dans OSM qui indique: - le pylone, - l'usage (GSM, 2/3/4G, autre) - les opérateurs... - l'ID ANFR pour aller chercher le reste des infos dans une base plus détaillée et qui sera sûrement mieux mises à jour qu'OSM ! -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Normalisation du tag antenne
Salut Pour répondre à Pierre, effectivement il ya les données de hauteur des antennes par rapport au sol...Le champ m'avait échappé... Sinon, je suis comme Jérome, je ne vois pas comment on pourrait mettre un point par antenne dans OSM. Je pense que mettre un résumé par support comme le suggère Christian suffit largement. L'ID ANFR à utiliser serait l'ID du support que l'on trouve dans le fichier support.txt (SUP_ID) et qui permet ensuite de retrouver les infos complémentaires sur le site cartoradio si besoin. Je pense que dans OSM, faut mettre que les infos utiles et stables. Si j'ai besoin des données complètes, je vais chercher directement dans les données ANFR et pas dans OSM ! Eric 2015-04-30 19:16 GMT+02:00 Christian Quest cqu...@openstreetmap.fr: Le 30/04/2015 19:08, Jérôme Amagat a écrit : Dans un precedant mail tu ecris : Je verrai bien un résumé dans OSM qui indique: - le pylone, - l'usage (GSM, 2/3/4G, autre) - les opérateurs... - l'ID ANFR pour aller chercher le reste des infos dans une base plus détaillée et qui sera sûrement mieux mises à jour qu'OSM ! Le problème c'est que chaque opérateur fait un usage qui peut être bien différent des autres. Dans l'exemple même free et bouygues ne font pas la même chose (le GSM). ce que je proposais c'est de lier opérateur et usage. je sais bien que l'on utilise les ; mais c'est pas toujours le cas : http://wiki.openstreetmap.org/wiki/Lanes operator =RESEAU PRIVE*|* TDF *|* SNCF Réseau *|* FREE MOBILE *|* IFW *|* BOUYGUES TELECOM reseau =PMR *|* FM;FH *|* GSM R *|* UMTS 900;UMTS 2100;LTE 2600 *|* BLR 3 GHZ *|* FH;LTE 800;LTE 1800;LTE 2600;GSM 900;GSM 1800;UMTS 2100 Justement, je voyais un résumé plus... résumé ;) La liste des opérateurs, ça me semble pertinent. Ensuite le détail par opérateur du type d'usage, ça me semble déjà aller trop loin. Savoir qu'un pylône sert pour du GSM quel que soit l'opérateur est un niveau de détail à peu près gérable dans OSM (j'entends par là maintenable, parce que pour le côté vérifiable faut être affuté). Après pour plus, il y a les données détaillées. Ça ne vous semble pas suffisant ? -- Christian Quest - OpenStreetMap France ___ 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
Re: [OSM-talk-fr] Normalisation du tag antenne
Le 30/04/2015 18:07, Jérôme Amagat a écrit : man_made=antenna est-ce que man_made est une bonne solution? beaucoup des antenne sont sur une tour, un pylône qui lui devrai être tagger en man_made. pourquoi pas seulement ajouté antenna=yes sur le support? supprimé complètement man_made=antenna ne serai t elle pas une meilleur solution pour éviter des confusions? l'id anfr : il faut voir de quoi on parle. dans le fichier libéré, des id il y en a plusieurs : un pour chaque support, station, antenne, émetteur et bande. et le numéro d'identification de l’installation sur Cartoradio. Une autre question : moi je pars du principe que l'on ne peut pas, pour un pylône, placer plusieurs points dans osm. j'ai raison? je repart sur l'exemple que j'ai donner plus haut : je verais bien ça : man_made=tower (ou autre) antenna=yes ref:cartoradio=... operator=RESEAU PRIVE|TDF|SNCF Réseau|FREE MOBILE|IFW|BOUYGUES TELECOM reseau =PMR|FM;FH|GSM R|UMTS 900;UMTS 2100;LTE 2600|BLR 3 GHZ|FH;LTE 800;LTE 1800;LTE 2600;GSM 900;GSM 1800;UMTS 2100| La convention sur OSM est de séparer par des ; Donc plutôt: operator=RESEAU PRIVE;TDF;SNCF Réseau;FREE MOBILE;IFW;BOUYGUES TELECOM utiliser des | comme pour les lanes sur les routes permet de donner des infos sur chaque operator. je ne vois pas comment on pourrait en mettre plus sans rendre le truc incompréhensible. Franchement, je ne vois pas l'intérêt de recopier toutes ces données librement disponibles dans OSM. Inutilement complexe, les mises à jour manuelles ne seront sûrement jamais faites... mieux vaut se référer à la source et donc correctement pointer vers elle. Les ré-utilisateurs potentiels préféreront sûrement reprendre directement les données de l'ANFR. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Normalisation du tag antenne
Alors le type de réseau, l'id anfr (ou autres), le type d'antenne (ça peut être carrément utile pour le repérage) et les opérateurs. Le tout placé via le tag antenna=yes.Comment gérer une antenne isolée sur un batiment? Le Jeudi 30 avril 2015 19h55, Eric Debeau eric.deb...@gmail.com a écrit : Salut Pour répondre à Pierre, effectivement il ya les données de hauteur des antennes par rapport au sol...Le champ m'avait échappé... Sinon, je suis comme Jérome, je ne vois pas comment on pourrait mettre un point par antenne dans OSM. Je pense que mettre un résumé par support comme le suggère Christian suffit largement. L'ID ANFR à utiliser serait l'ID du support que l'on trouve dans le fichier support.txt (SUP_ID) et qui permet ensuite de retrouver les infos complémentaires sur le site cartoradio si besoin. Je pense que dans OSM, faut mettre que les infos utiles et stables. Si j'ai besoin des données complètes, je vais chercher directement dans les données ANFR et pas dans OSM ! Eric 2015-04-30 19:16 GMT+02:00 Christian Quest cqu...@openstreetmap.fr: Le 30/04/2015 19:08, Jérôme Amagat a écrit : Dans un precedant mail tu ecris : Je verrai bien un résumé dans OSM qui indique: - le pylone, - l'usage (GSM, 2/3/4G, autre) - les opérateurs... - l'ID ANFR pour aller chercher le reste des infos dans une base plus détaillée et qui sera sûrement mieux mises à jour qu'OSM ! Le problème c'est que chaque opérateur fait un usage qui peut être bien différent des autres. Dans l'exemple même free et bouygues ne font pas la même chose (le GSM). ce que je proposais c'est de lier opérateur et usage. je sais bien que l'on utilise les ; mais c'est pas toujours le cas : http://wiki.openstreetmap.org/wiki/Lanes operator =RESEAU PRIVE| TDF | SNCF Réseau | FREE MOBILE | IFW | BOUYGUES TELECOM reseau =PMR | FM;FH | GSM R | UMTS 900;UMTS 2100;LTE 2600 | BLR 3 GHZ | FH;LTE 800;LTE 1800;LTE 2600;GSM 900;GSM 1800;UMTS 2100 Justement, je voyais un résumé plus... résumé ;) La liste des opérateurs, ça me semble pertinent. Ensuite le détail par opérateur du type d'usage, ça me semble déjà aller trop loin. Savoir qu'un pylône sert pour du GSM quel que soit l'opérateur est un niveau de détail à peu près gérable dans OSM (j'entends par là maintenable, parce que pour le côté vérifiable faut être affuté). Après pour plus, il y a les données détaillées. Ça ne vous semble pas suffisant ? -- Christian Quest - OpenStreetMap France ___ 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Normalisation du tag antenne
@Verdy: Heureux de te voir enfin, j'étais presqu'étoné de ne pas te lire. Cette propal de nomenclature est vraiment bonne. Merci Jérôme pour le coup, je ne vois pas comment mieux lier (quelqu'un avait proposé antenna:1...n mais il est clair que ce tag était invivable. @Liostier: Forme et emplacement d'antenne on est d'accord sauf qu'à voir la liste des type j'aurais besoin d'un coup de main si on veut proposer une vraie liste, tu peux faire ça le pad?Autrement je continue de considérer qu'il faut distinguer les antennes en fonction de leur émission. La cartographie ne passe pas que par le visuel et la connaissance de certains réseau peut être exploitable pour un usage civil (cf use case sur le pad et dans la ML). J'ai officiellement barré les bandes de fréquences, et les directions. On en reste du coup au draft initial de opérateurs, type de réseau, et type d'antenne (plus tag optionnel avec hidden, height, antenna:dimension et ele) Le Vendredi 1 mai 2015 0h18, Philippe Verdy verd...@wanadoo.fr a écrit : Le 30 avr. 2015 18:42, Christian Quest cqu...@openstreetmap.fr a écrit : Le 30/04/2015 18:07, Jérôme Amagat a écrit : operator=RESEAU PRIVE|TDF|SNCF Réseau|FREE MOBILE|IFW|BOUYGUES TELECOM reseau =PMR|FM;FH|GSM R|UMTS 900;UMTS 2100;LTE 2600|BLR 3 GHZ|FH;LTE 800;LTE 1800;LTE 2600;GSM 900;GSM 1800;UMTS 2100| La convention sur OSM est de séparer par des ;Oui mais uniquement pour des listes non ordonnées. Là Jérôme voulait lier l'ordre des deux listes.Les traits verticaux sont utilisés dans ce cas pour les listes ordonnées de lanes.Seulement je trouve ça très peu lisible. Il serait plus pertinent de grouper les données propre à chaque opérateur au nom de cet opérateur et en séparant alors les opérateurs sur des gags distincts.Cela donnerait un truc du genre:operator:1=TDF|FM;FH operator:2=Opérateur privé|PMR operator:3=SNCF|GSM R operator:4=FREE MOBILE|UMTS 900;UMTS 2100;LTE 2600 etc.Les séparateurs n'ont pas le même rôle et un pipe indique l'ordre des champs (nom d'operateur, types de reseau) lesquels peuvent encore inclure en valeur des listes non ordonnées séparées par points-virgules...Les indices numériques donnés à chaque opérateur sont ordonnés mais en fait arbitrairement.Dès que ça se complique de toute façon on se retrouve avec plusieurs tags. Sinon il faudrait admetttre des valeurs dans un type structuré comme JSON, voire XML en plus verbeux encore... ___ 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
Re: [OSM-talk-fr] Normalisation du tag antenne
Note: je n'ai rien précisé concernant la façon de créer un échappement pour
les crochets, accolades, guillemets, apostrophes, et les pipe, virgules ou
point-virgules : il faudrait juste réserve le backslash ou d'un caractère
conventionel non réservé :
- \\ pour le backslash \ lui même
- \| pour le pipe |
- \= pour le signe égal =
- \[ et \] pour les crochets [ et ]
- \{ et \} pour les accolades { et }
- \s (semicolon) pour le point-virgule ; et non pas \; afin de ne pas
entrer en conflit avec les point-virgules séparateurs par défaut des listes
non ordonnées d'OSM)
Et pour le cas où des chaines déjà entre guillemets ou entre
'apostrophes' sont utilisées:
- \q (quote) pour les guillemets doubles ASCII
- \a (apos) pour les guillemets doubles ASCII '
Rien de prévu pour les échappements Unicode (ceux qui y tiennent pourront
ajouter \xNN ou \u ou \UNN), le but étant de coder directement les
caractères du texte si possible et d'utiliser sinon les échappements plus
compacts à deux caractères...
Avec ça on a tout pour imiter JSON, mais en plus compact et sans distinguer
les types numériques et chaines (il n'y a qu'un seul type d'atome : les
chaînes).
Les schémas qui voudraient distinguer les types d'atomes devraient coder ça
dans les atomes-chaines par une convention comme type:valeur (un peut
comme le fait PHP pour sérialiser ses données), par exemple i:10 pour
indiquer l'entier 10 (nombre de bits non limité), n:10 pour le nombre
flottant 10 (précision non limitée), s:10 pour indiquer la chaîne 10,
n: pour indiquer une valeur nil, d:date pour une date dans un format
compatible ISO8601 (avec séparateurs de champs de date optionnels pour que
ce soit encore plus compact)...
Le 1 mai 2015 01:17, Philippe Verdy verd...@wanadoo.fr a écrit :
Le 1 mai 2015 00:35, dHuy Pierre dh...@yahoo.fr a écrit :
@Verdy: Heureux de te voir enfin, j'étais presqu'étoné de ne pas te lire.
Cette propal de nomenclature est vraiment bonne.
Note: je n'ai pas voulu taper gags mais tags (mais sur le coup le
smartphone que j'ai utilisé temporairement, le temps d'une indisponibilité
du système sur PC, n'en a fait qu'à sa tête malgré plusieurs corrections
successives de ce mot, il a encore été remplacé contre ma volonté lors de
l'envoi...)
Personnellement je n'ai jamais aimé le fait de mêler deux types de
séparateurs dans les tags lanes, c'est très peu lisible et trompeur. Et
j'aurais préféré un codage de type JSON (mais encore un peu plus compact),
sans aucun point-virgule (sauf si la structure principale est celle d'une
liste non ordonnée: aucun point-virgule dans les éléments)
Bref si on veut tout mettre dans un seul tag, permettre alors l'usage des
accolades, et dans ce cas dans les accolades permettre d'utilier
guillements et apostrophes ASCII pour encadrer des chaines (mais ne
contenant aucun point-virgule qui devraient utiliser un échappement)
Les valeurs structurées et sous-structures ne seraient que des listes non
ordonnées (entre accolades, séparées par des pipes ou virgules), ou
ordonnées/indexés (entre crochets, séparées aussi par des pipes, avec un
éventuel signe égal pour nommer/indexer le champ), et contrairement à JSON,
les guillemets seraient presque toujours évitables, et il n'y aurait qu'un
seul type d'atome: les chaines, et pas de nombres en tant que tels
Les séparateurs seraient également évitables s'il y a des crochets ou
accolades avant ou après, pour que ce soit encore plus compact. Pour cet
exemple cela donnerait:
operator={[TDF{FM|FH}][Opérateur privé{PMR}][SNCF{GSM R}][FREE
MOBILE{UMTS 900|UMTS 2100|LTE 2600}]}
Mais puisqu'ici la structure externe est une liste non ordonnée, on peut
aussi éviter les accolades externes et alors utiliser les points-virgules
habituels d'OSM, et supprimer aussi les crochets encadrant chaque élément
de la liste non ordonnée quant ils sont eux-même des listes ordonnées:
operator=TDF{FM|FH};Opérateur privé{PMR};SNCF{GSM R};FREE MOBILE{UMTS 900|UMTS
2100|LTE 2600}
Et voilà alors notre format JSON-like, ultra compact, adapté pour OSM,
mais toujours très lisible !
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Normalisation du tag antenne
On 01/05/2015 00:35, dHuy Pierre wrote: @Liotier: Forme et emplacement d'antenne on est d'accord sauf qu'à voir la liste des type j'aurais besoin d'un coup de main si on veut proposer une vraie liste, tu peux faire ça le pad? De retour au bureau lundi je devrais avoir moyen de mettre la main sur une typologie d'antennes pour un réseau mobile (en espérant que ce soient des types génériques et non des modèles de constructeurs) - et je devrais pouvoir contribuer quelques types supplémentaires. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Normalisation du tag antenne
Le 30 avr. 2015 18:42, Christian Quest cqu...@openstreetmap.fr a écrit : Le 30/04/2015 18:07, Jérôme Amagat a écrit : operator=RESEAU PRIVE|TDF|SNCF Réseau|FREE MOBILE|IFW|BOUYGUES TELECOM reseau =PMR|FM;FH|GSM R|UMTS 900;UMTS 2100;LTE 2600|BLR 3 GHZ|FH;LTE 800;LTE 1800;LTE 2600;GSM 900;GSM 1800;UMTS 2100| La convention sur OSM est de séparer par des ; Oui mais uniquement pour des listes non ordonnées. Là Jérôme voulait lier l'ordre des deux listes. Les traits verticaux sont utilisés dans ce cas pour les listes ordonnées de lanes. Seulement je trouve ça très peu lisible. Il serait plus pertinent de grouper les données propre à chaque opérateur au nom de cet opérateur et en séparant alors les opérateurs sur des gags distincts. Cela donnerait un truc du genre: operator:1=TDF|FM;FH operator:2=Opérateur privé|PMR operator:3=SNCF|GSM R operator:4=FREE MOBILE|UMTS 900;UMTS 2100;LTE 2600 etc. Les séparateurs n'ont pas le même rôle et un pipe indique l'ordre des champs (nom d'operateur, types de reseau) lesquels peuvent encore inclure en valeur des listes non ordonnées séparées par points-virgules... Les indices numériques donnés à chaque opérateur sont ordonnés mais en fait arbitrairement. Dès que ça se complique de toute façon on se retrouve avec plusieurs tags. Sinon il faudrait admetttre des valeurs dans un type structuré comme JSON, voire XML en plus verbeux encore... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Normalisation du tag antenne
Le 1 mai 2015 00:35, dHuy Pierre dh...@yahoo.fr a écrit :
@Verdy: Heureux de te voir enfin, j'étais presqu'étoné de ne pas te lire.
Cette propal de nomenclature est vraiment bonne.
Note: je n'ai pas voulu taper gags mais tags (mais sur le coup le
smartphone que j'ai utilisé temporairement, le temps d'une indisponibilité
du système sur PC, n'en a fait qu'à sa tête malgré plusieurs corrections
successives de ce mot, il a encore été remplacé contre ma volonté lors de
l'envoi...)
Personnellement je n'ai jamais aimé le fait de mêler deux types de
séparateurs dans les tags lanes, c'est très peu lisible et trompeur. Et
j'aurais préféré un codage de type JSON (mais encore un peu plus compact),
sans aucun point-virgule (sauf si la structure principale est celle d'une
liste non ordonnée: aucun point-virgule dans les éléments)
Bref si on veut tout mettre dans un seul tag, permettre alors l'usage des
accolades, et dans ce cas dans les accolades permettre d'utilier
guillements et apostrophes ASCII pour encadrer des chaines (mais ne
contenant aucun point-virgule qui devraient utiliser un échappement)
Les valeurs structurées et sous-structures ne seraient que des listes non
ordonnées (entre accolades, séparées par des pipes ou virgules), ou
ordonnées/indexés (entre crochets, séparées aussi par des pipes, avec un
éventuel signe égal pour nommer/indexer le champ), et contrairement à JSON,
les guillemets seraient presque toujours évitables, et il n'y aurait qu'un
seul type d'atome: les chaines, et pas de nombres en tant que tels
Les séparateurs seraient également évitables s'il y a des crochets ou
accolades avant ou après, pour que ce soit encore plus compact. Pour cet
exemple cela donnerait:
operator={[TDF{FM|FH}][Opérateur privé{PMR}][SNCF{GSM R}][FREE MOBILE{UMTS
900|UMTS 2100|LTE 2600}]}
Mais puisqu'ici la structure externe est une liste non ordonnée, on peut
aussi éviter les accolades externes et alors utiliser les points-virgules
habituels d'OSM, et supprimer aussi les crochets encadrant chaque élément
de la liste non ordonnée quant ils sont eux-même des listes ordonnées:
operator=TDF{FM|FH};Opérateur privé{PMR};SNCF{GSM R};FREE MOBILE{UMTS 900|UMTS
2100|LTE 2600}
Et voilà alors notre format JSON-like, ultra compact, adapté pour OSM, mais
toujours très lisible !
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Normalisation du tag antenne
Bonjour à tous, 2015-04-30 17:02 GMT+02:00 François Lacombe fl.infosrese...@gmail.com: Il faut vraiment clarifier l'utilisation d'antenne et de site. Installer une antenne qui couvre à 360°, réputée omnidirectionelle, et 3 antennes couvrant à 120° chacune pour se retrouver au global avec les 360° couverts n'est pas la même chose : en 1er il n'y a qu'une cellule, en 2nd il y en a 3. La deuxième solution écoule 3 fois plus de trafic que la 1ere. Tout en sachant qu'il est compliqué de savoir si un site couvre ou pas 360° car on ne connait pas les modèles d'antennes. Un site à 2 secteurs peut couvrir 2x90° (type TGV) ou 2x180° par exemple selon ce qui est utilisé. Nous ne devrions pas considérer les antennes du tout dans nos échanges, juste les sites. Donc bannir man_made=antenna. Free peut en effet installer une majorité de sites couvrant à 360°, ils vont par contre y parvenir en utilisant plusieurs secteurs/antennes de 120° pour des questions de capacité de trafic à écouler. Est-ce que se mettre au niveau des supports ANFR ne serait pas le plus simple, en indiquant le propriétaire et les exploitants ? (éventuellement les technos utilisées, à condition de mettre ça à jour régulièrement) Les données de cartoradio ne doivent pas nous permettre de placer les antennes mais uniquement le site radio. Cf un site avec des antennes réparties aux coins d'un batiment de grande envergure alors que la zone technique avec les équipements est au centre : ANFR #368376 C'est le soucis oui, la base n'est pas assez précise pour les sites avec antennes déportées. Sinon, le soucis d'utiliser les numéros d'identification ANFR, il ne me semble pas qu'il existe un moyen d'y aller facilement sur Cartoradio ensuite pour avoir des informations. Par contre, il est - aujourd'hui - possible de construire une URL pointant vers cartoradio avec le site au milieu. Mais difficile de savoir si cela sera encore valable dans 2 ans. Nicolas ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Normalisation du tag antenne
man_made=antenna est-ce que man_made est une bonne solution? beaucoup des antenne sont sur une tour, un pylône qui lui devrai être tagger en man_made. pourquoi pas seulement ajouté antenna=yes sur le support? supprimé complètement man_made=antenna ne serai t elle pas une meilleur solution pour éviter des confusions? l'id anfr : il faut voir de quoi on parle. dans le fichier libéré, des id il y en a plusieurs : un pour chaque support, station, antenne, émetteur et bande. et le numéro d'identification de l’installation sur Cartoradio. Une autre question : moi je pars du principe que l'on ne peut pas, pour un pylône, placer plusieurs points dans osm. j'ai raison? je repart sur l'exemple que j'ai donner plus haut : je verais bien ça : man_made=tower (ou autre) antenna=yes ref:cartoradio=... operator=RESEAU PRIVE|TDF|SNCF Réseau|FREE MOBILE|IFW|BOUYGUES TELECOM reseau =PMR|FM;FH|GSM R|UMTS 900;UMTS 2100;LTE 2600|BLR 3 GHZ|FH;LTE 800;LTE 1800;LTE 2600;GSM 900;GSM 1800;UMTS 2100| utiliser des | comme pour les lanes sur les routes permet de donner des infos sur chaque operator. je ne vois pas comment on pourrait en mettre plus sans rendre le truc incompréhensible. ou alors un truc du genre : operator:1=... reseau :1=... antenne:1=... frequence:1=... operator:2=... reseau :2=... antenne:2=... frequence:2=... ... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Normalisation du tag antenne
@Amagat, c'est pour le cas où une antenne serait sur un toit ou ailleurs, sans support node en dessous. Pour le reste (réussir à placer des infos sur un point), je vous laisse débattre, j'ai essayé de trouver le plus optimisé. Sinon le id station me parait pas mal comme id.@Lacombe jamais parlé d'antenne à 360, j'ai parlé d'une simplification. Le Jeudi 30 avril 2015 18h08, Jérôme Amagat jerome.ama...@gmail.com a écrit : man_made=antennaest-ce que man_made est une bonne solution? beaucoup des antenne sont sur une tour, un pylône qui lui devrai être tagger en man_made.pourquoi pas seulement ajouté antenna=yes sur le support? supprimé complètement man_made=antenna ne serai t elle pas une meilleur solution pour éviter des confusions? l'id anfr : il faut voir de quoi on parle. dans le fichier libéré, des id il y en a plusieurs : un pour chaque support, station, antenne, émetteur et bande. et le numéro d'identification de l’installation sur Cartoradio. Une autre question : moi je pars du principe que l'on ne peut pas, pour un pylône, placer plusieurs points dans osm. j'ai raison? je repart sur l'exemple que j'ai donner plus haut :je verais bien ça :man_made=tower (ou autre)antenna=yesref:cartoradio=...operator=RESEAU PRIVE|TDF|SNCF Réseau|FREE MOBILE|IFW|BOUYGUES TELECOMreseau =PMR|FM;FH|GSM R|UMTS 900;UMTS 2100;LTE 2600|BLR 3 GHZ|FH;LTE 800;LTE 1800;LTE 2600;GSM 900;GSM 1800;UMTS 2100| utiliser des | comme pour les lanes sur les routes permet de donner des infos sur chaque operator.je ne vois pas comment on pourrait en mettre plus sans rendre le truc incompréhensible. ou alors un truc du genre :operator:1=...reseau :1=...antenne:1=...frequence:1=...operator:2=...reseau :2=...antenne:2=...frequence:2=.. ___ 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
Re: [OSM-talk-fr] Normalisation du tag antenne
C'est là que des tags comme height interviennent à mon sens, la hauteur et l'élévation de l'antenne permette de déterminer sa visibilité directement Le Mercredi 29 avril 2015 14h53, Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net a écrit : Le mercredi 29 avril 2015 12:07:29 dHuy Pierre a écrit : En me basant sur la discussion initiée ici précédemment et des discussions avec des opérateurs, je reviens avec une proposition pour l'utilisation d'un tag unifié pour les antennes. https://pad.partipirate.org/plobm2h0ZV Ceci n'est qu'un draft encore, mais nécessaire pour l'intégration de cartoradio correctement. Il sera nécessaire de le traduire en anglais, ne faisant guère confiance au mien, je souhaiterai savoir s'il y aurait un volontaire? Verdy? Mister Lacombe et Chateau-Thierry avaient été réactifs sur le sujet la dernière fois, j'attends donc votre point de vue sur ce que j'ai pu en tirer. Librement, Intéressant. Tu dis que les antennes peuvent être des repères visuels, et je suis d'accord. Ceci dit, certaines antennes ne le sont pas, et ce serait donc intéressant de le renseigner pour ne pas s'attendre à ce repère visuel. Je pense notamment à une antenne cachée dans un clocher d'Église par chez moi. Son existence est intéressante dans OSM, mais un attribut additionnel genre visibility=hidden ou hidden=yes serait un plus. Après, comment différencier ces antennes cachés sur une carte c'est une autre question … -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ 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
Re: [OSM-talk-fr] Normalisation du tag antenne
C'est un pad au passage, n'hésitez pas à commenter (entre crochet) ou à corriger les fautes/inexactitudes. Le Mercredi 29 avril 2015 14h54, Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net a écrit : Le mercredi 29 avril 2015 12:07:29 dHuy Pierre a écrit : En me basant sur la discussion initiée ici précédemment et des discussions avec des opérateurs, je reviens avec une proposition pour l'utilisation d'un tag unifié pour les antennes. https://pad.partipirate.org/plobm2h0ZV Ceci n'est qu'un draft encore, mais nécessaire pour l'intégration de cartoradio correctement. Il sera nécessaire de le traduire en anglais, ne faisant guère confiance au mien, je souhaiterai savoir s'il y aurait un volontaire? Verdy? Mister Lacombe et Chateau-Thierry avaient été réactifs sur le sujet la dernière fois, j'attends donc votre point de vue sur ce que j'ai pu en tirer. Librement, Intéressant. Tu dis que les antennes peuvent être des repères visuels, et je suis d'accord. Ceci dit, certaines antennes ne le sont pas, et ce serait donc intéressant de le renseigner pour ne pas s'attendre à ce repère visuel. Je pense notamment à une antenne cachée dans un clocher d'Église par chez moi. Son existence est intéressante dans OSM, mais un attribut additionnel genre visibility=hidden ou hidden=yes serait un plus. Après, comment différencier ces antennes cachés sur une carte c'est une autre question … -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ 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
Re: [OSM-talk-fr] Normalisation du tag antenne
Belle initiative, merci Pierre. Pourquoi ne pas avoir utilisé le wiki pour diffuser plus largement le document ? Et suivre ainsi un formalisme établi. Cela permettrait aussi d'ajouter des exemples, pour être sur que l'on parle de la même chose. Cartographier les antennes au sens strict du terme peut être hardu. Ici : http://www.gizmodo.fr/wp-content/uploads/2010/08/gsm-antenne.jpg Il faudrait indiquer qu'il y a deux antennes et non qu'une, avec possiblement deux jeux de paramètres (puissance, numéro de cellule, LAC, BCCH, PCPICH et j'en passe) et aussi deux directions différentes. Les antennes peuvent être déportées, couplées, intégrées les unes dans les autres etc... Pour OSM on devrait se limiter au site radio et le considérer comme atomique (je rejoint les propos de Marc). Merci d'apporter quelques précisions sur tout ca. A+ *François Lacombe* fl dot infosreseaux At gmail dot com www.infos-reseaux.com @InfosReseaux http://www.twitter.com/InfosReseaux Le 29 avril 2015 15:35, THEVENON Julien julien_theve...@yahoo.fr a écrit : * De :* dHuy Pierre dh...@yahoo.fr * *C'est là que des tags comme height interviennent à mon sens, la hauteur et l'élévation de l'antenne permette de déterminer sa visibilité directement pas forcement, de plus en plus d antennes GSM sont camouflees donc le tag indiquant si elles sont visibles/cachees ou non a un sens http://www.animatif.com/panoramas/gsm/antenne-relais-camouflage.html http://www.google.fr/url?sa=trct=jq=esrc=ssource=webcd=3ved=0CDEQFjACurl=http%3A%2F%2Fwww.kathrein.fr%2Fmedia%2Fdocuments%2Fcellulaire%2Ffran%25C3%25A7ais%2Fsolutions%2520d%2527integration.pdfei=S91AVbvyFoLsat3agcADusg=AFQjCNGRbcj_yoVS0lEqo3MggQZe7nuAQQbvm=bv.91665533,d.d2scad=rja Julien http://www.google.fr/url?sa=trct=jq=esrc=ssource=webcd=3ved=0CDEQFjACurl=http%3A%2F%2Fwww.kathrein.fr%2Fmedia%2Fdocuments%2Fcellulaire%2Ffran%25C3%25A7ais%2Fsolutions%2520d%2527integration.pdfei=S91AVbvyFoLsat3agcADusg=AFQjCNGRbcj_yoVS0lEqo3MggQZe7nuAQQbvm=bv.91665533,d.d2scad=rja ___ 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
Re: [OSM-talk-fr] Normalisation du tag antenne
J'ai pris un exemple dans les données pressentes sur data.gouv.fr de lanfr voila ou se trouve le pylone : https://www.openstreetmap.org/node/3487062694 toutes les donnée sur cette station sont là : https://docs.google.com/spreadsheets/d/1Q2I5QfX0imcOyFI2BQlBSA8Y3rM3eVUY9w3EI1gFYXA/edit?usp=sharing c'est un pylône autostable appartenant à TDF, dessus il y a 8 supports exploités par différentes personnes ( 3*TDF, SNCF, FREE, Bouygues,...) et sur ces supports il y a des antennes, 29 ! en tout sur ce pylône (16 pour bouygues, 3 pour free, 2 sncf, 4 TDF, ...) et certaines antennes peuvent émettre sur plusieurs fréquences (par exemple pour une antenne free : UMTS 2100, LTE 2600 et UMTS 900 avec à chaque fois 2 bandes de fréquence). Maintenant comment intégré ça (ou au moins une parti) dans osm? tout ça est sur un pylône (d’après la vue aérienne) donc normalement 1 point dans osm, a moins d’empiler les nœuds les uns sur les autres. Le 29 avril 2015 15:35, THEVENON Julien julien_theve...@yahoo.fr a écrit : * De :* dHuy Pierre dh...@yahoo.fr * *C'est là que des tags comme height interviennent à mon sens, la hauteur et l'élévation de l'antenne permette de déterminer sa visibilité directement pas forcement, de plus en plus d antennes GSM sont camouflees donc le tag indiquant si elles sont visibles/cachees ou non a un sens http://www.animatif.com/panoramas/gsm/antenne-relais-camouflage.html http://www.google.fr/url?sa=trct=jq=esrc=ssource=webcd=3ved=0CDEQFjACurl=http%3A%2F%2Fwww.kathrein.fr%2Fmedia%2Fdocuments%2Fcellulaire%2Ffran%25C3%25A7ais%2Fsolutions%2520d%2527integration.pdfei=S91AVbvyFoLsat3agcADusg=AFQjCNGRbcj_yoVS0lEqo3MggQZe7nuAQQbvm=bv.91665533,d.d2scad=rja Julien http://www.google.fr/url?sa=trct=jq=esrc=ssource=webcd=3ved=0CDEQFjACurl=http%3A%2F%2Fwww.kathrein.fr%2Fmedia%2Fdocuments%2Fcellulaire%2Ffran%25C3%25A7ais%2Fsolutions%2520d%2527integration.pdfei=S91AVbvyFoLsat3agcADusg=AFQjCNGRbcj_yoVS0lEqo3MggQZe7nuAQQbvm=bv.91665533,d.d2scad=rja ___ 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
Re: [OSM-talk-fr] Normalisation du tag antenne
Bonsoir Les données de l'ANFR publiées sur data gouv ne sont pas aussi précises que celles disponibles sur le site ANFR. Par exemple, on n'a pas la hauteur du positionnement des antennes dans le fichier data gouv alors que l'on a ces infos sur le site ANFR. Sinon, je ne sais pas si ca fait sens de renseigner toutes les infos dans OSM parce que comme le précise Jérome il y a des cas complexes avec de nombreux opérateurs utilisant chacun plusieurs antennes. Je pense que l'on devrait au minimum indiquer les sites, mais il faut ensuite respecter les règles actuelles et l'intégration dans OSM devrait respecter les règles actuelles : http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dmast Dans les données ANFR, les différents sites possèdent des infos sur le support : 0;Sans nature 40;Sémaphore 41;Phare 4;Château d'eau - réservoir 38;Immeuble 39;Local technique 42;Mât 8;Intérieur galerie 9;Intérieur sous-terrain 10;Tunnel 11;Mât béton 12;Mât métallique 21;Pylône 17;Bâtiment 19;Monument historique 20;Monument religieux 22;Pylône autoportant 23;Pylône autostable 24;Pylône haubané 25;Pylône treillis 26;Pylône tubulaire 31;Silo 32;Ouvrage d'art (pont, viaduc) 33;Tour hertzienne 34;Dalle en béton 9;Support non décrit 43;Fût 44;Tour de contrôle 45;Contre-poids au sol 46;Contre-poids sur shelter 47;Support DEFENSE 48;pylône arbre 49;Ouvrage de signalisation (portique routier, panneau routier, panneau publicitaire) 50;Balise ou bouée 51;XXX 52;Eolienne = il reste à traduire ces types en tag osm pertinent. Après, on peut certainement indiquer les services supportés par un site : FH, 2G, 3G, 4G. Mais il faut aussi penser à la mise à jour de ces informations. A mon avis, si on intègre déja les sites radios, ca serait déja bien et le plus pertinent serait de pointer vers les données ANFR en indiquant une url associée au site. Eric 2015-04-29 20:02 GMT+02:00 Jérôme Amagat jerome.ama...@gmail.com: J'ai pris un exemple dans les données pressentes sur data.gouv.fr de lanfr voila ou se trouve le pylone : https://www.openstreetmap.org/node/3487062694 toutes les donnée sur cette station sont là : https://docs.google.com/spreadsheets/d/1Q2I5QfX0imcOyFI2BQlBSA8Y3rM3eVUY9w3EI1gFYXA/edit?usp=sharing c'est un pylône autostable appartenant à TDF, dessus il y a 8 supports exploités par différentes personnes ( 3*TDF, SNCF, FREE, Bouygues,...) et sur ces supports il y a des antennes, 29 ! en tout sur ce pylône (16 pour bouygues, 3 pour free, 2 sncf, 4 TDF, ...) et certaines antennes peuvent émettre sur plusieurs fréquences (par exemple pour une antenne free : UMTS 2100, LTE 2600 et UMTS 900 avec à chaque fois 2 bandes de fréquence). Maintenant comment intégré ça (ou au moins une parti) dans osm? tout ça est sur un pylône (d’après la vue aérienne) donc normalement 1 point dans osm, a moins d’empiler les nœuds les uns sur les autres. Le 29 avril 2015 15:35, THEVENON Julien julien_theve...@yahoo.fr a écrit : * De :* dHuy Pierre dh...@yahoo.fr * *C'est là que des tags comme height interviennent à mon sens, la hauteur et l'élévation de l'antenne permette de déterminer sa visibilité directement pas forcement, de plus en plus d antennes GSM sont camouflees donc le tag indiquant si elles sont visibles/cachees ou non a un sens http://www.animatif.com/panoramas/gsm/antenne-relais-camouflage.html http://www.google.fr/url?sa=trct=jq=esrc=ssource=webcd=3ved=0CDEQFjACurl=http%3A%2F%2Fwww.kathrein.fr%2Fmedia%2Fdocuments%2Fcellulaire%2Ffran%25C3%25A7ais%2Fsolutions%2520d%2527integration.pdfei=S91AVbvyFoLsat3agcADusg=AFQjCNGRbcj_yoVS0lEqo3MggQZe7nuAQQbvm=bv.91665533,d.d2scad=rja Julien http://www.google.fr/url?sa=trct=jq=esrc=ssource=webcd=3ved=0CDEQFjACurl=http%3A%2F%2Fwww.kathrein.fr%2Fmedia%2Fdocuments%2Fcellulaire%2Ffran%25C3%25A7ais%2Fsolutions%2520d%2527integration.pdfei=S91AVbvyFoLsat3agcADusg=AFQjCNGRbcj_yoVS0lEqo3MggQZe7nuAQQbvm=bv.91665533,d.d2scad=rja ___ 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Normalisation du tag antenne
Le 29 avril 2015 22:48, Eric Debeau eric.deb...@gmail.com a écrit : Dans les données ANFR, les différents sites possèdent des infos sur le support : 0;Sans nature 40;Sémaphore 41;Phare 4;Château d'eau - réservoir 38;Immeuble 39;Local technique 42;Mât 8;Intérieur galerie 9;Intérieur sous-terrain 10;Tunnel 11;Mât béton 12;Mât métallique 21;Pylône 17;Bâtiment 19;Monument historique 20;Monument religieux 22;Pylône autoportant 23;Pylône autostable 24;Pylône haubané 25;Pylône treillis 26;Pylône tubulaire 31;Silo 32;Ouvrage d'art (pont, viaduc) 33;Tour hertzienne 34;Dalle en béton 9;Support non décrit 43;Fût 44;Tour de contrôle 45;Contre-poids au sol 46;Contre-poids sur shelter 47;Support DEFENSE 48;pylône arbre 49;Ouvrage de signalisation (portique routier, panneau routier, panneau publicitaire) 50;Balise ou bouée 51;XXX 52;Eolienne = il reste à traduire ces types en tag osm pertinent. Sur chacun des cas, il y a plusieurs possibilités. Voici celles où on se sert du support pour indiquer qu'il y a de la radio dessus, avec au passage la ref ANFR. 0 : N'importe quel objet 40 : Il y a historic=optical telegraph http://wiki.openstreetmap.org/wiki/Tag:historic%3Doptical_telegraph, mais je doute que ce soit le sens de Sémaphore ici, plutôt une balise qu'une télégraphe. 41 : man_made=lighthouse (approved) 4 : man_made=water_tower (de facto) 38, 17, 19, 20 : On place un noeud au centre de la zone technique (si visible sur le toit), pas sur les antennes pouvant être réparties aux 4 coins). L'immeuble est tagué avec building=* (approved). 39, 8, 9, 10 : Maintes possibilités : préférer placer un nœud dédié sur l'emplacement supposé de la zone technique (local intérieur) 42 : man_made=mast (unspecified) 11 : man_made=mast + material=concrete 12 : man_made=mast + material=metal 21 : Au sens électrique : power=tower 22, 23, 24, 25, 26 : man_made=tower + tower:type=communication (unspecified) 31 : man_made=silo (de facto) 32 : Maintes possibilités 33 : man_made=communications_tower 34 : ? 43 : ? 44 : man_made http://wiki.openstreetmap.org/wiki/Key:man_made=tower http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dtower and service http://wiki.openstreetmap.org/wiki/Key:service=aircraft_control http://wiki.openstreetmap.org/w/index.php?title=Tag:service%3Daircraft_controlaction=editredlink=1 (proposed) 45, 46, 47 : ? 48 : man_made=mast + tag_pour_integration_paysagere=arbre 49 : Maintes possibilités 50 : La même chose qu'un sémaphore ? 52 : power=generator + generator:source=wind + generator:type=horizontal_axis Sinon pour être plus puriste : on place un nœud (ou une zone) sur toute la zone technique (faisant l’objet d'un acte de propriété ou d'un bail bien souvent) du site radio (les antennes en elles-même peuvent être plus largement réparties) et on met en relation avec le support situé à une distance plus ou moins grande. La zone technique est plus globale que le support en lui-même : http://www.europoles.fr/uploads/pics/cb_070427_1_l_06.jpg Après, on peut certainement indiquer les services supportés par un site : FH, 2G, 3G, 4G. Mais il faut aussi penser à la mise à jour de ces informations. Ça ne semble pas être le rôle d'OSM. Ces infos sont de nature très variable dès qu'on rentre dans le paramétrage on a un problème sur la vérifiabilité et sur la mise à jour. En mettant le numéro ANFR sur le support, on peut joindre facilement tout ou partie du jeu de données ANFR avec les infos géographique d'OSM. Exemple : https://carte-fh.lafibre.info/ Indiquer le support, quelques informations en plus pourquoi pas, mais utiliser le numéro pour faire une jointure c'est mieux. Ceci à coupler avec la référence du site chez l'opérateur, bien souvent visible sur le terrain, on peut avoir deux solides références. A mon avis, si on intègre déja les sites radios, ca serait déja bien et le plus pertinent serait de pointer vers les données ANFR en indiquant une url associée au site. Eric Pas d'URL, dont la structure peut changer facilement, mais le numéro identifiant le site côté ANFR avec un tag ref:FR:ANFR=*, just my 2 cts. ++ *François Lacombe* fl dot infosreseaux At gmail dot com www.infos-reseaux.com @InfosReseaux http://www.twitter.com/InfosReseaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Normalisation du tag antenne
De : dHuy Pierre dh...@yahoo.fr C'est là que des tags comme height interviennent à mon sens, la hauteur et l'élévation de l'antenne permette de déterminer sa visibilité directement pas forcement, de plus en plus d antennes GSM sont camouflees donc le tag indiquant si elles sont visibles/cachees ou non a un sens http://www.animatif.com/panoramas/gsm/antenne-relais-camouflage.htmlhttp://www.google.fr/url?sa=trct=jq=esrc=ssource=webcd=3ved=0CDEQFjACurl=http%3A%2F%2Fwww.kathrein.fr%2Fmedia%2Fdocuments%2Fcellulaire%2Ffran%25C3%25A7ais%2Fsolutions%2520d%2527integration.pdfei=S91AVbvyFoLsat3agcADusg=AFQjCNGRbcj_yoVS0lEqo3MggQZe7nuAQQbvm=bv.91665533,d.d2scad=rja Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Normalisation du tag antenne
Le mercredi 29 avril 2015 13:04:16 dHuy Pierre a écrit : C'est là que des tags comme height interviennent à mon sens, la hauteur et l'élévation de l'antenne permette de déterminer sa visibilité directement Là, en l'occurence, la hauteur n'indiquerait rien, car l'antenne est bien cachée à l'intérieur du clocher dont les baies sont obturées par des abat-sons (persiennes). -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
