1. Administering Oracle Field Service
  2. Travel Time Prediction

Travel Time Prediction

Oracle Field Service uses time-based prediction for travel time. This topic describes how travel time is calculated in the application.

Travel time between two activities is calculated as a combination of:

  • Statistical “Learned” estimation

  • "Straight-Line" estimation

Note: You can specify durations for specific activities and mobile workers through APIs. For more information, see the REST API for Oracle Field Service guide.

Statistical “Learned" Estimation

Statistical Learned estimation is based on the historical travel times between two locations. These locations are represented by geographical areas, termed as Travel Keys. A Travel Key is typically a portion of or the entire Post Code or ZIP Code. When a resource records travel between two locations, the values are added to the statistics to produce a learned estimate of the travel between that set of Travel Keys. To produce and use a Statistical Learned Estimate for the travel time between two activities, both activities must contain a value that is part of the Travel Key and the Travel Keys must have enough historical travel data.
Note:

  • The travel time between two Travel Keys is adjusted over time as more data is collected.

  • Generally travel time for an activity is considered to be the time between the end of the previous activity and the start of the current activity. If there is idle time after the end of the previous activity (before the start of predicted travel to the current activity; for example, the current activity was assigned to the route after the previous activity ended), then the recorded travel time is not considered for the statistics.

Airline Distance Method

Oracle Field Service calculates the airline speed and parking time for each travel key separately. If one travel key encompasses an urban area, where speeds are low and parking times are high, while another key is located in a rural area with higher speeds and minimal parking times, travel time estimations using company-wide values may not be as accurate as possible. Estimations are likely to be more accurate when the airline distance speed and departure, or parking time are based on the values collected for individual travel keys. If there is enough reported data for a travel key, the airline speed and parking time is estimated based on the collected data. If there isn't enough reported travel data, the travel time estimate uses the default airline speed and parking time, as defined for the entire organization on the Configuration > Statistics page.

For travel within a travel key, the travel time estimate is the straight-line distance divided by the airline distance speed of the travel key plus the departure or parking time of the travel key.

Travel time estimate = Distance/Airline distance speed + parking time

For travel between two travel keys, the travel time estimate is the average of the travel time estimates calculated using each of the keys.

Travel time estimate = 0.5 * (Distance/Airline distance speed of key 1 + parking time of key 1) + 0.5 * (Distance/Airline distance speed of key 2 + parking time of key 2)

The final estimated travel time may be based on the airline distance estimation combined with statistically calculated travel durations.

Override Airline Distance Based Travel

You can use the Statistics API to override the travel estimations based on airline distance with any value you deem appropriate for each travel key. If a calculated override value exists, that value will be used to determine the travel time. For more information on the API, see the REST API for Oracle Field Service guide.

Travel time estimation

Oracle Field Service uses a parameter called Coordinated Travel Weight (CTW) to combine the two methods of estimations described earlier. CTW is a company–level value and is calculated using the Coordinate calculation weight parameter. Coordinate calculation weight is configured at the company level, in the Statistics page. The formula is:
Travel Time = Statistical x (1-CTW) + Straight Line x CTW

For example, if you set CTW to 0.5, the travel time is the average of the two.

Exceptions:

  • If the CTW value is 0.0, only the Statistical Learned estimation is used. If no Travel Key is available, the Default Travel time is used.

  • If the CTW value is 1.0, only the Airline Distance Method is used. If coordinates are not available for both activities, the Default Travel time is used.

  • If neither Statistical Learned estimation nor Airline Distance Method is available, the Default Travel time is used. The Default Travel time is a single configuration at the company level.

Additional adjustments

After routing is performed, the application may adjust Travel Time further for activities that are pending and ordered on a route. This adjustment may occur when the application is unable to find a Statistical “Learned" record that matches the pair of Travel Keys in these cases:
  1. When only the Airline distance method is used.
  2. When the "default" value is used.
When either of the above occurs, the application attempts to adjust travel time using two methods:

  • Generate “actual travel" data: The application submits the origin and destination addresses to the Oracle Spatial and Graph Route Server, if the accuracy level of each activity = “address”. The application calculates the travel time between the activities, adds the results to the temporary statistics, and recalculates the travel time on the route using the updated statistics.

  • Generate "street/post code level" estimate travel between post codes

    • This method requires post or zip code to be configured as the travel key.

    • The application submits the origin and destination post or zip codes to the Oracle Spatial and Graph Route Server and the application calculates the travel time between them. The returned information is used to improve the quality of the temporary statistics.

      Note: When the post code is the same for both the activities, this method is not used.
Temporary statistical travel data is calculated and used until real data is accumulated. This is accumulated as resources record travel between two locations based on the status of the activity. As soon as actual resources learned statistics are obtained, the temporary record is deleted. The Daily Extract - Appt data set contains the ‘travel_estimation_method’ field, which identifies what travel method was used for the travel time estimation. This field is only available in the Daily Extract file. These values can be present:

Values for the Travel estimation method field

Value Description
0 - travel is not calculated Travel is not calculated. This is not calculated because the Activity Type feature = “Calculate travel” is not selected.
1 - company default Travel estimation uses the company default found in “Configuration - Statistics”
2 - statistics only Travel estimation uses only the Statistical Learned estimation. This could be a result of an activity not being geocoded or the Coordinated Calculation Weight parameter set to 0.
3 - expansion statistics only Travel estimation is based on the expansion statistics. See 2A above for a definition.
4 - initial statistics only Travel estimation is based on the temporary statistics that were generated based on the results received from street level routing.
5 - coordinates only Travel estimation only uses the Airline Distance Method. This could be a result of an activity not having a physical address or the Coordinated Calculation Weight parameter set to 0.
6 - statistics + coordinates Travel estimation is based on a combination of the Statistical Learned estimation and Airline Distance Method using the ‘Coordinate calculation weight’ setting.
7 - expansion statistics + coordinates Travel estimation is based on a combination of expansion statistics and the Airline Distance Method using the ‘Coordinate calculation weight’ setting.
8 - initial statistics + coordinates Travel estimation is based on the statistics that were generated as part of the results received from street level routing and the Airline Distance Method using the Coordinate calculation weight setting.
9 - "manual" adjustment Travel estimation is based on the value that was updated using an API. This value can be set via Core API (update activity). For this goal, “manual” should be passed as a value of the “setTravelTime/source” field.
10 - "street level" adjustment Travel estimation uses the street level estimations provided by Location Services between coordinates of locations. This is used when you use SLR for Routing.
11 - "externally estimated value provided via API" adjustment Travel estimation is based on the value that was updated using an API. This value can be set via Core API (update activity). For this goal, “manual” should be passed as a value of the “setTravelTime/source” field.
12 - same location Travel was not calculated because the location is the same based on address or geocode. (Travel = 0)
13 - statistics (not-ordered, bucket, not-scheduled) Travel estimation only used the Statistical Learned estimation. In this case the origin location of the travel is still unknown and the application estimates an average traveling time value. A presence of these estimations is important for capacity management.
14 - company default value (not-ordered, bucket, not-scheduled) Travel estimation used the company default found in “Configuration - Statistics”. In this case the origin location of the travel is still unknown.
15 - GPS coordinates Travel estimation uses the Airline Distance Method between the GPS based location of the resource and the Activity location.
16 - Point to point adjustment Travel estimation is adjusted using point to point estimations provided by location services based on coordinates of locations.
17 - Real time traffic Travel estimation is adjusted using the real-time traffic data estimations provided by the location services, based on the activity coordinates or resource locations.
18 - Travel Key based Airline Distance Travel estimation uses the Airline distance based estimation using the coordinates of the medians of travel keys. This could be the result of a location not having valid coordinates and not having learned statistics between the locations.