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 <[email protected]> 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
[email protected]
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-fr
