subject:"\[OSM\-talk\-fr\] Normalisation du tag antenne"

Merci à tous pour les remarques mais le principe d'un pad est aussi d'ajouter 
vos idées en collaboratif :)
Pour répondre à tous:@marc_sibert: Justement je propose de ne pas taguer la 
station mais bien les antennes pour éviter le sur nombre d'antenne@Thevenon, 
pertinent mais je vois que ça a été ajouté au pad donc nickel@Dumoulin, yep 
bien compris :)@Lacombe: Pour que vous puissiez pusher vos proposition 
directement et qu'on y travaille de manière collaborative avant de faire naitre 
un vote etc... en plus je souhaiterai le mettre simultanément en anglais et en 
fr.@Lacombe (bis): justement j'indique que le tag des infos gsm ne devrait pas 
être fait et le pourquoi de cette idée. J'ai contacté des responsables réseaux 
chez des opérateurs avant de mettre en place ce point justement. Les LAC, CID 
and co ne sont pas cartographiable de manière viable sur osm (lien avec une db 
possible par contre)
@Amagat @Sibert: justement dans des exemples comme ça on unifie les ensembles. 
Mettons les antennes free couvrent toute à 360 degrés, et dispose d'une réseau 
lte et d'un umts. L'information du coup se fusionne sous la forme d'une antenne 
opérée par free etc... Et du coup 18 antennes se transforme en une seule. Il 
faudrait garder au moins 1 point par opérateur et usage (mais du coup je crois 
avoir mal lu la db car j'avais l'impression qu'un support pouvait avoir 
plusieurs opérateurs)@Debeau: si on a l'élevation.@Debeau: Pour info le tag 
made_man=mast n'a JAMAIS été voté donc aussi valable que le mien. Cependant 
pour tous les autres support cette discussion a eu lieu précédemment sur cette 
ML pour les intégrer via osmose.@Lacombe: les services sont importants au 
contraire: un répéteur gallileo ou gps peut etre utile à connaitre en bord de 
mer pour la navigation alors que si c'est juste antenne radio c'est inutile 
(voir le use_case). Au pire unifier toute la téléphonie.
@cquest: l'ID ANFR: effectivement je l'avais oublié j'ai rajouté. @cquest: 
cependant la conservation de données complémentaires peut etre pratique, comme 

Ce que je veux proposer c'est un tag assez complet pour ne plus avoir à 
l'amender après. Et surtout pas un tag qui ne serve qu'en France!J'amende le 
doc en prenant en compte vos remarques.
Librement,
 


 Le Jeudi 30 avril 2015 11h46, Christian Quest  a 
écrit :
   

  
 
 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 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


  ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Normalisation du tag antenne

2015-04-30 Thread François Lacombe

Le 30 avril 2015 15:36, dHuy Pierre  a écrit :

> @Lacombe: Pour que vous puissiez pusher vos proposition directement et
> qu'on y travaille de manière collaborative avant de faire naitre un vote
> etc... en plus je souhaiterai le mettre simultanément en anglais et en fr.
>

Les motivations du wiki sont les mêmes.
On peut échanger sur le pad en effet, par contre on va devoir ré-expliquer
nos conclusions à une partie de la communuauté qui prend le wiki comme
référence.
En utilisant les pages de discussions sur les proposition, on garde une
trace tout aussi pérenne et plus centrale.

Les langues sont aussi gérées sur le wiki.
Je ne maitrise que peu le pad, comment ca se passe pour une version
bilingue ?


> @Lacombe (bis): justement j'indique que le tag des infos gsm ne devrait
> pas être fait et le pourquoi de cette idée. J'ai contacté des responsables
> réseaux chez des opérateurs avant de mettre en place ce point justement.
> Les LAC, CID and co ne sont pas cartographiable de manière viable sur osm
> (lien avec une db possible par contre)
>

Ok, +1


> @Amagat @Sibert: justement dans des exemples comme ça on unifie les
> ensembles. Mettons les antennes free couvrent toute à 360 degrés, et
> dispose d'une réseau lte et d'un umts. L'information du coup se fusionne
> sous la forme d'une antenne opérée par free etc... Et du coup 18 antennes
> se transforme en une seule. Il faudrait garder au moins 1 point par
> opérateur et usage (mais du coup je crois avoir mal lu la db car j'avais
> l'impression qu'un support pouvait avoir plusieurs opérateurs)
>

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.

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.

Ce ne sont pas des notions triviales, nous devons faire attention à ce que
le modèle qui sera établi soit très précis dans les termes utiliés.

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
Les antennes :
Azimut 1 :
https://www.google.fr/maps/place/Rue+Kimmerling,+69003+Lyon/@45.755367,4.86215,3a,23.7y,86.84h,116.86t/data=!3m4!1e1!3m2!1sPlB8T0a5HoFU4U0VHX0RWw!2e0!4m2!3m1!1s0x47f4ea7a3b1f1a0f:0x5ebfb167d782f423
Azimut 2 :
https://www.google.fr/maps/place/Rue+Kimmerling,+69003+Lyon/@45.754476,4.863752,3a,15.2y,8.61h,119.7t/data=!3m4!1e1!3m2!1soT6lM6968aCgjK14qFar6g!2e0!4m2!3m1!1s0x47f4ea7a3b1f1a0f:0x5ebfb167d782f423
Azimut 3 :
https://www.google.fr/maps/place/Rue+Kimmerling,+69003+Lyon/@45.755633,4.86476,3a,15.2y,244.85h,109.48t/data=!3m4!1e1!3m2!1sbLFXt4_RIw2A2rLlz8hFhQ!2e0!4m2!3m1!1s0x47f4ea7a3b1f1a0f:0x5ebfb167d782f423

@Lacombe: les services sont importants au contraire: un répéteur gallileo
> ou gps peut etre utile à connaitre en bord de mer pour la navigation alors
> que si c'est juste antenne radio c'est inutile (voir le use_case). Au pire
> unifier toute la téléphonie.
>

Oui, ce serait bien d'unifier toute la téléphonie parmi la variété de
services radio existants.


> @cquest: l'ID ANFR: effectivement je l'avais oublié j'ai rajouté.
> @cquest: cependant la conservation de données complémentaires peut etre
> pratique, comme
>
> Ce que je veux proposer c'est un tag assez complet pour ne plus avoir à
> l'amender après. Et surtout pas un tag qui ne serve qu'en France!
> J'amende le doc en prenant en compte vos remarques.
>

+1, tout a fait motivé pour y arriver.

A+

François

--
*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.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

2015-04-30 Thread Nicolas CORBEL

Bonjour à tous,

2015-04-30 17:02 GMT+02:00 François Lacombe :

>
> 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

2015-04-30 Thread Jérôme Amagat

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  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 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


  ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Normalisation du tag antenne

2015-04-30 Thread Christian Quest



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

2015-04-30 Thread Jérôme Amagat

Le 30 avril 2015 18:41, Christian Quest  a écrit :

>
>
> 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.
>

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


>
> --
> 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

2015-04-30 Thread Christian Quest



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

Re: [OSM-talk-fr] Normalisation du tag antenne

2015-04-30 Thread Eric Debeau

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 :

>
>
> 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

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 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 :

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

Re: [OSM-talk-fr] Normalisation du tag antenne

2015-04-30 Thread Jean-Marc Liotier

Je prend la discussion en cours de route... Mais si je puis me permettre 
quelques suggestions...


Commencez pas border un consensus concernant les artefacts physiques 
observables visuellement - types d'antennes par exemple. C'est un but 
atteignable et ce sera déjà beau.


Veillez à insister sur la distinction entre l'antenne et son support (je 
vois souvent des confusions) - ça permettra de traiter proprement le cas 
très courant du support garni d'une palanquée d'antennes diverses, tout 
en simplifiant la taxonomie (mât+yagi, pylône+parabole, clocher+omni etc.)


Concernant les caractéristiques radio... Vous êtes dingues. Ambitieux, 
courageux et tout ça - mais dingues quand même. Les opérateurs ne sont 
même pas complètement certains de ce qu'ils ont sur le terrain et ça 
bouge tout le temps... J'ai mal pour vous rien que d'y penser. Collez 
l'identifiant ANFR comme lien vers les détails (laissez les applications 
utilisatrices construire l'URL) et oubliez le reste - pour votre bien !


Oubliez aussi le site radio - c'est un identifiant impossible à vérifier 
visuellement. Vous pouvez évidemment identifier le site physique (un 
shelter, un bâtiment, une salle - cf. les débats précédents concernant 
les sites de télécommunications) mais la couche radio est purement 
logique - et donc reconfigurable... Laissez l'utilisateur lire 
l'identifiant ANFR de l'antenne et suivre le fil pour trouver à quel 
site elle appartient.



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Normalisation du tag antenne

2015-04-30 Thread Philippe Verdy

Le 30 avr. 2015 18:42, "Christian Quest"  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

@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  a écrit :
   

 
Le 30 avr. 2015 18:42, "Christian Quest"  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

2015-04-30 Thread Jean-Marc Liotier


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

2015-04-30 Thread Philippe Verdy

Le 1 mai 2015 00:35, dHuy Pierre  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

2015-04-30 Thread Philippe Verdy

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  a écrit :

> Le 1 mai 2015 00:35, dHuy Pierre  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

@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  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  a écrit :

Le 1 mai 2015 00:35, dHuy Pierre  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

Re: [OSM-talk-fr] Normalisation du tag antenne

Le 1 mai 2015 10:20, dHuy Pierre  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

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  a écrit :
   

 Le 1 mai 2015 10:20, dHuy Pierre  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

2015-05-01 Thread François Lacombe

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 

Le 1 mai 2015 13:55, dHuy Pierre  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  a
> écrit :
>
>
> Le 1 mai 2015 10:20, dHuy Pierre  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

L'ANFR ne s'occupe pas vraiment non plus des supports, pas plus que des
antennes. Ce qui le concerne c'est la localisation du site (quelque soit le
nombre de supports), les fréquences utilisées, les puissances émises et les
zones de couverture (qui dépendent de la hauteur de l'antenne, du relief et
de facteurs environnementaux comme la présence de réflecteurs qui peuvent
altérer les signaux et surtout créer des zones de résonnance où localement
les puissances reçues peuvent être suramplifiées, et où ailleurs on observe
des zones de non réception ou un signal trop faible)

L'ANFR est au départ un registre de fréquences allouées car elles ne sont
pas extensibles et sont un domaine public à partager. De plus certaines
fréquences sont soumises à des régimes d'autorisation (et à octroi de
licence payante), mais toutes sont réglementées même quand elles sont en
usage libre (fréquences Wifi/BlueTooth) et plus ou moins standardisées au
plan international avec des normes imposées aux constructeurs de matériels.

Avec la desnification des usages, il a fallu aller plus loin dans la
précision des puissances et zones de couverture qu'un simple enregistrement
des fréquences utilisées. La seule position de l'antenne, sa hauteur ne
suffit plus, il faut tenir compte aussi de la nature des signaux et des
bruits impulsionnels parasites, et des profils des lobes d'émission
(utilisation de guides d'ondes), et spécification des tolérances
acceptables sur l'orientation des lobes et sur la dispersion des fréquences.

Et aussi aider à réglementer les normes permettant à des émetteurs voisins
de négocier leurs usages en cas de conflit ou débordement, avec des
systèmes automatiques de réduction de leurs émissions (comme on en trouve
même dans les émetteurs grands publics des téléphones ou des routeurs wifi)
par détection de certaines équipements prioritaires (radars de navigation
aérienne par exemple, signaux d'urgence de la sécurité civile, capables de
téléguider l'extinction partielle des autres émetteurs pour se réserve une
bande passante suffisante, de façon temporaire voire permanente pour
interdire localement certains canaux).

Au delà de ça,l'ANFR est aussi un gardien de surveillance du spectre et
peut faire effectuer des contrôles (autrefois c'était TDF qui s'en occupait
en Ffance au temps du monopole public, et même encore avant l'ORTF, y
compris pour les usages militaires en coopération avec la gendarmerie, sauf
pour les fréquences qui étaient totalement fermées à l'usage civil ou pour
les fréquences internationales des satellites)

Le 1 mai 2015 21:42, François Lacombe  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.
>
> 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 
>
> Le 1 mai 2015 13:55, dHuy Pierre  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  a
>> écrit :
>>
>>
>> Le 1 mai 2015 10:20, dHuy Pierre  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 lis

Re: [OSM-talk-fr] Normalisation du tag antenne

2015-05-01 Thread Jérôme Amagat

Le 1 mai 2015 21:42, François Lacombe  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

@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  a 
écrit :
   

 

Le 1 mai 2015 21:42, François Lacombe  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
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo

Re: [OSM-talk-fr] Normalisation du tag antenne

2015-05-01 Thread Jean-Marc Liotier

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  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  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

Le 2 mai 2015 00:21, dHuy Pierre  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

Re: [OSM-talk-fr] Normalisation du tag antenne

2015-05-02 Thread Eric Debeau

Salut

J'a


Eric

2015-05-02 5:04 GMT+02:00 Philippe Verdy :

> Le 2 mai 2015 00:21, dHuy Pierre  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

@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  a écrit :
   

 Salut

J'a


Eric

2015-05-02 5:04 GMT+02:00 Philippe Verdy :

Le 2 mai 2015 00:21, dHuy Pierre  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

Re: [OSM-talk-fr] Normalisation du tag antenne

2015-05-02 Thread Eric Debeau

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 :

> @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  a écrit
> :
>
>
> Salut
>
> J'a
>
>
> Eric
>
> 2015-05-02 5:04 GMT+02:00 Philippe Verdy :
>
> Le 2 mai 2015 00:21, dHuy Pierre  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

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  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 :

@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  a écrit :
   

 Salut

J'a


Eric

2015-05-02 5:04 GMT+02:00 Philippe Verdy :

Le 2 mai 2015 00:21, dHuy Pierre  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

2015-05-02 Thread François Lacombe

Le 2 mai 2015 00:09, dHuy Pierre  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 pro

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  a 
écrit :
   

 

Le 2 mai 2015 00:09, dHuy Pierre  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 (communicati

Re: [OSM-talk-fr] Normalisation du tag antenne

2015-05-02 Thread Nicolas CORBEL

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 :

> 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 
> a écrit :
>
>
>
>
> Le 2 mai 2015 00:09, dHuy Pierre  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 l

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  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 :

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  a 
écrit :
   

 

Le 2 mai 2015 00:09, dHuy Pierre  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

Re: [OSM-talk-fr] Normalisation du tag antenne

2015-05-02 Thread Philippe Verdy

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  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  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 :
>
> 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 
> a écrit :
>
>
>
>
> Le 2 mai 2015 00:09, dHuy Pierre  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

Re: [OSM-talk-fr] Normalisation du tag antenne