POI Searches

Most map databases include some basic POIs, such as airports, train stations , parks, schools , and others. The exact list depends on the map database. There are various search types that make it easy for your application to quickly find the right POI for your user .

Search Types

Name Search

A name search handles various matches that might include exact match, wildcard, or soundex. A name search might also check both primary and alternate names . Name searches are typically most valuable when the user knows the brand that he or she is searching for.

Around a Point

A name search around a point allows a user to find all the brand X locations within a radius of a point. This might be the user's location, as identified by a location positioning method, or another location that the user has input. The user might be allowed to specify the search radius, or this could be handled by the application itself.

Along a Route

Searching for POIs along a route is a much more sophisticated and difficult solution. In this scenario, a user who was very loyal to a given gasoline company (because they receive a frequent shopper discount, because they are a shareholder, etc.) might want to know about all the gas stations within a half-mile of his or her route. This would allow the user to plan a driving route and make sure he or she is able to shop with the preferred gas station.

Globally

Global name searches would typically be used only for statistical or testing purposes. It is less frequent that a user would want to do a search on every brand in Europe or North America, as an example. In most cases, the user is better off with a city/region/postal code search or a search around a point. These searches are far less taxing on the server and generate a much faster response.

Within City, Region, or Postal Code

This search type is similar to the search around a point except that the extents are a city, region, or postal code boundary rather than distance from a point.

Category Search

A category search is similar to a yellow pages search in North America. The user does not necessarily have a specific brand in mind, but wants to find the nearest dry cleaner, post office, police station, hospital, or other landmark. The search types possible for category searches are the same as those for a name search.

Phone Search

It is not often that a consumer would want to search for a POI by its phone number, so you might wonder why this search type would be useful. Phone searches are most useful in business and customer service applications. Using telecommunication services that allow computer telephony applications to receive a caller's phone number, it is possible to develop mobile location services that do a database lookup and present a user's personal and location information to a customer service agent as he or she answers the telephone. One interesting application might be to route callers by geographic region to a customer service representative with local knowledge or language skills.

POI Databases

The POI data provided by map data vendors is not rich with details. Typically the information is limited to name, location, and category. Third-party POI databases often have specific and proprietary attributes that are not handled in a generic spatial analysis software system. For many mobile location service applications, these additional attributes are very important. As an example, an off-the-shelf map database and spatial analysis engine might provide a POI database that includes banks. But if your application is targeted to people who need to find a place they can get cash, they need to know where to find an ATM. ATMs can be found in many locations that are not banks, and some banks do not have ATMs. In addition, your user might want to know what bank networks the ATM supports, bill denominations the ATM dispenses, and hours of operation. Although less common in North America, many ATMs in Europe close at night. The additional information not included in the compiled map database is best stored separately and linked with a unique identifier.

Figure 4.24 shows a description of the process of building and integrating your own POI database as handled by Kivera (http://www.kivera.com), a provider of mobile location service technology. ^[4]

Figure 4.24. Process for Geocoding POIs.

1. Unique Identifiers

Only a small subset of the fields in the original POI data becomes part of Kivera's CSF database. CSF is the proprietary, compiled map data format Kivera uses. Information that does not become part of the database and yet would be useful to reference is placed into a supplemental relational database. To enable data stored in Kivera's database to refer back to the data stored in the supplemental database requires the existence of a unique set of identifiers. If one does not exist, Kivera's extraction program creates it.

2. Map Categories

Although the raw POIs are associated with a specific category, customers often want to redefine these for their own needs. For each vendor category that is to be used in Kivera's database, a mapping to a custom category, custom category ID, and icon is made. A field mapping (not shown) is also required to relate Kivera's required fields (name, city, state, etc.) to the fields in the vendor's data.

3. Extract Data

Geocoding is the process of determining a latitude/longitude coordinate from a given address. Most POIs do not have an associated latitude/longitude and require geocoding. However, some POIs, such as campgrounds, have an associated latitude/longitude and do not require geocoding.

4. Geocode POIs

Geocoding is the process of assigning a latitude/longitude coordinate to a place. Kivera's geocoding engine works with a variety of inputs, including the following:

Address (number and street)	OR
Cross street	OR
Phone number	OR
City and state	OR
Zip code

When not all of the given information exactly matches a location in the database, an indication of the level of confidence of the geocode is returned. Based on an operator's application model a variety of steps are then possible:

• Accept geocode and flag with level of confidence

• Fail geocode with this dataset and, if the customer is eligible to search more expensive data, try another vendor's data

• Fail geocode

One of the functions of Kivera's Geocoding Engine is to obtain a latitude/longitude coordinate given an address. This is accomplished by finding the link that has the desired address within its range and interpolating the actual latitude/longitude coordinates. A geocode operation is said to fail if an address match cannot be found. When this occurs, a list of failed geocodes is created with an error code, defined in Kivera's Location Server API Guide, as to why the geocode was not possible. Because the unique VEND_ID, POI_ID is associated with all of these failed geocodes, it is possible to review these records and correct the incomplete, inaccurate, or ambiguous data.

5. Geocoded Data

Each successive attempt to geocode data creates a new file. Because there can be tens of millions of POIs in a database and multiple attempts can be made to geocode this data, there might exist numerous files. These files are stored in a directory representing the corresponding data vendor. Also, because there can be multiple sources of POI data, there might exist many directories, each with many files.

6. Merge/Delete POIs

To absorb these files into Kivera's database, duplicate POIs from the same POI vendor are removed. If there is duplicate POI information from different vendors, Kivera's Merge POI Engine uses a preference table to select the data to be entered into the database. For example, if both vendor X and vendor Y have similar data about a specific POI, and vendor X is more expensive, the rules can instruct Kivera's Merge/Delete Engine to automatically include only vendor Y's data in the CSF database.

Besides being able to read spatial data from different vendors, Kivera's data neutrality applies to POI vendors as well.

7. Index Creation

Finally, three indexes are created and ordered so that a binary search algorithm can be used to quickly search the data. Each record also refers back to POI data using the unique VEND_ID and POI_ID references.

With these indexes, the following types of queries are possible:

• Search by any word in a name (Oakland Hilton Hotel would show up in a search for "Oakland," "Hilton," or "Hotel").

• Search by phone number, with or without area code.

• Search by category within a specified radius.

Routing With POIs

There are applications, such as routing, with which it might be valuable to provide users with directions that involve POIs. For example, rather than provide a user with directions that say "Left turn on Mission Street (0.5 miles). Left turn on 4th Street," an application could provide directions that say "After passing Moscone Center, turn left on Mission Street. Turn left on 4th Street after passing the Sony Metreon Complex." The additional detail in directions is particularly valuable when landmarks are very obvious and the street names are difficult to find or nonexistent. To make directions like this possible requires coding all POIs with a flag indicating whether it can be used in generating directions and also a value for how visible the landmark is. Certain POIs, such as a dentist's office, would be ignored, because they are not visible landmarks . The ranking and category would allow the application developer to select the most appropriate landmark to include in the directions. It would usually make sense to not include more than one POI per maneuver.

POI Sources

Sources of POIs are varied and highly regionalized. Most major map databases ship with a very basic set of POIs included. Sources of more detailed content include companies like InfoUsa, Dun & Bradstreet, Acxiom, and Experian in North America. In Europe, a common data source is ViaMichelin, which is used by Orange in France and T-Motion in Germany and Austria.