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

Répondre à