Results with undefined latlng and bounds returned by L.esri.Geocoding.geosearch when using searchBounds

[andywalz]

Describe the bug

When using L.esri.Geocoding.geosearch with searchBounds defined I'm getting a number of results outside of bounding box, returned without latlng/bounds, that when clicked do nothing.

Expected behavior

• I would expect these results not to appear as they are outside the bounding box.

Actual behavior

• There are no errors in the console.

To Reproduce

1. Go to https://jsfiddle.net/andywalz/s9pqkh16/5/

2. Search for "Park Bench Cafe" for example

3. Click on

4. Nothing happens.

5. Set searchBounds to false and "Park Bench Cafe" works as expected

Environment Information

• Version of Leaflet (L.version): 1.7.1
• Version of Esri Leaflet (L.esri.VERSION): 3.0.2
• Your OS: macOS 11.4
• Browser and Version: Version 91.0.4472.114 (Official Build) (x86_64)

[jwasilgeo]

Thanks for the clear and helpful description and live example.

I can verify that the suggestion network request (/suggest) and subsequent looking up of address candidates request (findAddressCandidates) both send along the valid searchExtent parameter.

And, respectively, as we see here, "park bench cafe" returns in the suggest response but not in the findAddressCandidates response.

In another scenario, we can try "Lexington" (both with and without the JS searchBounds geocoder plugin option), and we do get similar behavior.

My initial investigation and reaction leads me to think that L.esri.Geocoding.geosearch is working as expected, but the geocoding services are behaving differently with a searchExtent parameter for the 2 different requests.

Perhaps one way to alleviate this situation (while I think it is outside the control or bounds 😉 of this plugin) could be to perform client-side point-in-polygon checks before rendering the suggestions UI dropdown results, if a searchBounds option is present.

[andywalz]

@jwasilgeo - Thanks for the quick response. Once a result and a magic key is obtained using the searchExtent (from the /suggest call), shouldn't the searchExtent then be omitted from the /findAddressCandidates call that occurs on clicking the result? In other words, wouldn't including the searchExtent parameter only for the first request address this problem (and not change any existing behavior)?

e.g. this gives results that geosearch would work with: https://geocode.arcgis.com/arcgis/rest/services/World/GeocodeServer/findAddressCandidates?outSr=4326&forStorage=false%20outFields=*&maxLocations=5&singleLine=Park%20Bench%20Cafe,%2017732%20Goldenwest%20St,%20Huntington%20Beach,%20CA,%2092647,%20USA&magicKey=dHA9MCNsb2M9OTQxODQ0MyNsbmc9MzQjcGw9NDg5NjQ2NSNsYnM9MTQ6MjgzNTU3NjI=&f=json

[jwasilgeo]

Actually, upon looking into this a bit more, there is something going on with the source code here in esri-leaflet-geocoder with how the search extent is managed in the /suggest call versus the /findAddressCandidates call.

Here, only for the /suggest, there is a 0.5 padding being applied to the search extent: https://github.com/Esri/esri-leaflet-geocoder/blob/master/src/Tasks/Suggest.js#L31.

We can see that in the separate network requests the /suggest call has a larger searchExtent than originally defined in your code example, which incorrectly includes "park bench cafe". We'll continue to investigate.

[jwasilgeo]

@andywalz this will be fixed next time we publish a new release of esri-leaflet-geocoder. Thanks again for reporting it and discussing it with us.

[gavinr]

This was released in v3.1.0 https://github.com/Esri/esri-leaflet-geocoder/releases/tag/v3.1.0