It happens to all of us, we see poor data on Google Maps, suggest the edit and receive the "Not Applied" response.
We are told that we do not live in a perfect world and that Maps has to put filters in place to prevent spam and poor data. These filters that are looking for "bad stuff" are not perfect and some quality edits will receive the wrong verdict: aka false positives. In other words, "good stuff" is falsely labeled as (potential) "bad stuff".
But what if we turn it around?
What if other algorithms were looking for good stuff and evaluate our edit suggestions on the basis of Mapping Guidelines/ Rules and information available.
So in other words, when that system would accidentally givegood stuffa "Not Applied" it would be a false negative 😉
Getting to the point...
My suggestion is to have anextensionto the current verification procedure.
AFTER a Local Guide has received the "Not Applied" response we should be able incertain types of cases to trigger the other type of algorithm, allowing for a re-evaluation.
The most obvious cases where this should be possible right now are:
1) A pinpointer/ map marker is at the wrong place and satellite view clearly proves it. 2) A name is not following rules (e.g. includes legal terms or wrong use of CAPS). 3) A name is not consistent with other branches of the same store.
Surely, the AI/ algorithms must be advanced enough to analyze and evaluate these types of false positives. Just to be clear, we would not be resubmitting our data, all we would do is tag a false positive with a "category".
It goes further!
The OBJECTIVE is to improve the quality of the data on Maps. Not to get our edits approved.
An example where Maps would even benefit from this extension in case of "positive positives":
- I tried to change the name of a branch of a store because branches of the same store are not consistently using the same name.
- As it turns out my suggested name is wrong in the eyes of Google. It would be correct to give my edit a "Not Applied" response (aka positive-positive).
- Irrespective if I am aware that my correction is not the right solution to the problem I was trying to solve. I trigger the re-evaluation by labeling my "Not Applied" with issue #3 from the above list.
- By bringing the easy-to-solve-problem to the attention of the system - using the proposed extension of the verification procedure - my action could trigger an auto-correction route.
I hope I am making sense here. If not please let me know.
Another approach to this idea is that we Local Guides have the option to simply "label" wrong data on maps, without giving the solution. It could be a great intermediate step for Local Guides that do not have the confidence to make a certain correction, because they are insecure about their solution, but do know that the data needs fixing.
Could you provide a real-world example of #3 (above) "A name is not consistent with other branches of the same store." (That would be two branches to show the inconsistency ; ) -- and links are always helpful.)
On a different note, did you mean to use the word not in the sentence "if I am aware that my correction is not the right solution to the problem I was trying to solve...", rather than "if I am aware that my correction is the right solution to the problem I was trying to solve..."
Thank you @MapWrangler for your interest in my idea suggestion.
Of course, not every person who thinks he/she wrongfully received a "Not Applied" response, is indeed correct. So, what I was trying to demonstrate with the "It goes further" section of my idea presentation, is that even poor data contributions could still have the right intent of which Maps could benefit.
In other words, when a Local Guide sees a problem/ issue, he/she could flag the issue by labeling what is wrong (e.g. issue type 1, 2 or 3). The actual solution offered by the editor, aka the suggested edit, could still be denied. However, now the algorithm is focusing on the type of issue and how to (auto) fix it.
In my idea presented above, I suggest that this extension to the verification process could be triggered AFTER a person received the "Not Applied" response. The "I wish to escalate this false negative" feeling that lots of Local Guides get when their correct edit was rejected.
But the "how" of the implementation is not the point here. The point of my idea is to open up the verification procedure/ algorithm and offer a way to improve machine learning.
I am not sure why you are asking an example of number 3 of my presentation, but I am happy to do so. If I needed help in fixing an issue, I would, of course, post it on the "How-Tos" board 😉
Earlier this year, I was in La Laguna (a town where I do not live but visit from time to time). I discovered a local vegetarian/ vegan hamburger shop with four branches on our island. There was no consistency in the names whatsoever and some even had keywords stuffed with the name.
I was able to make all the desirable corrections on the branch that I visited and had some success in changing the names of the other three. However, one location gave me a "Not Applied" as I was trying to clean up the map.
As you can see 3 out of 4 are now consistently called "Burger Mel" except this one at the time of writing. My argument is that "Burger Mel Benavides" as a stand-alone might be okay as a name, but since this Burger Mel is one out of four, I argue that the mapping rules state that they all should be called Burger Mel.
If I remember correctly, this edit was pending for a while, so it wasn't only the algorithm that was working against my intent. However, would I have been able to label my edit with my intent to achieve naming consistency with the other branches. The Googler or the algorithm could have made a different evaluation of my contribution.
>> The point of my idea is to open up the verification procedure/ algorithm and offer a
>> way to improve machine learning.
I understood the purposes of your suggestion -- I thought it was well written and clearly described.
>> I am not sure why you are asking an example of number 3 of my presentation,
>> but I am happy to do so
I've found that it's (virtually) always helpful to have a specific example(s) when discussing specific mapping topics. In the case of #3, there are [operative] exceptions to the name consistency rule.
As it turns out, your example with Burger Melmay be one of them.
When I began mapping a couple of years ago in the now retired Map Maker, there was a very clear rule that location descriptors were not permitted in the name. Mappers would edit out the location descriptor and the edit would (usually) be approved without any difficulty.
There was at that time an unwritten exception to the location descriptor rule -- hotels (resorts, etc) were allowed to have a location descriptor in their name, and we mappers didn't edit those businesses.
What's happened since then is that the location descriptor rule is not enforced by Google -- and especially by Google My Business (GMB), with the result that the map is virtually flooded with names containing location descriptors. Said differently, there is no penalty for a business to include a location descriptor. (I'll add the information that all Burger Mel locations are claimed business under GMB.)
In my view the number of names containing location descriptors will only increase as new (as well as existing) business owners will look at the map to get ideas on how to list their business and will see *many* businesses with location descriptors and (may) think "well, that's what I should do with my name".
@Flash recently (09-23-18) commented in a thread "GMB has of late not enforced removal of location descriptors from businesses, but that does not mean the rule doesn't exist."
Flash quoted the Google My Business (GMB) guideline: Name consistency All business locations within the same country must have the same name for all locations. For example, all Home Depot locations should use the name "The Home Depot" rather than "Home Depot" or "The Home Depot at Springfield".
The GMB guideline may have been recently amended: (you have to drill down through the "Learn More" expansions to find this) Chains and brands Name consistency There are two exceptions to this policy: 2. If some of your locations consistently use a different name in the real world - on their storefront, website, stationery etc. - these locations can use this different name. * Acceptable name variations: "Intercontinental Mark Hopkins San Francisco" and "Intercontinental New York Barclay"; "PFK" (for locations in Quebec) and "KFC" (for locations in the US and rest of Canada)
The bottom line reply to Briggs from a GMB Product Expert was:
"You're not the only one who has issues with this. Google are not open to discussion on the matter. Unfortunately there is nothing further I can do."
As you can see, reporting a business to our friends over at Google My Business is useless as "Google doesn't want to discuss the issue" with the result that the GMB Product Experts can't escalate the violation to be fixed.
@JeroenM, I do realize that there are specific -- shall we say "more technical" points that could be argued here, such as Burger Mel may not (is likely not) be using the location "on their storefront, website, stationery etc." Additionally, it could be argued that Burger Mel isn't (yet) using a location descriptor in the names at their other three locations -- thus they are in violation of the "consistently use a different name in the real world" rule (above).
As a practical matter, applying the sentiment of Google's position in the preceding comments I don't see either of these arguments gaining any traction.
To be clear, I am not advocating for or against the use of location descriptors in a name. Rather my advocacy is the same that many other mappers cry out for: a clear rule regarding location descriptors, with no unwritten exceptions nor "wink-wink" acceptance -- that is applied worldwide across all mapping forums, including GMB.
It is a terrible disservice to (especially new) mappers who are freely giving their time to volunteer to make a better map to have confusing, ambiguous rules that aren't enforced -- especially when the "fix" appears (to me) to be so easily accomplished.
Last, with regard to your suggestion, in light of the above, I question if #3 would be implemented even if the concept of your suggestion was accepted.
Thank you for your comprehensive response @MapWrangler. It looks like we are not able to give kudos to comments in the Idea Exchange, but a big KUDOS for that! Thank you, again.
I was aware of most of what you said and like Briggs, I have been to battle at the GMB forum and got a little burned on this naming rule matter. @Flash helped me out and I particularly remember his example how location descriptors are often the cause of bad merges between a store and a shopping center.
Leaving this whole discussion about the lack of clear rules and the enforcement of them (hear, hear, I could kiss you for your commentary, lol) aside, it is indeed up to Google Maps developers to evaluate which "issue categories" could be applied in the "idea concept" I tabled here, if they decide to do so. My number 1, 2 and 3 were only examples.
Again, thank you for your constructive feedback and your commitment to helping fellow mappers who take their responsibility as map-editors serious.
@JeroenM Wow! 😳 very thoughtful and thought-provoking post.
I think you’re onto something, and I upvoted (or whatever we do). But even without getting too in the weeds with hypotheticals or the minutiae, your suggestion in the last graf (if I understand it, essentially a ‘flag for review’ button in instances when a correct edit suggestion is initially rejected) is pretty simple and the benefits are apparent.
Well done - I’ll be curious to see how others respond. Great post 🙏
@kmichaelcook Thank you for your support and feedback. Indeed, it is a concept that I am tabling here. I leave the details to the Google wizards when they decide it is indeed something they would like to pursue.
Google Maps could make it easier to update places that have moved to a new location on maps by giving us options to type the new address of these places that moved/no longer exist. At the moment, we can only drag the Map Pin to the new location (which takes a long time). Why not just allow local guides the option of being able to type in the new address and the location is entered automatically into maps (instead of dragging) as we do when searching for a place/navigating?
2022
Search Page
