One method of delimiting a geographic search is to added geographic-specific keywords to the text search. For example, the city, state, and zip code of our tourist attractions could be text-searched along with the usual descriptions. Let's use the following table schema:

• Name
  The attraction's name

• Desc
  A brief description of the attraction

• City
  The city where the attraction is located

• State
  The two-letter state

• Zip
  The (integer) zip code

We create a Metamorph index on not only Name and Desc , but the other fields as well:

create metamorph inverted index xgeo on tourist(Name\Desc\City\State\Zip)

Now we search against those fields with LIKE in our script:

  <SQL "select Name
        from tourist
        where Name\Desc\City\State\Zip like $query">
  </SQL>

passing our user's $query to the search.

Since the state, city and ZIP code info is part of the text field, our users can geographically delimit their searches with queries like this:

Wyoming bed and breakfast

NASA rockets in Huntsville

restaurant 440*

giving a state, city, or ZIP code, or combinations thereof. Note the wildcard in the last query: this matches several nearby zip codes, broadening the search.

Advantages

The biggest advantage to this type of geographic search is that we can probably completely resolve the query with one index, the Metamorph index. This can greatly speed up the search over, say, an AND clause that would require post-processing.

Also, we can limit the search to an exact political region, say a city, without needing to know its latitude/longitude.

Disadvantages

The biggest disadvantage is that we can't easily zoom in or out to cover a larger area in the search, nor cover a fixed region centered on a location. For example, searching for hotels in Rhode Island may leave out ones just a few miles away in a neighboring state. We can't tie the search to, say, a 100x100 mile area centered on Providence, regardless of state/city boundaries.

ZIP codes that have the same prefix might not really be adjacent, making the exact region ambiguous.

Having the same state in many rows in the table makes the index larger, and that "word" will because noisy in the query, slowing the search.

To resolve some of these issues, we can use latitude and longitude data, as in our next example (next page):