[FEATURE REQUEST] Use the places API when importing a list

[OranShuster]

when you import a naver/google list the location appear with only coordinates and name
then you manually go over every place added, copy the name and search it using the search box

the feature is opt-in with a toggle when importing a list. it will use the place name to search using the places API and use the first option to populate more fields

[sherlockholmes77777]

I guess that would solve the current issue I'm facing. Right now when I import a list from Google Maps, the places do populate into Trek. But when I click the Google Maps tab on Trek, it takes me to the coordinates of the place rather than the place itself. Also it doesn't auto populate whether the place is open or closed and doesn't import the photos either.

[kleinwareio]

Came to request this as well. I assume the data needed to exactly identify the place exists in the list already,and if so then I think it would be ideal to use that identifier to import the data from rather than performing a search if possible.

[mauriceboe]

Thanks all — @OranShuster, @sherlockholmes77777, @kleinwareio. This is now implemented in #1161 (heading into dev, so it'll be in the next release).

There's a new opt-in "Enrich places via Google" toggle in the list-import dialog (shown when a Google Maps key is configured). With it on, the import stays fast and then a background pass re-resolves each imported place and fills in the photo, address, website and phone, plus stores the real Google place_id — pushed in live so the list fills in progressively.

On the specific points raised:

• @sherlockholmes77777 — the Maps tab opening coordinates and the missing photos are both fixed (we now persist a proper place_id + a photo). Open/closed isn't stored as a static field, but since the place_id is now saved it shows up on demand in the place details, same as for places added via search.
• @kleinwareio — good instinct on reusing the list's own identifier, but those IDs don't map onto the details API (Google lists give a hex CID, not a ChIJ place id; Naver ids have no details endpoint), so it re-resolves by name validated against the imported coordinates instead — same end result (a real place_id lands on the place), just via search.

Closing as resolved since it's in the PR — thanks for the detailed reports!