I have developed a proposal to indicate the availability of cell phone service at nodes and areas, https://wiki.openstreetmap.org/wiki/Proposal:Cell_reception .
There is currently no such usage of a tag or any related tags known. Please add any valuable discussion on the wiki discussion page or here.
There is coverage:mobile_phone:PROVIDER that some people in California started to use two years ago.
A comment to your proposal: It seems to be too detailed to me - reception might vary a lot depending on the exact model of phone and weather conditions. The type of network, provider and maybe three levels of reception strength seem to be the most detail that can be determined reasonably well.
Good catch! Though looking at the coverage tag it looks like it’s only been used 23 times according to taginfo, and looks like the only values used “att” and “verizon” which I feel could easily be incorporated into this new tag and updated accordingly.
I agree that it’s a little detailed, but the intent was to have the extra detail as additional tagging just as supplemental info. Initial tagging is as simple as yes/assumed/limited/no.
Would your suggestion to be to remove the “sms,voice,data” keys? That would leave the additional keys as provider, type of network, and three levels of strength (not including “none”). I agree those initial keys are somewhat duplicates of the “strength” value so maybe those should be removed.
I think the biggest issue with verifiability is defining the boundaries of areas, and I think the proposal might be improved by specifying (at least initially) a very narrow set of POIs that this would be defined for. People would likely use it in other contexts, and we could figure out after such use what they might have meant by it, but starting narrowly would help flesh out the proposal.
To expand on the issue – if a restaurant node was tagged as cell_reception=limited, does that mean that the tagger tried it somewhere in the restaurant and something failed, or that they tried it throughout the restaurant and it didn’t work anywhere?
And if cell_reception=yes was tagged on a multi-story building, does that imply that the basement has full cell reception, or just that at least one place in the building has good coverage?
If we limited the proposal just to campgrounds, we could define the values as: “in at least one place in the campground”.
That’s a really good point. I feel like it should almost be defined as “worst case scenario,” but I understand that for significantly large areas/buildings that would be unrealistic to actually verify accurately.
Though I think there’s many more applications other than just campgrounds, that’s just the one that I relate to the most. Maybe we go your route and specify use cases for outdoor leisure POIs? We could specifically reference campgrounds, parks, beaches, lakes?
Though I’m not sure how keen I am to map this kind of detail, here are a few other points of reference from my own past experiences in California, in case there’s interest in expanding the scope of this proposal beyond recreational sites:
I agree your building scenario is difficult to manage and likely isn’t a very good application for this tag.
I also feel your train scenario is not a good application for this. Depending on the POI’s (I wouldn’t tag the train station, but possibly the path), you could tag the train path as cell_reception=limited, signal=issues, internet_access=no. Though I don’t think this is a good path forward since we could go in as deep as segmenting portions of the line as “good service” and “no service,” but in reality this data would be very difficult to find and manage and would have limited practical use.
I feel like we should definitely focus this in on recreational sites for now, unless people have better ideas.
I appreciate knowing if I go to a campground and it does or doesn’t have “free WiFi” (free is included in my campsite fee, we all know this).
Beyond that, if I want (what passes for) reception coverage of Verizon or AT&T or T-Mobile or whatever, I’ll go to their (somewhere between shitty and fair-to-bad) online maps. These are blocky, some of the most stochastically variable data you might map. They used to be VERY shitty, now they are at-a-wider-level perhaps somewhat helpful to show “patches” and “holes” in coverage. North America has vast swaths of “dark and quiet” areas with absolutely no coverage. It does seem the colors are chosen not to be helpful, but to be confusing and hide differences in technology or rules for how these data are calculated. It’s fairly rude data, in short. My guess is that these carriers and their lawyers came up with the thin but lumpy soup they publish. It’s junky or hazy at best. Putting these in OSM is wrong about one second after you enter the data. While that could be said to be true of all our data, when we know that and can say that ahead of time, I can’t think of a better reason for the community to say “no.”
Boundaries in area are indeed where something as variable (as a decibel range as a UHF signal) is a problem. OSM can’t even hope to describe those within reasonable accuracy, leading to obvious (and endless) disagreements as to the accuracy of our data. A Wi-Fi working “at the campground” is such a reasonably true assumption I don’t even think more needs to be said.
These data (cell phone reception) do not belong in OSM. The boolean value of whether a campground has Wi-Fi, yeah, that’s about right. Beyond that, go looking elsewhere for what you think you know today and likely changes next week. I’m not alone on this opinion, either, but I’m listening.
If you wanted to go start a social media group on collecting these, making your own data to publish, hey, go nuts. Not in OSM, say many. I wouldn’t say that sort of knitting is what our fabric is for: the data you propose start out far too noisy, ill-defined, rapidly-changing and sometimes not initially predictable as to truth or quality. Even discussion your of syntax and semantics is (and will almost inevitably be) fraught with fuzzy definitions that were only true last week.
No, thanks.
So you’re saying the campground deep in a national park where there’s is no commercial construction activity allowed will magically get cellular service next week? Or that campground outside of town away from anything but just happens to be next to a cell tower will lose it’s service?
Your argument could be said about anything mapped in OSM. Wi-Fi could be added / removed / misconfigured any day of the week. That speed limit sign could be changed. That road could be reconstructed. Just because data changes doesn’t mean it doesn’t belong.
Additionally, why map Wi-Fi? We’re not measuring the dB strength of it across every coffee shop and college campus that has it. What’s the difference? I appreciate the criticism, but don’t see the value in your argument. This is the same boolean value of Wi-Fi.
I would love for you to expand on this because I whole heatedly disagree.
Of course not, I never said that, you did.
No, again, you are making assumptions I never said. Please don’t do that.
I already mentioned “true about all data in OSM.” Enough said.
Wi-Fi is a place we already do map. OSM asserts this with values starting with internet_access=wlan (and the syntax opens out from there…many here have not started using that form until now, which seems like it isn’t well-focused or is too narrowly-focused).
Mapping Wi-Fi at a campground can be said to be an OSM thing: it exists, we do it. A lot in Europe in OSM, free or fee Wi-Fi is expressed in many ways. You’re talking about “signal level data the carriers already publish” and that is where why? becomes No.
So why not indicate cell service? It is (from the proposal process page):
Just because it’s already published doesn’t mean it’s not valuable to the OSM community. Google Maps already has 99% of roads and buildings published and most local governments have maps with park information, bike lanes, etc.
Pointing towards Google Maps doesn’t help your case.
For some people, especially recently (pandemic-era) having free (or fee, in some cases) WiFi is almost as important a commodity as the air we breathe. That might be a bit of an exaggeration, but when I think of how important it is to map important amenities like libraries (where you can find free WiFi, sometimes) is SO important, it MUST be mapped in OSM.
The commercial radio emissions from commercial cell towers? Eh, no. They already publish (a hazy, noisy, sometimes shitty version, but hey, that’s what it is) those data. “Go look elsewhere” (where they already are). I see no especially extra add to the value of OSM for these, and such a possible injection of noise and endless argumentation (about something which exists already), I want to say “no, thank you.” So, I do.
Hence I will stop mapping McDonald’s because of the commercialization and any pay for service…
We’ll have to agree to disagree. I see the value in the data and will continue to map in true OSM fashion adding what’s valuable to me. Hopefully others see the value in it too.
Look, plenty of businesses are in OSM, I agree with you this a rapidly-changing “sub-fabric” of OSM that is highly valuable. I am 100% NOT in the way of that!
In the case of commercial radio emissions, when I see what is mapped elsewhere, because it is a never-ending, chase-it-forever, never-the-same-twice, chase-your-own-tail thorny bush as it is, I point and say “bad idea to put into OSM.” That’s what this is, I’m repeating myself as to my reasons, so I’d prefer to listen. I suppose nobody can stop you, but you’ll be forever chasing wrong data, and in a big, obvious, already-exists way. Why would anyone do that?
A campsite may have satellite uplink internet. They may reshare this through their wifi or in collaboration with the provider by a picocell plugged into this uplink that converts it into cell service.
One issue I have wit the proposal that wasn’t mentioned above is that the wording implies that an OSM mapper must carry a SIM & latest generation phone from each of the 4-8 operators (or however many non-virtual networks exist in the country) to check that they all have coverage at the point to fill in the form. This is not how OSM works. Volunteers carry whatever they have and share whatever information they find on site and have to have a way to crowdsource and progressively improve upon existing uploaded data by volunteers of different capabilities, free time and equipment.
You also seem to conflate usage sufficient for emergency (where any phone can roam onto any network and you don’t need much quality) and casual usage due to internet-addiction (I actually consider campsites under radio silence a feat due to this!).
We love McDonalds because there are so few public toilets on the streets and none of them are free!
On the coverage maps published by providers here, they generally use different colors by generation (4G/5G) and indicate whether full indoor reception is expected (within normal buildings around windows) or whether you are only expected to enjoy reliable service if you go out on the street away from the building towards the nearest cell tower and finding a good microwave sweet spot to stand in (so-called “outdoor covered area”).
Because this is such a complicated matter, any tag you add will add burden to your future maintainers of the given objects. Hence why I recommend that you drop almost all keys and stick to the basics that convey your intent:
And nothing else. I mean, imagine you marking the site as excellent for data, because you were alone, but when during peak season, 100 more kids (phones) join you, the connection will be slower, less reliable and even smaller in coverage area. CDMA is unique in that the edge of its coverage can take “breaths” depending on how many are using it - shrinking or expanding over time, so your data point could be way off due to multiple causes.
Steve & bkil pretty well covered it - different networks, different phones on the same network, how crowded any spot is at the time = how much demand, whether there may be a good spot up that hill.
Sorry, no, not an OSM thing as too many unknown (& unknowable) variables.
Rather than creating a proposal, I’d suggest a more JFDI approach - you yourself go out and map the information unambiguously that you want to so that there’s a base of data to work from for any future data consumer. “unambiguously” means “in a way that can’t be mistaken for something else” - it doesn’t matter exactly what key you use - if it’s unambiguous it can always be changed to some more popular schema later.
As noted above there absolutely are verifiability issues so you need to be really clear about what you’re measuring - there at least two variables to measure “reception” for (carrier and band). It’s also worth looking at some other “sliding scale” value OSM tags to see how they are handled - wheelchair, tracktype etc. so that you don’t end up with something too complicated.
Personally, I suspect that you might struggle to get enough people to contribute data to make it useful, and I somewhat share @Fizzie41’s opinion that it’s not going to work.