IssueTracker

When using the Google Address Validation API, an input address like:
"1020 North Grand Avenue Nogales AZ 85621"

returns the formatted address as:
"1020 North Grand Avenue, Nogales, AZ 85621-1363, USA"

However, when this formatted address is passed to the Google Geocoding API, the results array contains two entries:

First Entry (Index 0 - Less Accurate)

Formatted Address: "Nogales, AZ 85621, USA"
Location Type: APPROXIMATE (City-Level Match)
Place Type: Locality / Political
Second Entry (Index 1 - More Accurate)

Formatted Address: "1020 N Grand Ave, Nogales, AZ 85621, USA"
Location Type: ROOFTOP (Exact Address Match)
Place Type: Premise / Street Address
The expected behavior is that the ROOFTOP result, which provides the most precise location, should be ranked first (index 0). However, the APPROXIMATE result, which represents a broader, city-level match rather than the exact address, is incorrectly ranked first.

This issue is not limited to a specific address but can occur with other locations where a more precise address match (ROOFTOP or STREET_ADDRESS) is available but ranked lower in the response.

Impact:
Applications relying on the Google Geocoding API may incorrectly use the less precise APPPROXIMATE result, leading to inaccurate location data.
This affects geolocation-based services, address verification, and automated workflows that expect the most accurate match to be returned first.
Expected Behavior & Resolution Request:
The Geocoding API should consistently prioritize precise address-level matches (ROOFTOP or STREET_ADDRESS) over broader, approximate location matches (APPROXIMATE or LOCALITY).
This should be resolved generically across all locations, not just for specific addresses like "North Grand Avenue, Nogales, AZ 85621".
We request you to review and adjust the ranking logic in the Geocoding API to ensure that the most accurate match is always returned as the first result.

Thank you