How to build location-aware mobile apps using Google Places API

• System initiation script

The first script wine-picker/require_once/update_city_bboxes.py gets started only once in order to initiate the system in case of transferring to a new server or the Places’ current database is empty. The system obtains information about 45 cities around the world, including 15 major locations located in Europe, 15 cities in the U.S. and 15 major cities from three other continents.

The initiation script processes this list of places, finds their coordinate values and saves the information into the database (city_bboxes is created).

City boundaries need to be determined so that a user could use location-based information in their Wine Picker app. We retrieve this data through Nominatim API, a search engine for OpenStreepMap data (bounding box).

Determining city boundaries in a convenient format was the first considerable challenge for our team of developers. Our decision for Wine Picker is based on the use of squares, an unconventional approach that helped keep the process simple and fast for implementation.

A response contains the coordinates of a rectangle framing the city. If a response provides multiple bounding boxes, the script selects the largest bounding box square.

Once the initial information about restaurants is received, the next task for the app is to perform location search in the boundaries of each selected city. This is where the second script launches.

• Coordinates processing script

The second script wine-picker/require_once/update_place_list.py is started only once, after the first script, to initiate the system. It processes city coordinates from the database (from the table city_bboxes). Our goal here is to divide each of the 45 cities into 3km x 3km squares and search for restaurants within each square.

Using Google Places API, the app determines a user’s location and searches for restaurants in 500 meters proximity from a user.
If a 3km x 3km square contains more than 20 restaurants (equal to one Google page), the square is divided into 4 squares and search is performed in the current square once again. The action is repeated until 20 or fewer restaurants per square are left. The pointer to the next page is the indicator of square division.
Once 20 or less places have been found, their IDs are automatically added to the database (table temp_place_caching, which is a queue for processing).

• Cached places processing script

wine-picker/cron-5-minutes/cache_google_places is the script that processes cached places. It is started every 5 minutes and for processing it fetches restaurants in batches of 100 from table temp_place_caching.

The script checks whether the restaurants are present in the database and when the latest update of those restaurants was made.
For a place that was updated in the past 45 days, the system designates it as updated and removes its ID from table temp_place_caching. If more than 45 days has passed, the system retrieves information about the place using Google Places API, Place Details.

The script conducts check whether the restaurant is closed (parameter permanently_closed). If the response is empty or shows permanently_closed=TRUE, the place with all its data is deleted from the database (from table temp_place_caching).

If a place was not updated in the past 45 days and is not permanently closed, the place gets updated. The following parameters are processed for Wine Picker app:

• • opening_hours (conversion to json);

• • photo (if there are multiple photos, the system selects the first one and processes the reference for a hyperlink to the photo);

• type verification (is_geo_object).

Using types parameter from the response on places, the type of the place is determined by search in the following list:

  ‘administrative_area_level_1’,

  ‘administrative_area_level_2’,

  ‘administrative_area_level_3’,

  ‘administrative_area_level_4’,

  ‘administrative_area_level_5’,

  ‘colloquial_area’,

  ‘country’,

  ‘floor’,

  ‘geocode’,

  ‘intersection’,

  ‘locality’,

  ‘natural_feature’,

  ‘neighborhood’,

  ‘political’,

  ‘post_box’,

  ‘postal_code’,

  ‘postal_code_prefix’,

  ‘postal_code_suffix’,

  ‘postal_town’,

  ‘premise’,

  ‘room’,

  ‘route’,

  ‘street_address’,

  ‘street_number’,

  ‘sublocality’,

  ‘sublocality_level_4’,

  ‘sublocality_level_3’,

  ‘sublocality_level_2’,

  ‘sublocality_level_1’,

  ‘subpremise’,

  ‘transit_station’,

If any of the parameters is present in the place’s type parameter, it is designated as is_geo_object= true and is excluded from a response during restaurants search, but remains in the places table (general table of places) and is used during autocomplete search.

In case, Google reviews are found, they get stored in a separate table (place_reviews) with the following parameters: restaurant ID, author’s name, photo of the author, review text, and author’s rating.

 place_id,

 one_review.get(‘author_name’),

 self.gplace.get_google_user_image_url(one_review.get(‘author_url’)),

 one_review.get(‘text’),

 one_review.get(‘rating’),

 one_review.get(‘time’)

Users’ reviews are added every time a restaurant is updated. The app’s database filters duplicates using unique fields (place_id, timestamp, name (comparing the first 10 characters of the author’s name). The review data is necessary for calculating the users’ evaluation histogram on the restaurant’s details screen. This is how the histogram calculation function is performed:

max_rating = max(ratings.values())

      weight = 100 / float(max_rating)

      histogram = {

          ‘avoid’: int(ratings[1] * weight),

          ‘poor’: int(ratings[2] * weight),

          ‘fair’: int(ratings[3] * weight),

          ‘good’: int(ratings[4] * weight),

          ‘great’: int(ratings[5] * weight),

                        }

values – user’s highest rate

Currency for restaurant places is determined based on the code of the country in which it is located (e.g., GB for British pound sterling, USD otherwise).

          currency = defaultdict(lambda: u’$’)

          currency[‘GB’] = u’£’

A restaurant’s updated parameters are added to the general places table. This script also functions during search of restaurants, map scrolling, and any place-related request. Restaurants are not updated if there are no requests for them.

• Places updating  scripts (for search of new and closing old places)

When a map is scrolled or search for new restaurants is performed, the system receives the radius of the application displays at a given moment in time and location coordinates (screen center) from a request sent by a user.

Using the script, the system receives the places (up to 60 places):

• • If the square contains less than 60 places, the places are saved by adding their IDs to the temp_place_caching table;

• • If there are 60 places, the location coordinates and the radius are entered into table temp_coords_caching (presuming there are other places present in the square);

• every 5 minutes the system starts script wine-picker/cron-5-minutes/google_place_grabber which uses temp_coords_caching and receives places by dividing the square determined by the coordinates and radius.

That square, determined by the location coordinates and radius from the table, is divided into 4 squares. If any of the smaller squares has more than 20 places, it is divided into 4 once again, and so on, until one square has 20 or fewer places. Once 20 or less places have been found, their IDs are added to temp_place_caching, to the queue to be processed.

To update places data, script wine-picker/cron-5-minutes/cache_google_places (cached places processing script) is started every 5 minutes. It fetches places to process from the temp_place_caching table.

The use of Google Places API described above allows users of Wine Picker to use this app when they are traveling around the country and even around the world. The app performs a thorough place search so that a user receives the ultimate choice in taste preferences and pricing among various available possibilities.

Content created by our partner, Onix-systems.