Google Maps Platform API 應用於相簿 GPS 地點管理：Geocoding、Places API 與費用優化實戰

為什麼照片相簿會需要 Google Maps Platform API？

數位照片通常會在 EXIF 中保存 GPS 經緯度，但單純看到 latitude、longitude 對一般使用者沒有太大意義。照片相簿真正需要的是把 GPS 轉換成「國家、城市/行政區、景點名稱」，甚至進一步列出拍攝位置附近可能的景點，讓管理者挑選最合理的地點。筆者於2026年6月底架設了自己第一個相簿網站「Skypray Photography」，第一次上線就有約5,000張照片，對於照片地點的標記，自然也需要有對應的程式來管理。沒有GPS的早期單眼相機所拍攝的照片，需要批次呼叫Gemini API或手動上傳照片到Gemini網站來找尋可能地點和GPS（手動上傳照片到Gemini網站是適用最新的模型，辨識效果最好，而大量辨識使用的Gemini API勝過OpenAI API，在於外國名稱的翻譯較近於我們日常使用），但是就算有GPS的照片，那「國家、城市/行政區、景點名稱」這3個欄位如何自動帶入呢？就是今天要討論的重點。

雖然有免費的OpenStreetMap可以用，但是實在太差強人意了，常常只會辨識出附近的街道名稱，我要的是照片的景點，可不是它位於哪條路上。這時就會用到 Google Maps Platform 的兩大類服務：Geocoding API 與 Places API (New)。前者適合把座標轉成地址與行政區，後者則適合搜尋景點、商家、設施與其他 POI（Point of Interest）。兩者搭配使用，比只靠單一 API 更容易得到適合照片管理的地理資訊。

先理解 SKU：Google Cloud 帳單上的「計費項目」是什麼？

SKU（Stock Keeping Unit）原本是商業上用來區分不同商品或服務的「品項代碼」。在 Google Maps Platform 裡，可以把 SKU 簡單理解成Google 帳單上的計費項目名稱：你的程式呼叫某個 API、要求某些資料，Google 就依規則判斷這次使用觸發哪一個 SKU，再把使用次數累積到那個項目。

因此，「我有呼叫 Places API」還不足以判斷價格。同一套 Places API (New) 裡可能出現不同 SKU，例如：

Autocomplete Requests：取得地點名稱的自動完成候選。
Place Details Essentials：取得地址、座標等基本地點資料。
Place Details Pro：要求較進階的地點資料，例如可閱讀的地點名稱 displayName。
Place Details Enterprise：要求評分、網站、電話、營業時間等更高階資料。
Place Details Enterprise + Atmosphere：要求評論、停車選項、是否可訂位、餐飲服務等更豐富的「場所體驗」資料。
Nearby Search Pro：依 GPS 搜尋附近地點；Nearby Search 本身的搜尋結果欄位會決定實際層級。

Geocoding 也有自己的 SKU：Geocoding。例如照片只有 GPS 座標，程式呼叫 Reverse Geocoding 將座標轉成國家、城市與地址時，這次可計費事件就會累積在 Geocoding SKU。

所以在 Google Cloud Billing 裡看到「Geocoding、Autocomplete Requests、Nearby Search Pro、Place Details Pro、Place Details Enterprise」同時出現，並不代表使用了五個完全無關的系統，而是網站不同功能觸發了不同的計費品項。

Google Maps Platform、Google Cloud 與 Gemini API 的差異

Geocoding API 與 Places API (New) 都屬於 Google Maps Platform，通常在 Google Cloud Console 中建立專案、啟用 API、建立 API Key，並綁定 Cloud Billing 帳戶。Google Maps Platform 採 pay-as-you-go：不同功能觸發不同 SKU，再依每月可計費事件數量計算費用。

Gemini API 也不能和一般使用者在 Gemini 聊天介面中的訂閱方案混為一談。如果自己寫的程式、WordPress 外掛或網站需要呼叫 Gemini 的 AI 功能，必須另外使用 Gemini API，取得 API Key，並依 API 的模型與實際使用量計費。Gemini API 常見的計費基礎是輸入／輸出 Token，以及圖片、音訊等不同媒體的用量，而不是「每月付一筆訂閱費後，任何網站都可以無限呼叫」。

這個差異其實很合理。假設一個人訂閱 Gemini 聊天介面後，就能把同一份 API Key 放到公開網站，讓全世界訪客無限制使用 AI，最後卻只付一個人的月費，那麼一份個人訂閱等於可以供無限多人共同使用，商業模式當然無法成立。因此聊天產品的月費方案與程式開發用的 API 用量，是兩套不同的服務與計費邏輯。

也因此，只要網站使用付費 Gemini API，就不能把 API Key 寫在前端 JavaScript 或 HTML 讓訪客看到，也不應讓任何匿名訪客可以無限制呼叫。正確做法是由自己的後端伺服器保存 API Key，並加上登入權限、速率限制（rate limit）、每日／每月使用上限等保護。否則別人濫用網站 AI 功能時，API 用量與費用仍會計入網站擁有者的帳戶。

Google Maps Platform 也有類似概念：正式付費帳戶的免費額度用完後，不一定會自動停止服務。若沒有另外設定 API quota、Budget Alert 或應用程式自己的限制，背景程式仍可能繼續產生可計費 request，之後才從 Cloud Billing 看見費用增加。

最大的差異是Gemini API跟OpenAI API都是屬於預先儲值（最低消費：Gemini是400台幣，而OpenAI是5美金），額度扣完可以選擇要不要自動加值，而Google Maps Platform屬於Google Cloud的一部分，是事後結算，所以額度較容易過量。

Google Cloud 新帳戶的免費試用與每月免費額度

符合資格的 Google Cloud 新客戶目前可獲得 US$300 Welcome Credit，有效期約 90 天。這筆額度可用於多種 Google Cloud 服務，但免費試用與 Google Maps Platform 每個 SKU 的「每月免費使用量」是兩件不同的事。

Google Maps Platform 自 2025 年起改為每個 SKU 都有自己的免費用量門檻。常見概念可以簡化成：

類別	常見每月免費用量	例子
Essentials	10,000 次	Geocoding、Autocomplete Requests、Place Details Essentials
Pro	5,000 次	Nearby Search Pro、Place Details Pro
Enterprise	1,000 次	Place Details Enterprise、Nearby Search Enterprise

也就是說，「一個月有 10,000 次免費」與「一個月只有 1,000 次免費」都可能是正確的，關鍵在於你的程式實際觸發哪個 SKU。

Geocoding API：把 GPS 轉成國家、城市與地址

如果照片 EXIF 只有經緯度，例如：

Latitude: 47.074
Longitude: 12.694

可以透過 Reverse Geocoding 取得國家、城市、行政區、郵遞區號、道路等地址資訊。這非常適合照片匯入時，自動建立：

國家
城市或行政區
較粗略的地理位置

Geocoding 屬於 Essentials，官方目前列出的免費用量為每月 10,000 次，超過後第一個價格級距約為每 1,000 次 US$5。

最重要的省費做法是：查一次就把結果存進自己的資料庫。國家、城市與座標不會因為有人重新開啟照片頁就改變，所以完全沒有必要每次瀏覽照片都重新呼叫 Reverse Geocoding。

Places API (New)：從 GPS 找出真正的景點與 POI

Geocoding 很適合回答「這個座標屬於哪裡」，但不一定知道攝影者真正拍的是什麼。照片可能位於某個山區、湖邊或景點附近，Geocoding 只回傳一條道路或行政區名稱，此時就需要 Places API。

Places API (New) 可以根據 GPS 搜尋附近 POI，例如：

觀景台
國家公園
城堡與博物館
湖泊、山區設施
纜車站
旅遊景點

因此照片管理系統很適合採用「Geocoding 先取得國家與城市，再用 Nearby Search 找細節景點」的兩層式流程。

「先享受後付款」的計費帳單，一開始功能能實現很興奮，過了一個月看到帳單就笑不出來了。

Autocomplete：每打一個字都查，和按一次搜尋，費用差很多

Autocomplete 最容易讓 API 用量失控。典型的即時搜尋介面可能在使用者輸入：

M
Mo
Mon
Mont
Montr
Montre
Montreu
Montreux

每次字串改變就送一次 API request。使用者只是搜尋一次「Montreux」，實際上卻可能送出 8 次 Autocomplete requests。

如果不使用 session，官方的 Autocomplete Requests 會以每個 request 個別計費。目前每月免費 10,000 次，超過免費額度後第一個價格級距約為每 1,000 requests US$2.83。

對管理後台而言，其實不一定需要「每打一個字就即時查」。比較省費的設計是：

輸入至少 2 個字。
輸入文字的過程不自動搜尋，所以繼續輸入第 3、4、5 個字不會增加 request。
使用者只有在按一次放大鏡時，才送出 1 次 Autocomplete request。
這 1 次 request 可以一次列出多個候選結果，例如 5 筆或 10 筆。

一次 Autocomplete 回傳 5 筆或 10 筆候選，不會因此變成 5 次或 10 次計費。計費單位是 API request，而不是畫面顯示幾筆候選。

Autocomplete Session、Pro 與 Enterprise 的計費差異

Autocomplete (New) 可以使用 sessionToken，把使用者從開始輸入到最後選定地點的過程視為同一個 session。但 session 並不代表「不管輸入幾個字，整個欄位永遠只算一筆」；實際費用取決於最後用什麼方式結束這個 session。

情境 A：不用 session，按一次搜尋才查一次

假設每次成功選一個地點，只送：

Autocomplete × 1
Place Details Pro × 1

當免費額度都已使用完，以目前第一個價格級距估算，每 1,000 次成功選地點約為：

Autocomplete Requests：US$2.83
Place Details Pro：US$17
合計：約 US$19.83 / 1,000 次成功選地點

而且免費額度分別是 Autocomplete 10,000 次與 Place Details Pro 5,000 次。對「按搜尋按鈕才查一次」的後台介面而言，這種做法非常有優勢。

情境 B：不用 session，但每打一個字都查

假設平均每次成功選地點前會產生 8 次 Autocomplete：

Autocomplete × 8
Place Details Pro × 1

免費額度用完後，每 1,000 次成功選地點約為：

8 × US$2.83 + US$17
= 約 US$39.64

這種「使用者每輸入一個字，畫面就立即重新搜尋候選地點」的即時自動完成介面（常稱為 type-ahead）就會明顯放大 Autocomplete requests。

情境 C：使用 sessionToken，最後以 Place Details Essentials 結束

若最後只取得地址、座標、types 等 Essentials 資訊，官方目前的 session pricing 是：同一 session 前 12 個 Autocomplete requests 仍按 Autocomplete Requests 計費，第 13 個之後才屬於免費的 Autocomplete Session Usage，另外再計一次 Place Details Essentials。

情境 D：使用 sessionToken，最後要求 Pro 或 Enterprise 等級 Place Details

這是最需要注意的地方。若 Autocomplete session 最後用 Place Details (New) 結束，而且要求到 Pro、Enterprise 或 Enterprise + Atmosphere 的欄位，該 session 內的 Autocomplete requests 會歸入免費的 Autocomplete Session Usage；但是用來結束 session 的那一次 Place Details，官方目前規定會以 Place Details Enterprise + Atmosphere SKU 計費，不論實際只用了 Pro 還是更高階欄位。

因此若每次搜尋本來就只有 1 次 Autocomplete，使用 sessionToken 反而可能從：

Autocomplete + Place Details Pro
≈ US$19.83 / 1,000 次

變成：

Autocomplete Session Usage：US$0
Place Details Enterprise + Atmosphere：US$25 / 1,000 次

但如果你的介面真的每次都會產生很多次 Autocomplete requests，sessionToken 才可能重新變得有利。重點不是「session 一定比較省」，而是要看每次使用者操作到底會送出幾次 request，以及 session 最後用哪一級 Place Details 結束。

Field Mask 是什麼？為什麼它會直接改變 API 費用？

Field Mask（欄位遮罩／欄位清單）不是一種額外 API，而是你在呼叫 Places API 時附上的「我要哪些資料」清單。可以把 Places API 想成一份很大的地點資料庫：同一個景點可能同時有名稱、地址、座標、電話、網站、營業時間、評分、評論、停車資訊等幾十種資料。程式通常不需要全部拿回來，因此要用 Field Mask 告訴 Google「這次只回傳我真正需要的欄位」。

它同時也是計費的重要依據。Google 會檢查這份清單中最高價的欄位屬於哪一級 SKU；例如同一次 request 同時要求 Essentials 與 Enterprise 欄位，整次 request 就按照 Enterprise 層級計費。

Field Mask 可以把它想成「向 Google 點餐時，勾選你要 Google 回傳哪些資料」。

Places API 不會假設你需要所有資訊。程式必須明確告訴 Google：「我要名稱、地址、座標」，或「我還要評分、電話、網站、營業時間」。這份欄位清單就是 Field Mask。

例如：

X-Goog-FieldMask: displayName,formattedAddress,location

代表只要求：

地點名稱
格式化地址
GPS 座標

但如果再要求：

rating,websiteUri,currentOpeningHours

Google 就會認為這次 request 不只是基本地點資訊，而是需要更高階的商家資料，SKU 也可能從 Pro 提升到 Enterprise。

Atmosphere 是什麼？

Google 在 Places API 中所說的 Atmosphere，可以理解成「這個場所的體驗、特色與服務資訊」，而不只是「它在哪裡」。例如地址與座標是在描述地點本身；但使用者評論（reviews）、是否可訂位（reservable）、停車選項（parkingOptions）、是否提供外帶／內用，以及餐廳供應哪些餐別等，則是在描述到訪這個場所時的體驗與服務，因此被歸在較高階的 Atmosphere 類資料。

對照片相簿來說，大多數 Atmosphere 資料其實沒有必要。照片地點管理通常只需要「這是哪裡、地址是什麼、座標在哪、屬於哪一類景點」，因此若沒有特殊需求，就不應為了顯示候選地點而要求評論、訂位、停車或餐飲服務等欄位。

Place Details (New) 的例子

想取得的資料	代表欄位	可能觸發的 SKU	免費月額度
地址、座標、類型	formattedAddress、location、types	Essentials	10,000
真正可閱讀的地點名稱	displayName	Pro	5,000
評分、網站、電話、營業時間	rating、websiteUri、phone、openingHours	Enterprise	1,000
評論、停車選項、餐飲服務等	reviews、parkingOptions 等	Enterprise + Atmosphere	1,000

也就是說，只要一個 request 裡勾到較高級的欄位，整次 request 就會依較高的 SKU 計價。所以正式環境不應直接使用：

X-Goog-FieldMask: *

因為這相當於「所有資料都給我」，除了傳回大量不需要的資訊，也可能直接把請求推到更昂貴的層級。

Nearby Search：找附近景點時怎麼避免費用暴增

Nearby Search 很適合用 GPS 找照片附近的景點，但它本身就是 Pro 起跳。目前 Nearby Search Pro 每月免費 5,000 次，超額後第一個價格級距約為每 1,000 次 US$32；Nearby Search Enterprise 則每月免費 1,000 次，第一個價格級距約 US$35 / 1,000 次；Enterprise + Atmosphere 則約 US$40 / 1,000 次。

最容易浪費費用的流程是：

1 次 Nearby Search
→ 回傳 10 個候選景點
→ 對 10 個候選各呼叫 1 次 Place Details

這樣使用者只是查一次附近景點，後端卻可能產生：

Nearby Search × 1
Place Details × 10

比較好的方式是讓 Nearby Search 本身直接回傳：

displayName
formattedAddress
location
types / primaryType
Place ID

這些資料已經足夠顯示候選清單。等使用者真的挑中某一個景點後，才針對那一筆視需要呼叫 Place Details。

GPS 回查景點時，排除停車場、加油站等低價值 POI

照片 GPS 附近往往存在很多對攝影相簿沒有意義的 Places，例如加油站、停車場、充電站、洗車場或休息站。如果只是把「距離最近」的 Place 當成照片地點，很容易得到錯誤或很難看的結果。

Nearby Search (New) 支援 excludedTypes 與 excludedPrimaryTypes，可以在搜尋階段直接排除不希望出現的地點類型。例如攝影相簿可以考慮排除：

gas_station
parking
parking_lot
parking_garage
electric_vehicle_charging_station
car_wash
car_repair
rest_stop

Google 的 Place Types 文件明確將這些列為可用於 Nearby Search 篩選的類型。實際排除清單可以依網站需求調整；例如自駕旅遊網站可能反而會想保留停車場，但攝影網站通常更希望優先顯示觀景台、國家公園、城堡、湖泊、歷史景點或旅遊景點。

另外，GPS Reverse Geocoding 偶爾可能只得到道路名稱或沒有實際意義的文字。如果回傳的是類似「Unnamed Road」這種內容，不應把它當成真正景點名稱。比較合理的策略是：

先用 Geocoding 保存國家、城市與行政區。
若需要細節地點，再用 Nearby Search 找 POI。
排除低價值類型。
依距離、類型與名稱品質排序候選。
真的找不到合理景點時，寧可只保存城市或行政區，也不要硬塞一個「Unnamed Road」。

照片網站最省費的 API 流程

以照片相簿管理為例，我認為最合理的流程是：

照片第一次匯入

EXIF GPS
→ Reverse Geocoding
→ 國家 / 城市 / 行政區
→ 寫入自己的資料庫

需要找附近景點時

GPS
→ Nearby Search Pro
→ 排除停車場、加油站等低價值類型
→ 只要求必要 Field Mask
→ 一次顯示多個候選
→ 使用者選定後保存

人工搜尋地點時

輸入至少 2 個字
→ 按搜尋按鈕
→ Autocomplete × 1
→ 顯示最多 10 個候選
→ 使用者選定
→ 必要時 Place Details × 1
→ 寫入資料庫

這種設計有三個很重要的特性：不逐字搜尋、不逐候選查 Place Details、查過的資料不重複向 Google 查詢。

實作心得：幾個最值得注意的省費原則

先算 request 次數，不要只看單價。使用者做一次操作，程式可能在背景產生 1 次、8 次甚至數十次 API request。
Autocomplete 若不需要即時提示，就改成按搜尋按鈕才查。一次 request 就可以取得多筆候選。
候選筆數不等於計費次數。一次 Autocomplete 回傳 10 個候選，仍然是一個 request。
Field Mask 只拿真正需要的資料。不要為了方便使用 *，也不要無意間要求 rating、websiteUri、opening hours、reviews 等高階欄位。
Nearby Search 不要對每個候選再查一次 Place Details。先用 Nearby Search 回傳的基本資料完成候選清單，真的選中才查 Details。
利用 excludedTypes / excludedPrimaryTypes 過濾低價值 POI。對照片相簿來說，停車場、加油站、充電站等通常不是理想的照片地點名稱。
所有穩定結果都存自己的資料庫。國家、城市、景點、座標等不需要每次開啟照片都向 Google 重新查詢。
設定 Google Cloud Budget Alert 與 API Quota。免費額度不是自動停用門檻，正式付費帳戶超額後仍會繼續累積費用。

Google Maps Platform 對照片管理非常實用，但真正決定成本的往往不是「某支 API 一次多少錢」，而是程式設計是否讓同一個操作產生了過多 request，以及是否不小心要求到高階資料欄位。只要把 Geocoding、Places、Autocomplete、Nearby Search 與 Place Details 分工清楚，再配合 Field Mask、快取與候選過濾，小型個人相簿網站通常可以把 API 用量控制在相當合理的範圍內。

參考資料

Google Maps Platform 與 Gemini API 的價格、免費額度及 SKU 規則可能調整；實際開發與上線前，應再以 Google 官方最新價格表與 Billing 文件為準。

延伸閱讀：攝影網站建置學習順序

這篇文章已有 42 次瀏覽