That kind of rewriting would be stupid, but of course isn't what's actually happening. In reality there's no match for the geocoding search [34th and 6th ave ny,ny], so it is interpreted as a local search for [34th and] in the vicinity of [6th ave ny, ny].
Why isn't there a match for the geocoding search? It's not because somebody "destroyed Google Maps on iOS", but most likely just due to a switch to a newer geocoding index. These would be updated frequently with new data from all kinds of sources, just like web search won't use a static index but one that changes over time.
Why wouldn't this kind of change be noticed when changing to a new set of data? Because it'd be essentially impossible to find all possible changes to geocoding results from a data change, and even less feasible to verify which of the results are correct. So there's always going to be some kind of sampling going on when validating new data or code changes. And with a sensibly sized sample, you're not very likely to be checking a particular intersection in a very large country.
These kinds of regressions would have popped in and out during the whole lifetime of Google Maps. Just because you noticed such a change for the first time doesn't mean that they are currently failing when they weren't before.
The issue has more to do with google trying to match each address with a business. They are failing because 34th and 6th is one of the most popular tourist corners in NYC which you'd think would be tested during QA. Moreover most Maps users will attest that when they enter an address they do not want it auto translated to the venue name...again something that should have never made it beyond an idea stage or been reverted soon after release.
No, I'm quite sure that the issue is that geocoding search fails and Maps has to fall back to a local search.
It is probably bad UX to not make it clear that this is what's happening. But it would be much worse to fall back to a local business search, drop a pin on the result, and have the user think that it was an actual geocoder result.
Intersection searches are rare, and there's a limit to how large a set of queries you can have in a "the results of these searches can never change" golden set. Again, these kinds of things have always happened with map data, it's not some kind of new phenomenon. I'd bet there's no less QA going on than during the times when you thought the quality was good.
Comments
That kind of rewriting would be stupid, but of course isn't what's actually happening. In reality there's no match for the geocoding search [34th and 6th ave ny,ny], so it is interpreted as a local search for [34th and] in the vicinity of [6th ave ny, ny].
Why isn't there a match for the geocoding search? It's not because somebody "destroyed Google Maps on iOS", but most likely just due to a switch to a newer geocoding index. These would be updated frequently with new data from all kinds of sources, just like web search won't use a static index but one that changes over time.
Why wouldn't this kind of change be noticed when changing to a new set of data? Because it'd be essentially impossible to find all possible changes to geocoding results from a data change, and even less feasible to verify which of the results are correct. So there's always going to be some kind of sampling going on when validating new data or code changes. And with a sensibly sized sample, you're not very likely to be checking a particular intersection in a very large country.
These kinds of regressions would have popped in and out during the whole lifetime of Google Maps. Just because you noticed such a change for the first time doesn't mean that they are currently failing when they weren't before.
The issue has more to do with google trying to match each address with a business. They are failing because 34th and 6th is one of the most popular tourist corners in NYC which you'd think would be tested during QA. Moreover most Maps users will attest that when they enter an address they do not want it auto translated to the venue name...again something that should have never made it beyond an idea stage or been reverted soon after release.
No, I'm quite sure that the issue is that geocoding search fails and Maps has to fall back to a local search.
It is probably bad UX to not make it clear that this is what's happening. But it would be much worse to fall back to a local business search, drop a pin on the result, and have the user think that it was an actual geocoder result.
Intersection searches are rare, and there's a limit to how large a set of queries you can have in a "the results of these searches can never change" golden set. Again, these kinds of things have always happened with map data, it's not some kind of new phenomenon. I'd bet there's no less QA going on than during the times when you thought the quality was good.
Intersection searches are rare
No! Intersection searches are the norm, at least in New York City. And the intersection I listed is one block from the Empire State Building.
They may not be doing less QA. Just a crappier job.