Trying Out the New Features of Amazon Location Service Places: "Multilingual Addresses," "Travel Mode Optimization," and More

Introduction

On July 10, 2026, several new features were added to the Places API of Amazon Location Service.

https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-location-service-enhanced-address-search

This article summarizes the main features added in this update by comparing them with the previous version.

The support status of the new parameters and response attributes verified in this article is as follows.

• The "✓" for TravelMode indicates that the parameter can be specified. The effect on results varies depending on the API and search conditions. AddressNamesMode can also be used with ReverseGeocode.

Verification environment

• AWS CLI v2 (aws geo-places subcommand)
• Region: ap-northeast-1 (Tokyo)
• Authentication: IAM (geo-places:* permission)
• IntendedUse: SingleUse (if you want to store results permanently, you need to specify Storage)

AddressTranslations — Multilingual address translation

With --address-translations, you can retrieve multilingual variations of the specified address components in a single request. The components you can specify are the four types District, Locality, Region, and SubRegion (all can be specified at the same time).

We geocode the address of Hibiya Fort Tower (1-1-1 Nishishimbashi, Minato-ku, Tokyo) and retrieve translations for Locality (city/ward) and Region (prefecture).

aws geo-places geocode \
  --query-text "東京都港区西新橋1-1-1 日比谷フォートタワー" \
  --language ja \
  --address-translations Locality Region \
  --region ap-northeast-1 \
  --no-cli-pager \
  --output json

The multilingual variations of each component are returned in the Translations field of the response.

Here are the main ones excerpted from the translations of Locality (Minato Ward).

Translations for Region (Tokyo Metropolis) are returned in the same format.

{
  "Translations": {
    "Locality": [
      {
        "Names": [
          {"Value": "港区", "Language": "ja", "Type": "BaseName", "Primary": true},
          {"Value": "港", "Language": "ja", "Type": "Synonym"},
          {"Value": "みなとく", "Language": "ja-Hira", "Type": "Exonym"},
          {"Value": "みなと", "Language": "ja-Hira", "Type": "Exonym"},
          {"Value": "ミナトク", "Language": "ja-Kana", "Type": "Exonym"},
          {"Value": "ミナト", "Language": "ja-Kana", "Type": "Exonym"},
          {"Value": "Minatoku", "Language": "ja-Latn", "Type": "BaseName", "Primary": true, "Transliterated": true},
          {"Value": "Minato", "Language": "ja-Latn", "Type": "Synonym", "Transliterated": true},
          {"Value": "Minato-ku", "Language": "en", "Type": "Exonym"},
          {"Value": "Minato City", "Language": "en", "Type": "Exonym"},
          {"Value": "Minato Ward", "Language": "en", "Type": "Exonym"},
          {"Value": "Minato", "Language": "en", "Type": "Exonym"},
          {"Value": "미나토구", "Language": "ko", "Type": "Exonym"},
          {"Value": "미나토", "Language": "ko", "Type": "Exonym"},
          {"Value": "港区", "Language": "zh", "Type": "Exonym"},
          {"Value": "港", "Language": "zh", "Type": "Exonym"},
          {"Value": "港區", "Language": "zh-Hant", "Type": "Exonym"},
          {"Value": "港", "Language": "zh-Hant", "Type": "Exonym"}
        ],
        "Preference": "Primary"
      }
    ],
    "Region": [
      {
        "Names": [
          {"Value": "東京都", "Language": "ja", "Type": "BaseName", "Primary": true},
          {"Value": "東京", "Language": "ja", "Type": "Synonym"},
          {"Value": "とうきょうと", "Language": "ja-Hira", "Type": "Exonym"},
          {"Value": "とうきょう", "Language": "ja-Hira", "Type": "Exonym"},
          {"Value": "トウキョウト", "Language": "ja-Kana", "Type": "Exonym"},
          {"Value": "トウキョウ", "Language": "ja-Kana", "Type": "Exonym"},
          {"Value": "Toukyouto", "Language": "ja-Latn", "Type": "BaseName", "Primary": true, "Transliterated": true},
          {"Value": "Toukyou", "Language": "ja-Latn", "Type": "Synonym", "Transliterated": true},
          {"Value": "Präfektur Tokio", "Language": "de", "Type": "Exonym"},
          {"Value": "Tokio", "Language": "de", "Type": "Exonym"},
          {"Value": "Tokyo", "Language": "en", "Type": "Exonym"},
          {"Value": "Tokyo Prefecture", "Language": "en", "Type": "Exonym"},
          {"Value": "도쿄도", "Language": "ko", "Type": "Exonym"},
          {"Value": "도쿄", "Language": "ko", "Type": "Exonym"},
          {"Value": "东京都", "Language": "zh", "Type": "Exonym"},
          {"Value": "东京", "Language": "zh", "Type": "Exonym"}
        ],
        "Preference": "Primary"
      }
    ]
  }
}

The main attributes confirmed in this response are as follows.

• Type: BaseName (base name), Synonym (alternative name), Exonym (exonym: a name in another language/notation). In addition, Abbreviation (abbreviation), Shortened (shortened form), etc. may also be returned
• Transliterated: When true, it indicates that the conversion is by transliteration
• Primary: The entry with true is the preferred notation in that language

We also tried a Berlin address. For Region (Berlin), translations in German, English, French, Chinese, Japanese (Berlin in katakana), Arabic, and others were returned.

It works the same way for a Vancouver address. For Region (British Columbia), French (Colombie-Britannique), Spanish (Columbia Británica), Chinese (the Chinese name of British Columbia), and others were returned.

AddressNamesMode — Controlling address name display

The --address-names-mode parameter was added to the Geocode API and the GetPlace API. In the Geocode API, you can control whether the names of address components (Locality, etc.) are returned as normalized names, names matching the input, or official administrative names. It can also be used with the GetPlace API, but as of now the only valid value in the API reference is Administrative.

We check the difference using Brooklyn in New York City. Brooklyn is administratively part of New York City (a borough), but as an address it is generally written as "Brooklyn, NY".

We deliberately enter an address in the Park Slope neighborhood of Brooklyn as "New York, NY" and check whether Matched mode returns a place name that matches the input text.

aws geo-places geocode \
  --query-text "350 5th Av, New York, NY" \
  --language en \
  --address-names-mode Matched \
  --region ap-northeast-1 \
  --no-cli-pager \
  --output json

These are the results of switching the --address-names-mode value between omitted (Default) / Matched / Administrative. The PlaceId and coordinates [-73.98423, 40.67199] are the same in all modes; only Locality and Title change.

TravelMode — Optimizing results by travel mode

When you specify a means of travel with --travel-mode, the relevance of search results is adjusted taking the travel mode into account. We search for "gas station" near Tokyo Station to check the effect.

This is an example command with --travel-mode Car added.

aws geo-places suggest \
  --query-text "ガソリンスタンド" \
  --bias-position "[139.7671,35.6812]" \
  --travel-mode Car \
  --language ja \
  --region ap-northeast-1 \
  --no-cli-pager \
  --output json

We compare it with the case where --travel-mode is omitted.

The Suggest API returns not only POIs (store names) but also category candidates (QueryType=Category). Regardless of whether TravelMode is specified, the category candidate "gas station" is returned in first place, so we compare the POI results from second place onward.

When Car is specified, Irifune-Sakuragawa SS (Irifune, Chuo-ku), which was in 4th place without TravelMode, falls out of the top 5, and apollostation Hongo SS (Hongo, Bunkyo-ku) enters the top ranks instead. The relevance adjustment by TravelMode is considered to be affecting the order of results.

DriveThrough attribute and FoodTypes/Categories filters

DriveThrough attribute

We check in the US and Japan whether DriveThrough is included in PlaceAttributes in the response.

We search for McDonald's in Dallas, Texas, USA.

aws geo-places search-text \
  --query-text "McDonald's" \
  --bias-position "[-96.797,32.7767]" \
  --language en \
  --max-results 5 \
  --region ap-northeast-1 \
  --no-cli-pager \
  --output json

{
  "Title": "McDonald's",
  "Address": {
    "Label": "McDonald's, 1000 Commerce St, Dallas, TX 75202-3716, United States"
  },
  "Categories": [{"Id": "fast_food", "LocalizedName": "Fast Food"}],
  "FoodTypes": [
    {"Id": "fast_food", "LocalizedName": "Fast Food"},
    {"Id": "burgers", "LocalizedName": "Burgers"}
  ],
  "PlaceAttributes": ["DriveThrough"]
}

PlaceAttributes: ["DriveThrough"] is returned.

On the other hand, when searching for McDonald's in Japan (using its Japanese name), DriveThrough could not be confirmed in PlaceAttributes, even in results that include drive-through-capable stores (such as the Yoga Interchange store).

aws geo-places search-text \
  --query-text "マクドナルド" \
  --bias-position "[139.7671,35.6812]" \
  --language ja \
  --max-results 5 \
  --region ap-northeast-1 \
  --no-cli-pager \
  --output json

In this verification, the DriveThrough attribute was confirmed in US search results. On the other hand, in Japan, even for searches that include drive-through-capable stores, DriveThrough could not be confirmed in PlaceAttributes.

FoodTypes/Categories filters — Rich category data in Japan too

The DriveThrough attribute could not be confirmed in Japan in this verification, but the FoodTypes filter worked for locations in Japan as well. We search for burger restaurants near Yoga Station using the FoodTypes filter.

aws geo-places search-nearby \
  --query-position "[139.6333,35.6264]" \
  --max-results 10 \
  --filter '{"IncludeFoodTypes": ["burgers"]}' \
  --language ja \
  --region ap-northeast-1 \
  --no-cli-pager \
  --output json

Freshness Burger, MOS Burger, McDonald's Yoga Interchange store, Shake Shack, and others were hit.

In a search specifying japanese-ramen near Nakano Station, "Dotonbori Kamukura Nakano Sun Mall store", "Hidakaya Nakano store", and others are hit.

aws geo-places search-nearby \
  --query-position "[139.6659,35.7074]" \
  --max-results 10 \
  --filter '{"IncludeFoodTypes": ["japanese-ramen"]}' \
  --language ja \
  --region ap-northeast-1 \
  --no-cli-pager \
  --output json

Even within the range confirmed in the verification, detailed Japanese-cuisine subcategories were provided.

• japanese-ramen (ramen)
• japanese-sushi (sushi)
• japanese-sushi_train (conveyor-belt sushi)
• japanese-izakaya (izakaya)
• japanese-yakiniku (yakiniku)
• japanese-yakitori/chicken (yakitori)
• japanese-tonkatsu (tonkatsu)
• japanese-udon/other_noodles (udon and other noodles)
• japanese-rice_bowl (rice bowl dishes)
• japanese-curry (curry)

Notes when specifying filters

The value passed to the filter must be specified by FoodTypes ID. Specifying by LocalizedName (Japanese name) results in a ValidationException. Available FoodTypes IDs can be checked in the FoodType list in the API reference.

# ❌ Specifying in Japanese → ValidationException
--filter '{"IncludeFoodTypes": ["ラーメン"]}'

# ✓ Specifying the FoodTypes ID
--filter '{"IncludeFoodTypes": ["japanese-ramen"]}'

On the other hand, when --language ja is specified, the LocalizedName in the response is returned in Japanese ("Japanese Food - Ramen", "Burgers", etc., in Japanese). The specification is asymmetric: the filter input is the FoodTypes ID, while the display name in the response is in the specified language.

Category distribution by area

By specifying --query-radius 3000 (3 km) to widen the SearchNearby search range, you can see that the category distribution differs depending on the area.

In this verification, the area near Nakano Station had high dining diversity, with izakaya, conveyor-belt sushi, and various international cuisines appearing, while the area near Yoga Station was dominated by daily-life infrastructure categories such as police boxes, post offices, and dry cleaners.

Summary

We verified the new features added to the Amazon Location Service Places API using the AWS CLI.

With AddressTranslations, we confirmed that multilingual notations in Japanese, English, Korean, Chinese, German, and more can be retrieved for each address component in a single request. With AddressNamesMode, using a Brooklyn address as an example, we confirmed that the notation of Locality and Title changes depending on the difference between Default / Matched / Administrative.

TravelMode can be used in Suggest and SearchText to adjust the relevance of search results taking the travel mode into account. In this verification, we were able to confirm ranking differences with the Suggest API in a gas station search near Tokyo Station.

The DriveThrough attribute was confirmed in US search results but not in search results in Japan. On the other hand, the FoodTypes filter and Categories in the response are usable for locations in Japan as well, and multiple Japanese-cuisine subcategories were confirmed.

With multilingual address display, control of address name display, search that considers travel mode, and restaurant category search, this was an update that lets you handle the search and display aspects of the Places API more flexibly.

Reference links

https://docs.aws.amazon.com/location/latest/APIReference/API_Operations_Amazon_Location_Service_Places_V2.html

https://docs.aws.amazon.com/location/latest/APIReference/API_geoplaces_Geocode.html

https://docs.aws.amazon.com/location/latest/APIReference/API_geoplaces_Suggest.html

https://docs.aws.amazon.com/location/latest/developerguide/places.html

https://aws.amazon.com/location/pricing/