Proposal talk:Telecommunications tower
As there is no border between telecommunication towers and towers that just transmit television signals I suggest not to use man_made=telecommunications_tower.
communication=* seems to be an intresting idea, but this broadcasting value should be split somehow. Maybe use
More specific values can be found from this proposal Communications_Transponder Maybe it would be a good idea to find a way to unify both proposals somehow?
- That proposal has a drawback as there is no good way to mark multiple transpoders on the same spot.--RM87 16:24, 11 October 2011 (UTC)
- Thanks for your feedback, I think it is a good idea to use keys that can have the value "yes". Please have a look at the new proposal! --Derstefan 12:28, 2 January 2012 (UTC)
Use man_made=tower as main key instead
Hi, if you see that this proposal had been rejected Proposed_features/Base_transceiver_station the lessons learned should be to use the man made=tower key instead. You are right that power=tower had to be part of this, too. But on the other hand this is part of a logical closed key namespace instead.
But I like the idea of adding more details and unite man made=mast, and this proposals:
- Proposed features/Communications Transponder
- Proposed_features/Base_transceiver_station
- Key:landmark
--!i! 13:11, 2 January 2012 (UTC)
- I'll second that - there is no definite way to distinguish proposed feature from
man_made=tower
. "Telecommunications tower" just copies a natural language term without any clear definition. --BushmanK (talk) 16:27, 18 February 2017 (UTC)- +1 for man_made=tower too. Please note that refactoring power=tower or power=pole to man_made namespace had been discussed but rejected due to the large amount of objects already using those 2 values of power key.
- I would theoretically agree that supports should not be part of the network namespace used for power, gas, telecoms. But we are more defined by history for now Fanfouer (talk) 20:27, 19 February 2017 (UTC)
- I'd say, that it is driven by fear (rational or not) of automated changes. Eliminating non-verifiable "communication towers" would allow an improvement of data quality since nobody knows what "communication tower" actually is. Same applies to moving support structures out from
power=
key - it will finally allow to properly tag any kind of support structures independently of its function. So, yes - fear in expense of possible improvement. --BushmanK (talk) 21:29, 19 February 2017 (UTC)
- I'd say, that it is driven by fear (rational or not) of automated changes. Eliminating non-verifiable "communication towers" would allow an improvement of data quality since nobody knows what "communication tower" actually is. Same applies to moving support structures out from
- I'll second that - there is no definite way to distinguish proposed feature from
More services, specify technology
Maybe you can add some more services? I think these are useful:
- communication:railway=yes
- communication:military=yes
- communication:amateur=yes
- communication:aeronautical=yes
- communication:maritime=yes
- communication:emergency=yes (emergency services like police, ambulance, THW (in Germany)
- communication:timesignal=yes (like DCF77)
And I have one more suggestion: communication:*=yes means that this service is used, the technology could be specified in the value. (like already suggested below: Not network specific)
Example: communication:television=yes simply means that this tower broadcasts TV program, communication:television=analogue or communication:television=dvb-t specifies that it is broadcasted analogue or as DVB-T. --rurseekatze 20:28, 4 January 2012 (UTC)
- As I understand, you suggest to make communication really indipendend from the mounting (tower, mast, antenna, transceivers, ...) that sounds good to me. I saw there is already, frequency=* that would support this kind of tagging in the same way as this proposals: Proposed features/radio communication, Proposed features/Communications Transponder --!i! 08:49, 5 January 2012 (UTC)
- No, I would keep it like in the proposal, just add the additional tags I suggested. --rurseekatze 14:41, 5 January 2012 (UTC)
Not network specific
Maybe we should pay attention, that we don't use terms that are specific to a single networking standart (as BTS is mostly by GSM, for UMTS its just TS). So we could extend this schema for some expert users to add the networks communication:mobile_phone=umts --!i! 13:32, 2 January 2012 (UTC)
Mast vs. Antenna
Hi, as the pages man made=mast and man made=antenna don't give hints where the exact difference is between both, we should clearify it within this proposal. As I understand:
- man made=antenna is a giant antenna (tall as a building) that is mounted directly on the ground (or a very small base building)
- man made=mast is a carrier for multiple smaller antennas, for example the usaual base transceiver stations, definitly not as significant as a antenna or a tower
? --!i! 21:19, 2 January 2012 (UTC)
- Thank you, that is a good explanation. I think the pictures also help people to get the difference. Additionaly a man_made=telecommunications_tower is a large antenna mounted on top of a large concrete tower ("Fernsehturm"). Hopefully we can start the voting for this proposal soon? --Derstefan 12:17, 3 January 2012 (UTC)
- ok great :)
Even if I can understand you entheusiasm (well I remember I did some proposals long time ago, too ;) ), I highly recommend to think again on the problem before starting the vote! The history showed us, that the community is strictly introducing new keys that are already somewhere covered else.... --!i! 13:00, 3 January 2012 (UTC)
- Very bad definitions! The tag man made=antenna only says an antenna is present, not what it may be mounted on nor how big or small it might be. The tag man made=mast only says a mast is present, not what it may be used for, it could be used to light a football field. There are a few antennas close to the ground in Western Australia that are not large in themselves, but there are quite a few of them; 2,048! http://www.mwatelescope.org/ Warin61 (talk) 04:16, 23 November 2018 (UTC)
Detailed description of mobile phone base stations
I found a tagging of mobile phone base station. It is currently tagged like this:
tag | description |
---|---|
man_made=communications_transponder | |
communication:mobile_phone=yes | |
service=gsm | |
MCC=262 | mobile country code, Germany is always 262 |
MNC=01 | mobile network code, every operator has an own value |
operator=T-Mobile D | |
gsm:LAC=37890 | location area code, different values in GSM, UMTS,... |
gsm:cellid=4107;4108;4109 | every "beam"/antenna has own cell ID, corresponds to gsm:direction |
gsm:direction=0;120;240 | normally every BTS has 3 beams into 1/3 of the angle |
I think this is a first good way to tag a BTS, but it has some drawbacks:
- I would put the value "gsm" into the key "communication:mobile_phone".
- The man_made=communications_transponder is needless and was always a strange tag. Furthermore the BTS could be mounted to a man_made=watertower.
- The operator is tagged twice: MNC=01 already means that operator=T-Mobile D. Again, operator could be unclear, if the BTS is mounted to e.g. a chimney with the operator "Stadtwerke".
So I propose to tag a BTS like this:
- communication:mobile_phone=gsm
- MCC=262
- MNC=01
- gsm:LAC=37890
- gsm:cellid=4107;4108;4109
- gsm:direction=0;120;240
with additional keys where the BTS is mounted to, as described on the main page of this proposal. --Derstefan 13:41, 21 February 2012 (UTC)
Antenna vs BTS vs supporting structure
So, this is a typical case in urban environments. A single antenna is mounted on each wall of a bigger building. Sometimes there's two or more BTS'es in that same building (could be competing networks), and the total number of antennas is any multiple of 3 around the building. The antenna is not the BTS, so tags should not claim it such. Alv 09:14, 4 May 2012 (BST)
- Thanks for this, Alv. I think the tags don't claim to be a BTS. If you want (and have the information) you can tag one single antenna with its cell id and main lobe direction. And if one doesn't know anything about it, one can tag it as communication:mobile_phone=yes. This should be always right. -- Derstefan 14:20, 4 May 2012 (BST)
still active?
I noticed that we have a lot of tags focused on GSM and telecommunication in general. Are there any plans to start an united schema as in power=*? --!i! 22:13, 21 February 2013 (UTC)
- Hello !i!, I am still alive and still have an eye on the proposal. Nowadays you can only introduce a new tag by proposing it if the tags are already somehow established. The tags communication:radio=*, communication:television=* and communication:mobile_phone=* are on a good way... What would you suggest? What's the deal with power=*? --Derstefan (talk) 19:00, 22 February 2013 (UTC)
- I just suggest to find a similar bundled schema, was power=* which is in wide use, as everybody knows this primary key. The communication topic in opposite seem to be very mixed up :/ User:!i!/telecommunication. But I agree, that this communication:*=* tags might be useful --!i! 19:06, 22 February 2013 (UTC)
- Yes, the schemes for subtagging are sometimes a bit difficult. One approach is to separate the main and the sub key with a ":" and to use this as a key again. Using semicolons to concatenate several attributes is ugly and should be avoided for objects containing more than one value, e.g. communication=radio;television;mobile_phone One should use communication:radio=yes, communication:television=yes and communication:mobile_phone=yes instead to only have one value for every key.
Also you have to destinguish between the kind of object (e.g. man_made=tower) and the use. These things can also correlate: A man_made=communications_tower will be different to a man_made=chimney with both having mobile phone antennas. The simple tag communication=* is useless in my opinion. But I can easily be convinced if someone proposes a coherent scheme. For now I recommend tagging the communications stuff as I proposed. --Derstefan (talk) 19:47, 22 February 2013 (UTC)
- Yes, the schemes for subtagging are sometimes a bit difficult. One approach is to separate the main and the sub key with a ":" and to use this as a key again. Using semicolons to concatenate several attributes is ugly and should be avoided for objects containing more than one value, e.g. communication=radio;television;mobile_phone One should use communication:radio=yes, communication:television=yes and communication:mobile_phone=yes instead to only have one value for every key.
- Which is close to my own opinion. Unfortunately we have also a lot of competing tags and we still miss some aspects. I think it would be nice, if we can (re)create an bigger schema, that brings all stuff together. Guess this will help a lot for applications who build upon the "normalized" data :) --!i! 21:26, 22 February 2013 (UTC)
Multiple operators on the same "mast"
How to tag multiples operators and technology on the same place ?
Example : Node [1111082873]
- man_made=water_tower
- MCC=208
- MNC=01;10;20
- communication:mobile_phone=01:gsm,umts,umts900;10:gsm,umts900;20:gsm,umts900,fh
- communication:direction=01:60,290;10:70,290;20:50,170,290
- communication:height=01:35;10:30.7;20:32
- communication:operator=Orange;SFR;Bouygues Telecom
Like name=*, I suggest to suffix key with the unique MCC/MNC pair :
- man_made=water_tower
- MCC=208
- MNC=01;10;20
- communication:mobile_phone:20801=gsm;umts
- communication:direction:20801=60;290
- communication:height:20801=35
- communication:mobile_phone:20810=gsm;umts900
- communication:direction:20810=70;290
- communication:height:20810=30.7
- communication:mobile_phone:20820=gsm;umts900;fh
- communication:direction:20820=50;170;290
- communication:height:20820=32
--Pyrog (talk) 08:23, 13 October 2013 (UTC)
Using ref instead of copying external databases
Even if the tagging model to indicate technologies on pylons/masts is consistent, is that a good idea ? We should use ref:* tag to put a reference to an external DB record which will be more accurate than OSM can on its own.
Furthermore, documenting radio cells (LAC, CellId) is a service concern, not an infrastructure one. OSM should document infrastructure (masts, pylons and their visible shape), services are for operators. The main reason is because services always change, more often than infra which is expensive to modify. Operators will drive their networks without noticing OSM and our cells data will be 99% wrong. Fanfouer (talk) 14:51, 8 December 2013 (UTC)
Put tower number in name tag
One wants the tower name to show up properly on https://osm.org and https://openinframap.org/ so currently one needs to do
name=NurdTel 2443 Cell Tower
Also one should be careful with w:ENodeBs, E.g. only use the 7556 of
417556-21
(Taiwan CHT example) Jidanni (talk) 03:27, 14 June 2020 (UTC)
- No tagging for renders.
- References seen in place often go in ref=* and more specific or post-processed (to match business rules of public databases) ones go in a subset of ref, like ref:FR:Orange_mobile=*.
- Names are another field of knowledge, usually a common names for human readability conveniance regarding telecom sites Fanfouer (talk) 15:47, 14 June 2020 (UTC)