TITAN CMS - Data List

Proximity Filter

Overview

In the Data List block, the Proximity Filter can be used with Geographic Coordinate column type.  The data record should have a Latitude and Longitude entry for record to show in results.  In v6.9 a change was made, meters were changed to kilometers.

Steps
  1. Select the Proximity Filter and make desired selections.
  2. Configure the following:
    1. Select the Data Field *Column name for the Geographic Coordinate
    2. Set your Display Options
      1. Check to permit proximity filtering on display or not. 
      2. Enter the Initial Location - *Latitude and Longitude, use this to enter an address/zipcode Lat/Lng for initial prefiltering results.
      3. Select the Address/Zipcode Lookup Service - *The services available to use for converting user entered addresses/zipcodes into Lat/Long so we can filter.  These options are configured in the GeocodingConfig XML in Titan Admin module.
      4. IP-Based Location Service - *The services available to use for automatically converting user's IP address into Lat/Lng so we can filter.  These are configured in the GeocodingConfig XML in Titan Admin module.
      5. Native Browser Location - *Modern browsers support reporting your location, if you approve it.  This configures whether or not the pages should ask the browsers for your location.
        1. None
        2. Mobile Only
        3. Always
      6. Title - *Enter new title or use default Location
      7. Location Hint Text - *Text that will display in the search field.
      8. Radius Options - *Units used, options and default setting
        1. Miles
        2. Meters *v6.9 changed to Kilometers
      9. Enter additional Distance options if desired.
      10. Update the default value if desired with "Is Default" checkbox
  3. OK to retain configurations

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, USA

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

State

Geocode

Geocode error

Geo_confidence

 

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).

Titan CMS Training

Check out upcoming Titan CMS Training Classes
 

Learn at Northwoods 

Workshops
 

Titan CMS Support

(414) 914-9200
Submit Questions
 

Northwoods Web Solutions

p: (414) 914-9100