Pour ta norme pour cartographier les données associées aux antennes si tu veux.
Le Samedi 2 mai 2015 23h08, Philippe Verdy <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>:
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 <[email protected]> a
écrit :
Le 2 mai 2015 00:09, dHuy Pierre <[email protected]> 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
[email protected]
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-fr
