How to Use Isochrones for Food Delivery

Isochrones depict the location from which someone can travel to another location within a certain amount of time and with a certain cost. In this article, we explore isochrones and how to use them in food delivery applications focusing only on the APIs.

Food delivery is one of the fastest-growing industries, driven by innovative technological tools such as accurate navigation, direction, and real-time information software. Most restaurants, supermarkets, and food suppliers have gone digital and now use the customized web and mobile applications. These are accessible through web services and APIs created to help build and run food delivery operations and activities.

When delivering food, restaurants must know which location should make delivery to a customer. Likewise, customers must know which restaurant locations, if any, will bring them food.

This calculation cannot be a simple distance radius since road conditions, traffic, speed limits, and other factors affect travel time. In addition, it cannot be a static area because the customer may not be ordering from home. With orders pouring in and the grill smoking, restaurants must quickly determine which location is within delivery distance from each customer to ensure the food arrives hot and fresh. At the same time, customers need to know the delivery window they can expect from each restaurant.

Isochrones are lines drawn on a map connecting points at which something occurs or arrives at the same time. The isochrones depict the location from which someone can travel to another location within a certain amount of time and with a certain cost, such as kilowatts for electrical vehicles and fuel for combustion engine vehicles. They incorporate real-time events and spatial data to calculate this travel area. Because isochrones are too complex to determine manually, developers building food delivery applications usually select robust routing APIs that include isochrones and handle various location, routing, and traffic services. This saves time and effort.

In this article, we explore isochrones and how to use them in food delivery applications. We focus only on the APIs and not on a specific language or framework. All principles we discuss apply to any language or framework without modification.

Proposed Application

To run a food delivery service, we must enable the customer to see which restaurants are within a reasonable delivery range of their current location (or any location of their choice). The delivery range is the radius from the delivery location and road conditions, traffic, speed limit, and more. Therefore, the map must be dynamic to reflect factors such as the customer’s location and changing road conditions.

Fortunately, TomTom’s Routing API calculates reachable range when we provide an origin location (either by specifying the current location or selecting another location on the map) and a time budget. This yields a polygon representing the geographic area the driver can reach within the specified time.

To serve restaurants and customers, we can build a routable network from which we can get adequate response time. We do this by storing a set of restaurant locations that are part of our network in a geo-aware data store like PostgreSQL with PostGIS. PostGIS, in turn, takes the geo-region Routing API’s Calculate Reachable Range function and returns all nearby and reachable restaurants in that region.

The figure below is a conceptual diagram for part of a proposed food delivery application.

Let us discover how this web-based application works using TomTom APIs as a back-end service to generate isochrone maps.

Before we proceed, create a free account to access TomTom’s developer APIs. The account also gives you an API key (found in your account dashboard), protecting you from abuse and providing useful application analytics.

Usually, we use the API through an API request URL of the following general format:

http|https://baseUrl/map/versionNumber/tile/layer/style/zoom/x/y.format?key=Our_API_Key&view=...  

For the sake of demonstration here, we replace our evaluation API key with YOUR_API_KEY within the API request URLs, as in the example below. Make sure you insert your key into each URL.

https://api.tomtom.com/map/1/tile/basic/main/0/0/0.png?key=YOUR_API_KEY& view=Unified  

As you follow our demo application, you can use the API Explorer to test API parameters and attributes. You can also explore TomTom’s documentation for more information.

Location Selection

Our proposed application starts with the map view and initial landmark pointing to the user’s actual location as indicated by their device GPS. However, the user can either choose their current location or specify any other place by moving the landmark icon. This changes the location latitude and longitude coordinates.

Developers can use the Maps SDK for Web to render the geodata into gridded sections called tiles (square images of PNG or JPG format in various sizes and different zoom levels) to display a map with a current location and a movable landmark.and a movable landmark.

Reachable Range Calculation

The central part of our proposed application uses the Routing API. After the user chooses their location, they should be able to request a specific time budget.

The app then passes some parameters, such as location, time budget, and user settings, to the Calculate Reachable Range function. This function, in turn, calculates the possible set of places that someone can reach from the origin point within the specified time budget and user settings.

Users can optimize their routes by selecting the routing type to be fastest or changing user settings such as a method of travel (on foot, by car, by bus, and more), traffic conditions, and other settings. The app displays the output of this function as a polygon boundary in counter-clockwise orientation centered on the initial location that a user specified.

Our food delivery app accesses this function through the request URL with GET or POST HTTPS methods. You can see common routing parameters on the TomTom Routing API documentation page, but there are only two base path parameters: versionNumber and origin. Origin is the latitude and longitude of the user-selected location.

The remaining parameters are optional and exclusive. They represent the user’s custom settings to the returned result. Examples of these optional parameters are time budget in seconds, fuel budget in liters, electric energy budget in kilowatt-hours (kWh), traffic, travel mode, and so on.

The figure below suggests a simple graphical user interface (GUI) for passing these parameters to the Calculate Reachable Range function.

The response content type can be either XML or JSON. The response will be an error code if there is an error or spatial data from the API representing geo-regions within the input parameters and restrictions, which is the reachable range.

Storing Results

After getting geo-regions as output from the reachable range calculation, we need to save this spatial information in a geo-aware database management system. PostGIS is the perfect candidate for doing that since it is a specialized extension to the open-source, object-relational database PostgreSQL.

PostGIS has extra facilities that support geographic objects’ storage and querying. It handles geo-objects like points, lines, polygons, geometric collections, and topological objects in 2D or 3D spaces.

To implement our application, we design our geo-database as a PostgreSQL database then handle it through PostGIS. We use the function ST_GeomFromText to construct a PostGIS geometrical object from a text representation. Also, we may depend on the function ST_Intersects to find spatial intersections if a geometry or geography shares any portion of space. Other functions detect overlapping and touching.

These functions enable us to query the saved geo-region from the previous stage and generate a set of nearby reachable restaurants as defined by the TomTom Map view. We then pass this set to the next phase.

Displaying Results on the Map

The TomTom Map Display API converts the set of nearby and reachable restaurants to iconic landmarks. It displays them on the map either as raster or vector representation, layered or not, depending on user choice and preferences.

To do so, it follows these steps:

• Add the map view to the application.

• Walk through the list of nearby reachable restaurants in the routable network result.

• Display the geo-region as a colored polygon centered on the origin location.

• Add markers to the map that represent the restaurants.

Summary

New technology advancements, and the COVID-19 pandemic, have strongly impacted the food delivery industry. Restaurants have a greater need than before to build and implement web and mobile applications with maps, directions, traffic, and notification APIs to handle food delivery operations.

Isochrone maps help boost these apps’ effectiveness. Using TomTom Maps APIs, our proposed application enables users to select their location and provide a time budget and other settings to restrict delivery. Our app then calculates the reachable range and saves a geo-region based on those parameters. This generates a list of reachable restaurants. The app then displays the result on an isochrone map to show the user locations to order food delivery.

To expand this application, you can create notification objects that send an estimated time of arrival (ETA) to users, create routes, and track the delivery. This type of application is helpful for restaurant chains as well as food delivery services that deliver from a wide variety of restaurants to hungry customers.

To explore TomTom Maps APIs and SDKs and create your next great app, sign up for your TomTom developer account.

To learn more about food delivery use cases, check out these resources:

• Creating an App for Efficient and Convenient Delivery Services
• Using TomTom Data via APIs to Improve Delivery ETA Accuracy
• Using TomTom Data to Improve Delivery Routes

Happy mapping!