Arc is currently not utilizing business/location names from the Google Places database. Instead, all locations default to street addresses only, even for major, well-established businesses that are clearly marked on Google Maps.
For example, when visiting Costa Coffee (which is properly named on Google Maps), Arc only shows the location as “53 High Street” until a private place is manually created with the name “Costa Coffee.”
Scope and Impact
This affects ALL locations, not just specific cases or certain areas
The issue has persisted for more than a year
This behavior is different from previous versions when Arc used Foursquare
Every location requires creating a private place to show its actual business name
This significantly reduces the app’s usefulness for location tracking
Creates unnecessary extra work for users who need to manually create private places for every business they visit
Technical Context
This appears to be an issue with how Arc implements the Google Places API, not a limitation of Google’s data
The same locations are properly named in Google Maps and other apps using Google Places
The issue has continued through multiple app updates
The only current workaround is to manually create private places for any location where you want the actual business name to appear instead of the street address. This is not a practical solution for occasional visits or when traveling to new areas.
Request
Could you please investigate why Arc is not utilizing the business names available in the Google Places database? This seems to be a regression in functionality compared to both the previous Foursquare implementation and what should be available through Google Places.
I just tested here, and when tapping the “Search Google Places” button at the bottom of the results list it’s working for me. I see new results appear that are using the business names (eg shop names, restaurant names, etc).
Arc gets street addresses separately, from Apple’s “reverse geocode” service. It doesn’t actually use Google Places for street addresses (though I’ve been tempted to change that over the years, but unfortunately Google Places is very expensive).
When you see a timeline item showing up in the timeline view with only street address, that typically means the “reverse geocode” has been completed, so the Visit item has been marked with that address, but the Visit hasn’t had a Place assigned yet. Then when you go into the Edit view for that Visit you can manually select a Place from the results there, to assign to the Visit.
Oh, one significant change in the past year is that … well there were several changes. Maybe I should list them chronologically:
Foursquare started charging a lot more, while their database quality steadily declined, making them nonviable for continued use. I eventually removed the Foursquare lookups from the app.
I switched to Mapbox’s Places API as the primary source, to replace Foursquare. Mapbox’s API was cheap/free and “good enough”. Not as good as Foursquare was in its heyday, but … good enough.
To offer greater quality over Mapbox’s database, the “Search Google Places” button was added to the bottom of the results list. Google Places overall has much higher breadth and depth of data than Mapbox (and Foursquare, since its decline), but costs an order of magnitude more, hence it being an optional button at the bottom instead of the default.
Mapbox updated their API to no longer include “points of interest”. Oh they shipped a “new” replacement API that does include POIs, but it’s designed to be unusable for apps like Arc Timeline. Feels a bit personal, but let’s not get paranoid. The upshot of that is that (for now) Arc’s initial, immediate results are empty. Mapbox become unusable, leaving only the manual “Search Google Places” button at the bottom as functional.
So that’s where we are today. It’s supposed to be Mapbox results first - automatically - and then Google Places results manually, if you tap the button at the bottom. But the Mapbox results are now empty (no idea what they were thinking there - seems idiotic to break their service), but the Google Places results still work correctly as long as you tap that button at the bottom.
Oh and the street addresses you see come from Apple’s reverse geocode service only. That at least still works (albeit having sometimes not ideal quality).
Ah! An answer as to why this was broken! (sorry for not reporting but sounds like you are well aware.)
Have you considered querying OpenStreetMap directly via the Overpass API instead of through Mapbox? Protomaps is also possibly of interest as a basemap if the goal is reducing API costs, though I don’t think an iOS renderer exists for it yet
Painfully aware, unfortunately. The Places API situation has been an ongoing problem for quite a few years now, with Foursquare fading away, Google charging a fortune, Mapbox playing silly games…
I did! Maybe a few times over the years. Though I can’t remember what my conclusions were. I think the rough sense has been that using OSM’s db directly (or semi-indirectly but not via Mapbox) has always been a potential alternative, but it’ll likely be a lot of work and the db quality isn’t great. But then Mapbox’s db quality isn’t great either (I think they blend OSM, old Foursquare snapshots, maybe some of their own also…)
The most recent possibility I’ve been considering is self hosting Foursquare’s now-open db snapshots, and using that to replace the defunct Mapbox results, while still keeping the Google Places fallback.
But yeah, all of the options tend to be a lot of work, so for now I’m deferring it, and eating the cost of Google’s horrific API prices.
Looks interesting! Don’t think I’ve seen that one before. Though in truth I pay nothing to Mapbox for using their maps SDK, nor even for using their places db (when it was still usable). They’ve got a super odd business model that gives away far too much for free. I wish they’d just charge me a sensible rate and continue providing a sensible places API. But you can’t even talk to them about it - they don’t answer emails.
And Mapbox’s iOS maps SDK is actually really good these days. I’ve had my gripes with it over the years, but recently they’ve really been excelling with maps SDK quality. A shame their places API isn’t doing similar.
I’ve found Mapbox to be worse than OSM on many occasions — mostly because it lags behind OSM by a lot and so I have no recourse to fix it within a predictable time frame! The fact that Mapbox will render a place on the map but not expose it within the places API boggles my mind.
Good point. I think I went with Mapbox over more pure OSM options simply because it was the easiest API implementation pathway. Which of course backfired when they intentionally broke their API while shipping a new one that’s … also broken. Ugh.
I’m also not entirely fond of Google Places. It has various strange quirks, both at API level and database quality level. But for now it is the leader in overall breadth and depth of coverage, so … I have to begrudgingly spend the money on it.
I think I’d be most happy with a pure OSM implementation, that also allows users to feed edits and additions back to OSM. Someday maybe I’ll get there…
FWIW this is big up there on my wishlist though understandably I know your hands are full with the re-write of existing features right now
The lack of good OSM data apps on iOS is one of the things that contributes to its POI database being lacklustre! Should the time ever come, I’m happy to consult on tagging best practices / UX for this.
Me too. I’ve long wanted to be more active (or active at all) on OSM, but the convenient tooling just isn’t there. (Or wasn’t there last time I checked, which was admittedly probably some years ago). And it makes total sense that an app like Arc should be providing those kinds of tools.
In the LocoKit rebuild (LocoKit2 on Github) I’ve exposed the Places system this time. In old LocoKit the Places system was purely in the private Arc Timeline app repo, but this time I wanted to get at least the core of that in the public / open source lib.
I haven’t included the PlaceRankingManager or the API integration layers, because with those in the open source lib it feels like it’d be basically providing a complete app minus the UI.
Aside: I’m always confused why competitors haven’t picked up on LocoKit over the years. Although admittedly the old lib had become quite creaky, having lived for almost a decade. But it’s weird that new potential competitors pop up every year or two, building everything from scratch (and inevitably doing it much worse), then eventually dying off a year or two later from lack of users. LocoKit is sitting there, ready and waiting to be used to build a competent competitor. shrug
LocoKit2 is much easier to work with, being all modern Swift 6 and no dirty old outdated patterns. Will be curious to see if anyone goes for it this time. Though admittedly the UI layer itself is also a large undertaking. These are not trivial apps to build.
Anyway potentially a lot of the OSM integration could get into the open source LocoKit2 this time around. And just because the Mapbox and Google Places API layers still live in the Arc Editor private repo, doesn’t mean an OSM API integration layer couldn’t live in the public LocoKit2 repo…
Thanks for the explanation. It was simply the move from default naming of places to manual requesting that had thrown me. I understand your (cost) justification. Still seeing examples where the map shows a business or labelled location, and neither the default nor Google places search brings it up as a name, but I understand now that these are coming from different sources
