[RFC] Feature Proposal - Cell Phone Reception

General talk Tagging general discussion
, ,
81

Yeah, it is another huge issue with the tag as currently used. The workaround, instead of just using mobile_reception=yes might be to have a node with tag prefix instead, in the format of mobile_reception:TYPE:MCC:MNC=SIGNAL.

e.g. mobile_reception:LTE:260:2=-104

where:

  • TYPE is network type (e.g. LTE)
  • MCC:MNC are network identifiers, e.g. 260:2
  • SIGNAL is signal strength (in dBm) (e.g. -104)

which users could retrieve from e.g. TowerCollector app, as shown in this picture:

1080×1920 113 KB

you could also accompany it with check_date:mobile_reception:LTE:260:2=2020-09-14 to indicate where it was last verified (if the data didn’t change).

That would solve most of the issues (i.e. you could detail reception of each different network operator and type there, and also see how strong the signal is, or have value none if your network and equipment does not have any signal there) while still remaining relatively simple to tag and process.

Although I’m not sure if it would work for Starlink example (i.e. it would work in Starlink uses separate MCC/MNC and T-mobile is roaming on it, but would stil fail if Starlink reuses T-mobile MCC/MNC and only identifies as different LAC - and I have no data on that), which is another big one.

All that being said, I personally still think that such data (while admittedly quite useful!) is a not a good match for OpenStreetMap, as it fails several Good Practices (e.g. “Map what’s on the ground”, “Don’t map historic events and historic features”, “Don’t map temporary events and temporary features”, Verifiability, etc.)

2 Likes
82

@kevinp2 But, as the data itsef is quite useful, I’d say it would be much better to collect that data in separate databases, and then overlay it on OSM basemap for display.

And lo and behold – that already exists!

Especially as you’d still need to use some app like TowerCollector or NeoStumbler, why not just use those apps to contribute directly (and automatically! much less work!) to databases like https://beacondb.net and https://opencellid.org ?

Advantages:

  • much simpler to both tag and use (just press the record button on the beginning and upload button at the end!),
  • avoids controversies and OSM database bloat,
  • avoids technical hurdles and human errors
  • such existing databases are already being well populated (and having significant userbases which continues to update them),
  • can also be used for rough geopositioning in case of no GPS coverage (or it being disrupted, or device not having GNSS) with apps like AltLocationServices
  • it already has web pages (and probably other offline ones) which show you the mobile network coverages (instead of one having to write such data consumer apps completely from scratch, as one would have to do for OSM)
7 Likes
83

@Matija_Nalis, I think we are talking past each other, but you raise some good points, and I will work them into the Wiki description of the key and that will of course be subject to evolving standards like any other tag.

84

Ok, this is interesting and I will look into this some more. Are there any iOS phone apps that work with these sites? Everything listed seems to be Android only.

85

that sounds great, thanks! :+1:

Sorry, I’m not using (nor have ever used) iOS so I have no idea what works there or not[1]. :man_shrugging:

I would guess at least opencellid.org website map (being written in leafletjs) should work in any web browser, including mobile iOS ones.

But you should inquire/check communication channels of those respective projects directly about what you want, as you’d have much higher chances of getting good answers (compared to getting them here in unrelated project forum).

  1. But, if there is any iOS app which would work with OSM’s mobile_reception=yes/no data (which you were thinking of using), it should be relatively easy for its developers to modify it to also include beacondb.net / opencellid.org data into it ↩
1 Like
86

A slight tangent, but is there an existing tag for a spot that’s well-known to have cell reception (or even designated as such with signs)? That would be far less ambitious than some of the mapping that’s taken place in relation to this proposal, and important to distinguish from it, but a much clearer fit for the OSM database proper.

Imgur

3 Likes
87

You mean, besides the mobile_reception=yes proposed here?

For the marker itself, I don’t know of anything better than a marker=plate + utility=telecom + operator=* + inscription=* + support=pole + description=*

But of course, if there is no mobile signal around, and there is suddenly good mobile signal there, that might probably indicate that quite nearby there exists man_made=mast + tower:type=communication + communication:mobile_phone=yes - so you could certainly map that if you can see it.

88

The signs I linked to aren’t utility markers, they’re destination signs to guide vehicular traffic. For example, the U.S. Forest Service put up the following sign somewhere along this road to guide visitors to one of the pullouts (lay-bys) along it:

Imgur

I don’t think there’s any special infrastructure here, just a “good” line of sight to distant cell towers compared to the surrounding terrain. I would’ve been inclined to tag the parking lot as something like mobile_reception=yes, except that it would be mistaken for the more experimental observations being discussed here.

The AquĂ­ Hay Señal de Celular signs in Argentina appear to conform to the Vienna Convention pattern for any sort of motorist service, although it doesn’t appear in the latest decree or the accompanying sign manual. I don’t know the criteria for posting these signs.

New South Wales posts Mobile Phone Area signs directing motorists to mobile base stations or, alternatively, passive hotspots that amplify signals from towers as much as 100 kilometers away.

89

You could invent another value like mobile_reception=designated (or something like that) if that would help differentiate it.

And there is always human-readable description=* (or mobile_reception:description=* if you prefer suffix version of it) where you can explain the details, which should help.

1 Like
90

mobile_reception=designated would be my suggestion as well, no need to overthink it. Attach a description=* and a image=* / wikimedia_commons=* if possible

1 Like
91

I agree we shouldn’t overthink this. So if I understand correctly, we should use mobile_reception=designated for the signposted spots but avoid using mobile_reception=yes for anything because it gets into the weeds of broadcast engineering. What about indicating that there’s no cell service?

A roadside sign assembly consisting of four regulatory signs: No OHV Use, No Fuel Services, No Cell Service With Preserve. (NPS / K. Lewandowski. Public domain as a work of the U.S. federal government.)
A roadside sign assembly consisting of four regulatory signs: No OHV Use, No Fuel Services, No Cell Service With Preserve. (NPS / K. Lewandowski. Public domain as a work of the U.S. federal government.)1920×2437 455 KB

mobile_reception=no is already used 455 times. The strained analogy to
 hygienic facilities doesn’t give me confidence that the existing usage is based on deterministic observations.

1 Like
92

mobile_reception=only_from_satellite?

1 Like
93

Ahh, but how about from the top of that mountain in the background? :crazy_face:

94

@Minh_Nguyen , I personally set mobile_reception=no (or yes) based on direct observation on two mobile devices while I was physically standing there.

If that is not deterministic, nothing in OSM is. Heck, we have random editors adding and deleting features based on outdated satellite imagery in places they have never been to! Just a week ago I had to revert deletions of new roads that actually exist.

95

mobile_reception=designated is a good idea and I agree with it.

96

Outdated imagery is indeed a problem but a different problem. I don’t doubt that you directly observed the signal strength at a given location, but as noted earlier, a reading or two in one moment isn’t necessarily predictive of a different device connecting to a different carrier at a different time of day under different weather conditions. These factors make OSM a poorly suited tool for the job.

From where I sit, I can currently pick up San Francisco TV stations and maybe an AM clear channel station from the other side of the Rockies, but only because it’s a clear night and I have a decent antenna, and only until the sun comes up. Yet I’m not about to dump my DXing reports into OSM. Other sites have much better suited data models and processes to manage the relevant probabilities and conditions, or simply catalogue the reports as the snapshots in time that they are.

Regardless, my only interest is to record a different sort of information about a place: whether it claims to be a good or bad place to expect cell service. I don’t want someone fudging this plainly observable information just because they happened to get lucky or unlucky, and I don’t want data consumers or end users to be confused about what they’re seeing in the data. To me, mobile_reception=* is a misleadingly straightforward key for an experimental observation. Call it something less authoritative, perhaps, and it could easily coexist.

9 Likes
97

different carriers would have to be tagged with their own tags, naturally. There is no correlation between reception with one carrier and another (unless they have some agreements, like you can use their cells if your provider doesn’t cover the area, etc.).
Different devices may behave differently, but if there is no signal at all, it will be the same for everyone, and if there is good reception, it will work with all devices. For edge cases, something like the weather or the quality of your antenna, etc. could make a significant difference between receiving a signal and not, agreed.

If we would want to record these, we would also have to distinguish between 2G, 3G, 4G and 5G, sometimes the signal is ok for phone calls (2G) but nothing else.

I agree that OpenStreetMap is not suited well for this task though, because it is ultimately raster data, for a coverage map, you would have to take many measurements, every few meters possibly. Then again, I can also imagine how punctual data like “there is commonly mobile reception on this hill” could be useful in some situations.

2 Likes
98

Let’s think about how cell companies make those coverage maps that they put on the internet.

Well, they just input their cell tower locations and make gradual colors decreasing from them.

Of course they introduce a blur factor, to not allow anybody too precise information.

Sure you might say those circles might not be perfectly isotropic due to antenna considerations. But usually there’s three antennas, each for 120°.

Okay now let’s discuss the method of these cell reception value indicators.

Well for good coverage you’re going to need one every five meters.

So you already get the problem, you’re going to have many many more nodes if you do it that way.

So let’s admit it, it’s all because the cell tower locations are secret that’s why you end up doing it the blind way


Knowing where the cell tower actually is, all you need to do is drive your car up to it then your guaranteed 100% coverage for your brand. Even knowing where it is on the horizon, as long as you have a good view
 that’s all you need to do.

Knowing where the cell tower is allows you to know which side of an obstacle you should stand on, also.

And actually, hunting down cell towers is not that hard at all I found.

First in urban areas just look for suspicious roof tops. You know, water tanks that don’t seem to be made out of metal.

Then walk around the block and see if the Tower Collector app shows you are changing from 120° antenna number one to number two to number three and back to number one.

That nails it. Of course that’s just for your phone company, not the other leading brand.

In rural areas they can’t hide very long either especially if you notice the signal’s getting pretty warm. You know something like -80 db.

Anyway, I’m just saying time is better spent hunting them down. They’re not going to change very much over the years. They all got complicated rent contracts and all those fiber cables.

And don’t believe those crowdsourced “average” cell tower locations. They’re just an average of the middle of a cell. Way off usually.

Sure, their phone company’s cell_ID will change every few years. But not their location!

4 Likes