Waze is a GPS navigation app owned by Google that combines Google’s road network information with their data feed partners. This information is collected and verified plus provides timely updates to changes on the road from planned road works to broken down cars and speed camera locations.

Waze partners can independently communicate road closures and incidents to the public from their own data sources via the Waze Data API. In order to feed data into a Waze map, the structure of the partners data feed must meet Waze’s data feed specifications. 

NGIS has built an accurate and consistent data sharing process that ingests our clients road information from the Waze Data API, into the publicly accessible Waze map. 

Structuring the data to make it compatible for Waze is a crucial part of this process. Let’s see what information is required to feed roads and traffic data into the Waze Data API. We will also cover what to do once the data is organised and how to push the data into the live Waze map.

The first step: Organising your data for the Waze Data API

To comply with Waze’s data feed specifications, road closures and incidents information need to be provided in a single file, with each record of closure or incident assigned a global unique ID. 

Here are Waze’s data feed specifications that need to be considered for road closures and incidents:

1. Road closure feeds – Road closure feeds are associated with planned incidents (i.e. scheduled road work). The data within these feeds should contain specific fields and meet the following requirements: 
    
   1. Incident ID: a global unique ID
   2. Polyline: geographic coordinates that describe the location of incidents, these should have at least six digits 
   3. Street: a specific street name where the road work is occuring
   4. Start time: start time of the closure in ISO8601 format (including a time zone)
   5. End time: end time of the closure in ISO8601 format (including a time zone)
   6. Direction: the direction of the closure, i.e. the road closure is in both directions or one direction
   7. Schedule: scheduled road closure timings which includes the day of closure
      
2. Incident feeds – Incident feeds are associated with any unplanned incidents, i.e. a car crash, an accident, bushfires, etc. The data within these feeds should contain specific fields and meet the following requirements:
   1. Incident ID: a global unique ID 
   2. Type: the type of road condition for example an accident, hazard or road closure
   3. Polyline: geographic coordinates that describe the location of incidents, these should have at least six digits
   4. Street: a specific street name on which the incident is occuring
   5. Start time: start time of the closure in ISO8601 format (including a time zone)
   6. End time: end time of the closure in ISO8601 format (including a time zone)
   7. Direction: detail direction of the closure, i.e. the road closure is in both directions or one direction
   8. Schedule (optional): scheduled road closure timings which includes the day of closure

Now your data is organised, you can start pushing it into the Waze Data API

Once the data meets Waze’s data feed specifications, the Waze Data API is then used to extract, transform and load incident data records in a JSON file format through to Waze.

To achieve this, the client and NGIS hosted the Waze Data API in Azure WebJobs and programmatically run jobs every 60 seconds. Incidents are sent through to Waze for up to 12 hours from the incident end date and time. Further, unplanned incidents are set to publish for 24 hours from the incident publish date/time.

Want to learn more about our work in the transport and logistics sector? 

NGIS has built geospatial solutions for the transport sector for over 27 years. If you want to learn more about our work in this space, head over to our transport industry page.