[Resolved] Geocode on address field returns "natural_feature" instead of "locality"

[Author]

Posts

[Steve Palm]

Tell us what you are trying to do?

We are trying to capture an address, even if partial, using an address type field on a post form. However, if the user inputs only a partial address sometimes Google is returning a "natural_feature" instead of a "locality" or other address type information. For example, inputting "Black Hills, SD" returns not the city Black Hills, but rather the natural_feature "Black Hills".

Is there a way to provide guidance or limitations to the Google geocode so that it ONLY returns actual city type results?

Is there any documentation that you are following?

Standard documentation.

What is the link to your site?

hidden link

[Waqar]

Hi,

Thank you for contacting us and I'd be happy to assist.

I've performed some tests on my website and I was able to restrict the autocomplete suggestions in the form's address field, to only cities in the United States, by adding the following script in the form's "JS editor":

function initialize() {
	var input = document.getElementsByClassName('toolset-google-map');
	options = {
		types: ['(cities)'],
		componentRestrictions: { country: "us" }
	};

	var autocomplete = new google.maps.places.Autocomplete(input[0],options);
}

jQuery(document).ready(function($){
	jQuery( "input.toolset-google-map" ).change(function() {
		initialize();
	});
	jQuery( "input.toolset-google-map" ).focus(function() {
		initialize();
	});
	jQuery( "input.toolset-google-map" ).click(function() {
		initialize();
	});
});

Note: The custom code examples from our forum are shared to get you started in the right direction. You're welcome to adjust them as needed and for more personalized customization assistance, you can consider hiring a professional from our list of recommended contractors:
https://toolset.com/contractors/

regards,
Waqar

[Steve Palm]

I will try this, but it sure looks like it is the right direction. Thank you very much for your help.

[dougS-3]

{wrong user sorry}

[Steve Palm]

Actually, this did not work.

For example, the following is still returning the "place" not the "city":

Black Hills, SD, USA

I will see if I can work with what you have given, but any other ideas would be appreciated. I inserted the JS on the post form editing screen box, and when viewing the page I can see it was injected.

If I set a breakpoint on the initialize(), or even when it is called as part of the jQuery statements on change/focus/click, the debugger doesn't catch them or stop there. Maybe this is normal, I don't know, but I can't see that the changing of options is ever happening.

If I set a breakpoint on the jQuery() calls inside the .ready() call, I do get a break there.

[Steve Palm]

{duplicate post}

For some reason when I edited the above post, even after refreshing a few times, it didn't show up. But after adding this second comment the first one did. Strange, sorry for the noise.

I also found that I needed to set "Preserve Log" in the browser debugger to make the breakpoints remain after a page refresh, and now I see the call being handled, but I have no answer as to why it doesn't seem to be changing anything. But I don't know enough about this level of interaction with the Google or Toolset components.

But even with this in place, I can also still input "Paris, France" and have it work, so it is not only not limiting it to cities, but not to the US. We eventually don't want the US limit, but it is good to test to see that even that is not working.

[Steve Palm]

Sorry for all the posts, but wanting to add any detail that might help.

In using the USPS toolset to find a zipcode, they don't return anything for "Black Hills, SD" so that particular case may not have an actual location of type city or region. That actually makes it a great test case, because if the autocomplete is properly restricted it should not suggest that as an option.

[Steve Palm]

Actually, it seems that your code is trying to do the right thing... I had changed (cities) to (regions) as I thought it better fit our needs, but it didn't change the results in any meaningful way.

I do see by looking at network traffic, though, that your restrictions are being passed:

hidden link{redated}&token={redacted}

But I do see the country of "us"and the "(regions)" parameters being sent on the query, so it is maybe more of a question as to why Google is offering suggestions that do not fit those restrictions?

[Waqar]

Thank you for sharing your observations. My further tests reveal there are two separate matters that need to be discussed:

1. Custom script's affects:

I can confirm that the autocomplete initialized as a result of my custom script seems to apply the country and type restrictions, correctly.

Without that custom script, if I type "empire", the autocomplete field brings in results like "Empire State Building" (a place/landmark), "Empire City Casino" (a place/landmark), and then a couple of cities from different states in the US.
( screenshot: hidden link )

And when that code is added, the same text "empire", only limits the results to cities from different states in the US only, excluding any places/landmarks.
( screenshot: hidden link )

You can even repeat the same test with the simple text "new". Without code, you'll see results like New York (US), New Orleans(US), New Delhi (India), and Newquay(UK). And with the code, the results will be limited to only the cities in the US.

And about "Black Hills", I'm sorry but I couldn't find any reference online confirming a city with this name and all the results point to a mountain range, not a city.

2. Downside of using the custom script:

The challenge here is that Toolset Map initialize's its own instance of autocomplete for the address type field, through the file:
/wp-content/plugins/toolset-maps/resources/js/wpv_addon_maps_editor.js

The way it is added, it is not possible to include additional attributes for the type and area restrictions, without actually editing the core plugin files (which is never recommended).

My custom script doesn't alter the default autocomplete instance, but initializes new one. It initially appears to work, but repeated entry of text and location selection results in duplicate suggestion windows appearing for the same field, which eventually disconnects with the map preview and is bad for the user experience.

Disabling the original autocomplete instance from Toolset isn't an option because then the map preview and storing of selected location's coordinates in the map's cache table in the background, won't work.

So based on these points, I'll not recommend using that custom script to initialize a new instance of autocomplete as it is doesn't work consistently.

You're welcome to submit a feature request for this restriction feature in the Toolset Maps through:
https://toolset.com/home/contact-us/suggest-a-new-feature-for-toolset/

For more personalized assistance around some different custom code alternative, you can also consider hiring a professional from our list of recommended contractors:
https://toolset.com/contractors/

[Steve Palm]

I understand, and I can't thank you enough for the amount of time you have invested into not only the initial suggestion, but in pointing out why in the end this is not feasible at this time. It is understandable why it is the way it is, and so even though our problem can not be solved at this time, I am very happy with the support you have provided.