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 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 > tout ca ? > Si on veut le proposer au vote sur @tagging, on y coupera pas. > > > François > > > > _______________________________________________ > 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