Information discussed with a client on how the Proximity Filter works.

Multiples of the same location come up as options (i.e. you type in Ohio, and [four] "Ohios" appear in the drop down)


When you type characters in the search box, those characters get sent to Google or Bing (depending on which provider you are using) via an AJAX call and they then send back a list of geographical location matches. We appear to have very little control over what, exactly, gets sent back for a match.


In the case of Ohio, BING returns FOUR matches:



Ohio County, WV, USA

Ohio County, IN, USA

Ohio County, KY, USA


For each of these four matches, Bing chooses to only return a location match name of “OHIO”. Why?  Your guess is a good as mine, but it makes it impossible to select the correct “Ohio” from the list (hint: the FIRST one refers to the STATE)


Google’s results are better – only two matches are returned and both refer to the State of Ohio.


My recommendation is to try Google if Bing’s results are not acceptable.


This brings up a bigger point – expecting relevant search results when entering ONLY a state is a fool’s errand. Users should be directed to enter a specific geographic point like a city, zip code, or the best option of all, a street address

Searching “Texas” and “200 miles” only pulls up 2 options in Texas but searching “Houston, TX” and “200 miles” pulls up 8 options in Texas


When you enter Texas (assuming you pick the correct “texas” from the list) you are getting back a geo coordinate that represents the approximate geometric center of the state. Texas is VERY large. Your results will be 200 miles from this center point.  Entering a city is MUCH better and gives more accurate results.

Some international locations are not showing up on the map (when the map was still active). Example: C.V.M. in Thailand


When this happens, check your data node and look to see which entries do not have geo coordinates. I do this by creating a custom view that displays:


Location Name



Geocode error



Google or Bing often have trouble with foreign addresses, even when they are formatted according to international addressing standards.  In this specific case, the address is clearly unintelligible to Bing and so this business has no coordinates and thus will never be found using the proximity search.


If the address is cleaned up and we still can’t get coordinates, then the lat/long would have to be entered manually (or the data node would have to be exported to a spreadsheet, the coordinates added, and the data would have to be uploaded)

For some states, like Indiana, they entered the state as IN, rather than spelling it out. As such, when someone searches Indiana, no results appear. Do they need to 

switch their data to say Indiana, or is there a way to have it recognize the abbreviations users type in? 


What the user types in has nothing to do with the address fields of a location in the data node, at least in terms of how a State is formatted. The geocoder understands state and state abbreviations just fine. This question is related to the “Ohio” question above. 


First, the user would not be able to enter just “IN”. The proximity search box doesn’t allow it if there are any location matches.


Second, “Indiana” is a match for “IN”. Selecting the first option gives good results.

They don't have locations in every state or country. As such, they're wondering if there could be a "nearest available" option. For example, there aren't any locations in New Mexico so the nearest available location would be another state. The nearest available would filter against whatever the user types in the location box. Is this even possible?


No, this is not currently possible, at least not as they’ve described it, but there is a solution – offer more mileage options. Instead of stopping at 200 Miles, add 500, 750, and 1000 mile options. That will achieve the same goal.


Sometimes, it appears that the geocoder comes up with coordinates that are not actual location of the entity in the data node. Why?


True, this can happen and there is a fix for this.


The problem is the “confidence” rating assigned to a match during the geocoding process.  Older versions of the geocoder were too generous with what was considered a match.  We had a case in which a business address in Elkhorn WI could not be found with high-confidence so the “medium confidence” coordinates were used and those coordinates were the geometric center of the state. Not helpful.


The newer geocoder has tighter rules – if it can’t find a high-confidence match it will not assign coordinates to the item.  This then gives the client the ability to manually enter missing coordinates (or fix the addresses as needed and rerun the geocoder background job).