Migrating from Google

Comprehensive migration guides for moving from Google Places to Woosmap Localities APIs.

Migrating from Google Places to Woosmap Localities is a straightforward process. This guide provides a direct comparison and actionable steps to update your implementation, focusing on the most common use case: an address autocomplete form.

Migration Checklist

Here are the key steps you’ll need to take:

  • Update Your API Endpoint: Switch from Google’s API endpoint to the Woosmap Localities API endpoint.
  • Swap Identifiers: Replace all instances and logic using Google’s place_id with Woosmap’s public_id.
  • Adjust Authentication: Use your Woosmap public key for client-side calls or private_key for server-side calls.
  • Update Response Parsing: Modify your code to handle the Woosmap JSON response structure (e.g., predictions array becomes localities).

API Service Equivalence

Woosmap offers direct, one-to-one replacements for the core Google Places services.

Google Places API Woosmap Localities API Description
Places Autocomplete Localities Autocomplete Provides location suggestions as a user types.
Place Details Localities Details Retrieves detailed information about a location.
Geocoding API Localities Geocoding Converts addresses to coordinates and vice-versa.
Nearby Search Localities Nearby Finds points of interest within a specified area.

API Endpoint Path Changes

To migrate your backend requests, you’ll need to update the base URL and paths for each service.

Autocomplete

  • Google: maps.googleapis.com/maps/api/place/autocomplete/
  • Woosmap: api.woosmap.com/localities/autocomplete/

Details

  • Google: maps.googleapis.com/maps/api/place/details/
  • Woosmap: api.woosmap.com/localities/details/

Geocoding

  • Google: maps.googleapis.com/maps/api/geocode/
  • Woosmap: api.woosmap.com/localities/geocode/

Nearby

  • Google: maps.googleapis.com/maps/api/place/nearbysearch/
  • Woosmap: api.woosmap.com/localities/nearby/

Code Example: JavaScript Autocomplete

Here’s a practical example of migrating a client-side JavaScript implementation for an address search input.

Before: Google Places SDK

A typical Google implementation uses AutocompleteService to get predictions and PlacesService to get details.

javascript
        // 1. Get Autocomplete suggestions
const autocompleteService = new google.maps.places.AutocompleteService();
autocompleteService.getPlacePredictions({input: "10 downing"}, (predictions, status) => {
    if (status === "OK" && predictions) {
        // predictions[0].place_id would be used to get details
        const firstPlaceId = predictions[0].place_id;
        getDetails(firstPlaceId);
    }
});

// 2. Get Place Details
function getDetails(placeId) {
    const placesService = new google.maps.places.PlacesService(document.createElement('div'));
    placesService.getDetails({placeId: placeId}, (place, status) => {
        if (status === "OK" && place) {
            console.log(place.formatted_address);
            console.log(place.geometry.location.lat());
        }
    });
}

After: Woosmap Map JS API

The Woosmap equivalent uses the unified woosmap.map.LocalitiesService for both autocomplete and details, simplifying the process.

javascript
        // Initialize the service once
const localitiesService = new woosmap.map.LocalitiesService();

// 1. Get Autocomplete suggestions
localitiesService
    .autocomplete({input: "10 downing"})
    .then(response => {
        // Note: the array is called 'localities' not 'predictions'
        if (response.localities && response.localities.length > 0) {
            // Use 'public_id' instead of 'place_id'
            const firstPublicId = response.localities[0].public_id;
            getDetails(firstPublicId);
        }
    })
    .catch(err => console.error(err));

// 2. Get Locality Details
function getDetails(publicId) {
    localitiesService
        .getDetails({publicId: publicId})
        .then(response => {
            const result = response.result;
            console.log(result.formatted_address);
            console.log(result.geometry.location.lat); // Note: lat is a property, not a function
        })
        .catch(err => console.error(err));
}

Key Parameter and Response Changes

Parameter Mapping

Most request parameters have direct equivalents. The most critical change is place_id to public_id.

Feature Google Places Woosmap Localities Notes
Place Identifier place_id public_id This is the most important change.
Authentication key key or private_key Use public key on the client, private_key on the server.
Autocomplete Text input input The user’s typed input string.
Country Filtering components=country:XX components=country:XX Restricts results to specified countries.
Search Center Point location location The latitude,longitude to bias results.

Core Differences to Note

  • Identifier: You’ll need to store and use Woosmap’s public_id instead of Google’s place_id.
  • Authentication: Woosmap uses two key types: a public key for client-side use and a private_key for server-side use.
  • Response Structure: The JSON response structure is different. You must update your parsing logic.
    • Autocomplete: Google’s response contains a predictions array. Woosmap’s contains a localities array.
    • Details Geometry: Google returns geometry.location.lat() as a function. Woosmap returns geometry.location.lat as a property.
  • Usage Limits: The Localities API has a default limit of 50 queries per second (QPS) per project.
‹ Tuning Your Localities Results Locality Types ›
Was this helpful?