Store locators are a popular feature of large retailers and businesses that have more than one physical location.
The way they operate is simple - given a user-supplied location (typically a zip code or city) they list nearby stores, ordered by distance. There are variations on this approach but the basic principle remains the same. They are a relatively recent innovation - such technology didn't exist prior to the Internet. Not so long ago a customer would have had to ring up or look at a paper map and work it out for themselves.
Traditionally the high cost of online mapping prevented widespread use of store locators. Finding good-quality data was hard enough (especially for developing countries without accurate mapping) and even if data was available, the cost of licensing it was prohibitively expensive, making it unfeasible for the majority of organizations. Commercial GIS software (from ESRI, MapInfo and others) and open source alternatives such as MapServer made it possible to display static online maps at fairly low cost, but lack of street-level data proved a huge stumbling block. And let's face it, store finders certainly require street-level mapping to be useful.
Web-mapping proliferated with all kinds of weird and wonderful uses and "mash-ups" created. One interesting development was the creation of the OpenStreetMap initiative. Although new mapping services made the technology accessible, there were still fairly tight restrictions on what you could use them for. OpenStreetMap counteracted this by developing user-generated content - crowdsourcing for mapping. Importantly the data was free in the strict sense of the word and could be used without restriction. On paper, getting people to upload GPS data whilst driving down roads, sounds like a recipe for disaster but it worked surprisingly well and provided a credible open source alternative of data.
New features such as map overlays, geocoding, turn by turn driving directions and pseudo-3D views all continued to push the boundaries of what was possible in a humble web browser. Despite the tough competition, Google Maps continually evolved and arguably remains at the top of its game. It's no coincidence that seven years after its introduction the Google Maps API remains the most popular Application Programming Interface on the web today, mapping or otherwise.
Geocoding involves taking a human-readable location (e.g. an address) and converting it into a machine-readable location (ie. geographic co-ordinates). This is a key requirement of store locators (and online mapping in general) otherwise people would be forced to type in GPS co-ordinates or the like - hardly convenient. Until recently this proved a real challenge, or headache, depending on your point of view. Humans are great at interpreting addresses (and their myriad variations) but computers proved pretty terrible.
Over the years geocoding improved but was still often only 70-80% accurate - good, but not good enough. It was rather like the state of Speech Recognition today - undeniably getting better but not practical for general use. The good news for geocoding was that a tipping point was reached a few years ago where you could throw all manner of textual locations at a geocoder and on most occasions it would correctly convert it to a geographic co-ordinate. This was particularly relevant for store locator tools which involved lots of geocoding (both store locations and user-entered locations). It's still not perfect, and not an exact science, but today an address not geocoding is more likely to be down to human error (e.g. typos), rather than a deficiency in the geocoding process.
So the mapping and geocoding was sorted. What next?
Well at its heart, a store locator is a distance calculator. In geometry, calculating Euclidean (aka straight-line or "as the crow flies") distance is easy, making use of Pythagoras' Theorem (a staple of school text books).
The complicating factor for store locators is that the equation assumes a flat surface, which the Earth is not (it's an oblate spheroid if you're wondering). This complicates the maths and makes working out distance to a high degree of accuracy quite involved. It is often quipped that life for geographers would be far simpler if the world were flat. That said, getting a reasonable (aka "good enough") approximation is quite easy, and perfect for the purposes of a store locator.
Of course, straight-line distance is not always appropriate when calculating how "near" a store is to a given location. Strictly speaking, distance (for our purposes) should take into account the ease of travelling somewhere. Store A might be further away from your house than Store B, but if it's accessible by a highway and therefore faster to get to, it is in some sense nearer.
In other words store locators should order their results by driving distance rather than geographic distance. In practice this rarely happens.
Computational load (aka "too many sums to work out"). Say you have 500 locations. A user types in a zip code. You'd have to work out the fastest driving route from the zip code to each of the 500 locations. A Sat-Nav often takes a few seconds to work out a new route, so imagine doing 500!
And don't forget the mode of transport (cycling anyone?), current traffic conditions etc etc. Thankfully there are various optimizations that can be performed but the bottom line is: the extra effort involved is not worth the extra accuracy gained. For store locators using straight-line distance is fine in 99% of cases. Phew.
One other interesting consideration for store locators (and all "find the nearest X" tools) is handling the relative sizes in user-input locations. When searching, a customer might provide any of the following (from most to least precise):
Distance calculations are point-to-point which presents a problem: if we perform distance calculations from our stores to the user's location then exactly what "point" should we use? Often the geometric center of the location of used.
This is fine for addresses (and often zip codes) because they are nice and precise and cover a small area. However a town or city (and certainly an entire country) can cover a large geographic area and by using the center of this area to calculate distance we can introduce a bias to our store locator.
Well consider this: if a user searches for Los Angeles and you take the geographic center (aka center of gravity) of Los Angeles as the center point used to calculate distance, store locations near this center point will always appear first in the results, simply by this positional quirk. For Los Angeles the center of gravity is actually near Franklin Canyon (largely unpopulated) so the "top" result, ie. the store located nearest the Canyon, would get the top slot. Geocoders combat this by returning a center point in the "heart" of a place (e.g. downtown LA) but the bias in results towards stores that just happen to be located near this center still applies. In an extreme case if a user typed "USA" into a store locator search box the center point would be somewhere in the middle of nowhere (specifically: a lake in Kansas between Coffeyville and Independence if you're interested). Hardly New York or Washington.
Does any of this matter?
Well, yes, as it could lead to disgruntled store owners. Say there are two stores within a given zip code. Store A happens to be near the geographic center of the zip code whilst Store B is slightly further out. When people search for that zip code Store A will always come out top even though there's really no difference between them in terms of relevance or convenience. It could actually affect which one people decide to visit which in turn could affect sales.
So how can a store locator solve this dilemma? Well, as is often the case, there's no perfect solution. But one approach is to consider the actual area covered by a search location, not just its center point, and treat stores within that area on an equal basis. So it finds all stores within a zip code area and then randomizes the results. This gets around the problem of geographic bias but for large search areas may produce seemingly odd results. Of course, a user who searches for a city most likely wants a general idea of available stores, whereas a user who searches using an address or zip code is more likely to be interested in actually making a trip. So it seems a reasonable compromise.
The future of the Internet is mobile and Location Based Services are gaining in popularity. They've been the "next big thing" for well over a decade now. Unlike some location applications (such as targeting ads or special offers towards users based on their precise location) store locators don't suffer from the same perception of privacy invasion ("Big Brother is watching you..."). Store locators serve a useful purpose and are instigated by the user (not forced upon them). If a user accesses a store locator from their cell phone it's quite likely they want to find their nearest store immediately.
Over time people might become less wary of locating technologies, although it should be noted that attitudes could go in the opposite direction. But automated location technology is likely to play an increasing role in store locators, particularly in countries where Internet access is predominantly through mobile devices.
Digital maps are undoubtedly a battlefield for the major players, each pumping millions of dollars into collecting and correcting data, and presenting it in useful ways. When Apple debuted its own mapping app (replacing Google Maps) for iOS devices its inferiority was quickly exposed by users. It made headlines across the globe and caused Apple a major PR headache. They learned the hard way how consumers have become accustomed to consistently high quality, detailed mapping. One benefit of such fierce competition is an insatiable appetite for innovation.
LiDAR is one such innovation, bouncing laser beams off buildings and trees to create detailed 3D models. The technology has been available for decades; but never before have fleets of vehicles been driving the roads of our towns and cities capturing the world they "see" in 3D. Incredibly, Nokia's mapping division has been doing just that, such is the desire to gain a competitive edge.
So, in summary, it used to be that only large organizations could afford store locators. But slippy maps and accessible street-mapping data allowed small and medium sized businesses to get in on the act.
Combined with smart geocoding and ever-improving hardware/software there's now no reason why any business can't enjoy a store locator on their website.
Presenting results in a meaningful (and unbiased) way may not be as easy as you'd think, but the hard problems have been solved and it looks likely store locators will be with us, and used "on the go", for as long as people physically visit stores. And (despite the growth of shopping online) that won't be ending any time soon.
All this takes place against a backdrop where people's love affair with mobile devices continues unabated. Intense competition between mapping providers is fuelling the kind of technology that wouldn't look out of place in a sci-fi film. Digital Mapping's Golden Age shows no sign of waning, which is great news for the humble store locator.