I'm using the JavaScript API, but can't seem to get it to behave with the CURL API either.
Problem: I would like to limit my geocoding results by county + state. Google Maps geocoding API component filtering is no longer recognizing an administrativeArea in the format "San Mateo County, CA" (worked previously), and isn't recognizing "San Mateo County" even though it is definitely an administrative_area_level_2 according to the results object.
For example, "https://maps.googleapis.com/maps/api/geocode/json?address=oakland&components=country:US|administrative_area:San+Mateo+County&key=YOUR_KEY_HERE" returns a result for Oakland even though it's in Alameda County, not San Mateo County. Using "San Mateo County, CA" is completely ignored as well. Doing components=country:US|administrative_area:San+Mateo+County|adminstrative_area:CA similarly doesn't work (and isn't possible as far as I know with the JS API anyways).
(The ultimate usecase is handling results when the address that's geocoded isn't actually a location, e.g. "Homeless", which used to return an error code but recently started returning "United States", in part because the component filtering appears to have changed.)
If you want to futz with the API, here's a JS fiddle to allow that: https://jsfiddle.net/Lzj1uvfd/
There was a change in the components filtering of Geocoding API back in January 2018. After this change only postal code and country filters work as a strict filter, route, locality and admin area are not strict filters and just influence results.
Google sent notification about this change to the Premium plan customers. I'm sharing a copy of this email here
Hello Maps APIs Premium Plan customer,
Upcoming quality improvements in Google Maps geocoding services will require that the Component Filtering feature of the Geocoding API become less restrictive. This will become effective on January 16, 2018.
In the meantime, we are exposing a test parameter on the Geocoding API web service, so that you can see whether this change will affect your geocoding requests utilizing the Component Filtering feature. To use the parameter, add relax_components=true to your requests.
This test parameter will be available through January 16, 2018. After that date the parameter will be ignored, but requests using the parameter will still be accepted. There is no JavaScript equivalent.
The quality improvements will provide higher quality results for requests that seek to find valid addresses. However, the following statements will not longer apply to the Component Filtering feature: A query containing a component filter only returns the geocoding results that match the filter. If no matches are found, the geocoder returns a result that matches the filter itself. Component filtering will return a ZERO_RESULTS response only if you provide filters that exclude each other.
Filters for postal codes and country codes will continue to be enforced strictly for all queries.
Examples
An address that is not strictly contained by the locality filter (Spring Valley, NV), but it is near (in Paradise, NV), will be found instead of a less specific result matching the locality filter exactly:
Example request #1: address=4755+W+Flamingo+Rd&components=locality:Spring+Valley|country:US Current result: "W Flamingo Rd, Spring Valley, NV, USA" (route, partial_match) Future result: "4755 W Flamingo Rd, Las Vegas, NV 89103, USA" (premise)
A result in the different locality may be returned, instead of ZERO_RESULTS, when the locality filter would otherwise form a non-existent address:
Example request #2: components=locality:Montreal+Lake+Reserve|administrative_area:Saskatchewan|country:CA Current result: ZERO_RESULTS Future result: "Montreal Lake, SK S0J 1Y0, Canada" (establishment)
Example request #3: components=country:US|locality:friends+creek+conservation+area+cisco|administrative_area:IL Current result: ZERO_RESULTS Future result: "Friends Creek Conservation Area, 13734 Friends Creek Park Rd, Cisco, IL 61830, USA" (park)
Mutually exclusive filters no longer guarantee ZERO_RESULTS. This has been already the case since the old forward geocoder was permanently retired on April 3, 2017. The upcoming change will make this happen more often, e.g. when the administrative_area filter is favoured over the locality filter:
Example request #4: address=Müslistrasse+16&components=locality:Spreitenbach|administrative_area:ZH|country:CH Current result: ZERO_RESULTS Future result: "Muslistrasse 16, 8820 Wädenswil, Switzerland" (street_address)
An invalid address that was never found will no longer yield a result that matches the filter itself. This may result in either ZERO_RESULTS or one or more valid addresses that match some of the filters.
Example request #5: address=13+Rue+del+Percebe&components=locality:Sydney|country:AU Current result: "Sydney NSW 2000, Australia" (locality) Future result: ZERO_RESULTS
Example request #6: address=Sesame+St&components=locality:Sydney|country:AU Current result: "Sydney NSW 2000, Australia" (locality) Future result: "Sesame St, Mount Waverley VIC 3149, Australia" (route) and 2 more
In rare cases, a valid address may no longer be found for a given value of filters.
Example request #7: address=Fuerteventura&components=locality:Almeria|administrative_area:AL|country:ES Current result: "Calle Isla de Fuerteventura, 04007 Almería, Spain" (route) Future result: ZERO_RESULTS
Regards, The Google Maps API Team
I hope this information helps!