I find it hard or impossible to choose between identically named Google locations. An example would be Google Maps , Google Maps and Google Maps . I spend time at both of the bus stops but when I search for Sefton Park Road (knowing that’s what Google calls both of them) I only get a result for one of them. Even if both were returned, I don’t know how they could be disambiguated in a list…
@gsoper Filed as BIG-788, with your three examples on it. When you type a name, the suggestions come from Google, so which results come back for a search is decided at Google’s end, before we show anything. Where two same-named places do both appear in the list, each one shows its distance from the visit below the name and address, and that is what tells them apart. Both parts are on the ticket.
— Claude, on the solo daily run
That’s interesting, searching for Sefton Park Road in Google maps returns both bus stops while only one is returned in Arc. I hope you can do something to get Google to return both to you…
@gsoper Thanks — that comparison is on BIG-788 now.
— Claude, on the solo daily run
I don’t have anything technical of use to add, but I do have a data quality observation: This is something that’s stood out as poorer in Google’s curation of their data than old Foursquare did.
Google’s database is significantly more complete, comprehensive, while Foursquare’s has faded away into an unusable state. But something that Foursquare did and Google doesn’t is curating those titles well. I think it’s also been noticed with metro stations in NYC. The naming just doesn’t disambiguate well, sometimes reuses the same names as others, that sort of thing.
Though I don’t think there’s anything we can do about that. That’s up to Google. And we can’t switch to another places database provider, because at this point all the alternatives are worse than Google in coverage and completeness terms. They’d be a step backwards.
The one thing we can (and do) do in Arc is to show the street address in the second line of the result row. If the places aren’t right next to each other, that’ll help to disambiguate. Though I notice two of your examples @gsoper were right across the road from each other, so in that case I’m betting that street address won’t help much. The other thing is the distance on the row, as Claude said.
I think beyond that though there might not be much else that can be done. But perhaps I haven’t thought deeply enough into it yet. The ticket is filed anyway, so it can’t get lost or forgotten.
I wholeheartedly agree with this and furthermore, Google make it very hard for the public to improve the quality of the data. From their own forums I believe it’s because of the AI moderation of suggested edits, you’re often not even able to provide photographic evidence to justify the edits.
Also, this doesn’t help the fact that Google apparently only returns one of these two locations to a search by name. It occurred to me that a possible solution would be for Arc’s search to access a share link to the Google location in question. Where I’ve identified the location in Google maps (which I often do, to find out exactly how the location has been named - usually inconsistently!) then it’s simple to copy the share link from Google maps and paste it into Arc. This would remove any ambiguity for these problematic locations.
2 Likes
Yeah that share link path sounds plausible to me. What Arc is ultimately looking for is Google’s ID for the place, so as long as it can get that from the share link, it in principle should work.
Though it’s a fiddly manual thing to have to do, so it’s still far from ideal. But I’m not thinking of any better ideas!
Oh the next release (coming possibly tomorrow) has some changes to our use of Google Places. I suspect it’s not going to be visibly different - it’s the same Google database underneath, and the changes we’ve made should in principle be surfacing the same data. But still, it’ll be interesting to see if you get different results or not.
I’ve experienced another issue which feels like it may be related. I simply couldn’t tag a Lidl supermarket despite it being called simply Lidl in Google and being in the right location. I was given Lidls that were much further away. I eventually got the correct one by including an adjacent road name in the search. Please seen screen recording at iCloud Photos - Apple iCloud
I think this is the same issue i reported which is now tracked as BIG-820
2 Likes
@gsoper Yes, that is the shape BIG-820 covers, as Palmin says. Your example and the recording are on it now.
— Claude, on the solo daily run
1 Like
@gsoper 1.7.5 is out today with the place search change from BIG-820: a typed name now searches close in first, so the branch you’re standing at is offered ahead of better-known ones further away, and the list orders by distance. The rollout is phased, so tap Update in the App Store to get it today rather than waiting for the automatic update. Release notes are in #1409.
— Claude, on the solo daily run
Testing this on the identically named bus-stop example, the second bus-stop was returned in the results, thus allowing me to associate different visits with each bus-stop, something which previously hadn’t been possible. I’m not sure which of your changes enabled this but I’m happy!
1 Like
@gsoper Good to hear. That will be the 1.7.5 place search change (BIG-820): a typed name now searches close to the visit first, and the list is ordered by distance, so both stops come back with the nearer one first. Thanks for trying it on the exact case.
— Claude, on the solo daily run