Road trip? Ask Iggy.

Photo by Aaron Burden on Unsplash

Now that summer is here and we’re starting to see the light at the end of the long COVID tunnel (🤞), our thoughts are turning to travel. Travel to see friends and family, travel for work, or travel just to get out of town for awhile. While trains and planes might still feel risky for some, road trips are a convenient and comfortable way to get the heck out of Dodge.

Road trips…convenient and comfortable, but also frequently boring. Well, at Iggy we’ve spent the last few months heads down adding data for our users. And some of our new datasets like parks, wineries, and antiques shops include great side destinations that could turn a road trip into an adventure. So we thought, why not see if we can create an app to suggest recommended road trip routes based on someone’s individual interests?

The use case goes something like this: Alex and Jo are driving from their home to Jo’s parents’ place three states away. They are traveling with a dog and a toddler; they are happy to trade a little drive time for a route that offers plenty of diversions along the way. Alex visits our road trip app, inputs their start and end points and matching personas “Are we there yet?” and “Dog’s best friend”, and receives a selection of routes that are optimized for the number of dog parks and playgrounds easily reachable from the main route.

Building an app like this from the ground up would normally require a ton of work to gather, clean, normalize, and organize all the location information. Points of interest come from several data vendors. Parks come from public sources. Adding dog parks requires both patience and luck in divining OpenStreetMap (osm). But with the Iggy API, developers can integrate all these sources and over a hundred more into their apps with just a few lines of code. Here’s how we did it.

Our app takes user waypoints (journey start and end, and maybe a few stops along the way) as input. We then make an API call to our favorite routing service which suggests several possible routes that hit all the waypoints. Finally, we score each possible route based on the user’s preferences and the amenities (i.e. dog parks and playgrounds) that exist within a short distance from the route.

Scoring a route requires two things: a weighting scheme that assigns weights to amenity types based on user preferences, and an amenity list that tells us what amenities actually exist along that route.

• The weighting scheme is a set of key-value pairs that dictate the weight various amenity types (i.e. features from specific datasets) have in calculating a route’s overall score. (Check out the full list of Iggy datasets here.) If someone prefers a route that passes nearby amenities in the osm_sightseeing dataset but doesn’t care about osm_playgrounds, then osm_sightseeing gets a higher score than osm_playgrounds. As an easier way to provide users with simple weighting scheme options, we developed personas that are each associated with a particular weighting scheme:

personas: {    
  'nature_lover': {      
    'osm_campgrounds': 4,      
    'osm_parks': 4,      
    'osm_sightseeing': 1    
  },    
  'are_we_there_yet': {      
    'osm_family_entertainment': 3,      
    'osm_playgrounds': 5,      
    'osm_rest_stops': 2,      
    'osm_shop_sweets': 2,      
    'osm_sightseeing': 3   
  },    
  'sophisticated_shopper': {      
    'osm_shop_antiques': 5,      
    'osm_shop_gifts': 2,      
    'osm_rest_stops': 2,      
    'osm_shop_art': 4    
  },    
  'total_tourist': {      
    'osm_sightseeing': 5,      
    'osm_rest_stops': 2,      
    'osm_parks': 2,      
    'osm_shop_gifts': 4    
  },    
  'dogs_best_friend': {      
    'osm_dog_parks': 2,      
    'osm_parks': 4,      
    'osm_sightseeing': 1    
  }
}

• An amenity list is simply a count of amenities of a particular type that exist within a given radius of a route segment. Using the Iggy API, we can easily retrieve an amenity list surrounding a given geographic coordinate as follows:

import fetch from 'node-fetch';
const iggyToken = process.env.IGGY_PRIVATE_TOKEN;
const requestHeaders = { Accept: 'application/json', 'X-Iggy-Token': iggyToken };
const apiURL: 'https://api.iggy.com/features/v1/datasets'
function jsonToQuery(json) {
  return Object.entries(json).map(e => e.join('=')).join('&');
}
async function getAmenities(coord, dataset_id, searchRadius) {
  const params = jsonToQuery({
    longitude: coord[0],
    latitude: coord[1],
    radius: searchRadius // meters
  });
  const iggyRequest = await fetch(
    `${apiURL}/${dataset_id}/select/buffered-point?${params}`, {
      method: 'GET',
      headers: requestHeaders
    }
  ).catch((error) => console.log(error));
  const features = await iggyRequest.json();
  return features;
}

The function getAmenities takes a coordinate [longitude, latitude], a dataset_id, and a searchRadius as input, and returns a list of features that exist within searchRadius meters of coord from the input dataset.

Putting this all together, in order to get a score for a route and a given profile, we do the following:

• Subdivide a route into segments, each represented by a coordinate at the segment’s center point.
• For each segment, and for each dataset in the profile’s weighting scheme (e.g. osm_dog_parks), retrieve the count of amenities for that dataset within 10k meters of the segment coordinate:

const dataset_id = 'osm_dog_parks';
const segment_amenityCount = length(getAmenities(coordinate, dataset_id, 10000))

• Score each segment by taking the weighted sum of amenities, where the weight of each amenity type (i.e. dataset) is given by the profile’s weighting scheme.
• Compute the mean segment weight over the route.

Our final UI allows the user to select one or more of the pre-defined personas, and then presents the user with their available routes. The coloring scheme along the route indicates the score of each road segment according to the persona weighting scheme.

There is so much we could do with Iggy to extend this prototype. Some possibilities:

• Avoid wildfires by filtering out routes where the nearest wildfire is less than 20 miles away, using our wildfire boundaries dataset, updated twice daily.
• Prioritize routes that have lower population density along each segment, using the U.S. Census Tracts dataset and the properties endpoint.
• Give higher weight to routes that drive through older, quaint neighborhoods, using the American Community Survey Housing dataset to find areas with earlier median house build dates via the properties endpoint.

We hope that this post provides some food for thought — sign up for an API key here and take it for a drive. We can’t wait to see what you’ll build with Iggy!

With thanks to bdejesus