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
