Trip
This section describes the trip analysis API.
Description
The overall approach behind DriveQuant’s trip analysis service is based on vehicle dynamics and powertrain modeling. Using vehicle or smartphone sensors, our services estimate the efforts applied to the powertrain enabling us, for example, to remodel the efforts between the road and the wheels or to estimate the exhaust pollutants.
DriveQuant’s data analysis service delivers a wide range of indicators describing vehicle usage and driver behavior. For a single trip, DriveQuant’s trip analysis service retrieves:
eco-driving indicators,
an estimate of the fuel consumption,
safety indicators,
tire and brake wear measurements,
pollutant emissions estimation,
a distraction score (phone use),
and a speed limit score.
The trip analysis API is automatically requested by the DriveKit SDK at the end of each trip.
This API can also be used without the DriveKit SDK if you have your own GPS data collection system (OBD dongle, black box, vehicle data).
The distraction score (phone use) is only available for SDK users.
An additional cost is required for the use of the speed limit score, which is calculated using data coming from map data providers.
This section explains how to query the trip analysis API, how driving indicators are computed and how they are structured.
DriveQuant services provide additional data by collecting all vehicle trips so you can easily retrieve statistics for each of your vehicles. We recommend to add a new vehicle before requesting the trip analysis API if you target a vehicule mantenance use case.
Trip
POST
https://service.drivequant.com/v2/trip
This method returns all driving analytics calculated by DriveQuant for a trip.
Request Body
account
object
Identification data for the trip
route
object
GPS or vehicle recorded data for the trip
vehicle
object
Vehicle characteristics used for the trip
itineraryData
object
Data of the trip
metaData
object
Customer specific data
Request
Account
account
string
API key
userId
string
User unique identifier
vehicleId
string
Vehicle unique identifier
DriveQuant counts the number of active assets per customer. The DriveQuant API is a pay-per-active-asset API. An asset is considered active if it has performed at least one trip on a monthly basis. An asset can be a driver (identified with its driverId) or a vehicle (identified by a vehicleId).
Three main use cases can be considered:
The request includes only a driverId: This is common when the data collected comes from a mobile application installed on a driver's phone. The total number of assets per customer is equal to the number of unique driverId's.
The request includes only a vehicleId: This is common when the data collected comes from a telematics device plugged into the vehicle. The total number of assets per customer is equal to the number of unique vehicleId's.
The request includes a driverId and a vehicleId: This is common when a group of drivers can use several vehicle within a fleet. The total number of assets may be the number of unique vehicleId's or driverId's. Billing and counting will depend on your business model and the difference between the number of drivers and vehicles. Please contact DriveQuant sales department to find out the best pricing model.
The Account object must contain the account and the userId or vehicleId attributes.
Route
gpsVelocity
array[double]
GPS speed vector in km/h
latitude
array[double]
Latitude vector in degree
longitude
array[double]
Longitude vector in degree
gpsAccuracy
array[double]
GPS accuracy vector in meter
gpsElevation
array[double]
Elevation vector in meter
gpsHeading
array[double]
Heading vector in degree
gpsDate
array[double]
GPS timestamp vector in second
vehVelocity
array[double]
Vehicle speed vector in km/h
vehEngineSpeed
array[double]
Engine speed vector in rotation per minute
vehTankLevel
array[double]
Fuel tank volume in liter
vehWheelAngle
array[double]
Steering angle vector in degree
batteryVoltage
array[double]
Measurement of the car battery voltage vector in volt
vehDate
array[double]
Vehicle date timestamp vector in second
A request must contain all the data corresponding to a single trip. The trip data analysis cannot be cut into multiple queries. It is not recommended to merge data from several trips into a single request.
Route object must contain at least the vehDate or gpsDate and at least gpsVelocity or vehVelocity attributes.
The input variables included into Route object are arrays which must contain the same number of data points.
The sample period for all input vectors must be 1 second. The sampling frequency of 1Hz is a standard for GPS sensors. in case your telematics device does not satisfy this constraint, please contact us to determine what alternative can be applied.
Vehicle
carTypeIndex
int
carEngineIndex
int
carPower
double
carMass
double
Vehicle mass in kg
carGearboxIndex
int
carConsumption
double
Combined fuel consumption [l/100km] measured during the New European Driving Cycle (NEDC)
carAutoGearboxNumber
int
Number of gear ratios for the automatic gearbox. This parameter is taken into account only if carGearboxIndex
is set to 1
Some parameters have a default value if not set, and a min and max limitations:
carTypeIndex
1 (compact)
-
-
carEngineIndex
1 (gasoline)
-
-
carPower
150
40
450
carMass
1400
700
3500
carGearboxIndex
2 (manual 5-speed)
-
-
carConsumption
4.5
3
20
ItineraryData
Itinerary object is optional.
startDate
date
Trip start date
Date format: YYYY-MM-dd’T’HH:mm:ss.SSSZ
endDate
date
Trip end date
Date format: YYYY-MM-dd’T’HH:mm:ss.SSSZ
departureCity
string
Name of the departure city
arrivalCity
string
Name of the arrival city
MetaData
Metadata can be used if you want to add some of your specific data in a trip. They can be added to the Trip API as a key/value object where the key and value have a String type
Example of JSON body request
Response
The table below summarizes the list of driving data analysis modules. The comments and itinerary statistics modules are included by default. All other modules are optional and can be combined as needed.
itinId
string
Trip unique identifier
status
boolean
true
if no problem, false
otherwise
comments
array[object]
itineraryStatistics
object
itineraryData
object
ecoDriving
object
advancedEcoDriving
object
fuelEstimation
object
advancedFuelEstimation
object
safety
object
advancedSafety
object
safetyEvents
array[object]
tireWear
object
brakeWear
object
pollutants
object
userId
string
unique id of the user
firstname
string
first name of the user
lastname
string
Last name of the user
endDate
string
End date of the trip
driverDistraction
object
distractionEvents
array[object]
callEvents
array[object]
speedingStatistics
object
speedingEvents
array[object]
energyEstimation
object
advancedEnergyEstimation
array[object]
Comment
errorCode
int
Error code
comment
string
Error description
Possible values are described here.
ItineraryStatistics
Itinerary Statistics module provides several indicators that characterize the trip conditions: the trip distance, the vehicle movement duration and the idle duration. We also compute the number of sub-displacements. A trip can be characterized as a succession of events either dictated by the driver’s will or by external factors. These events, called breakpoints, are indicated with black dots in the figure below. Each section of a trip between two breakpoints is called sub-displacement. The figure illustrates these concepts for a short trip with one traffic light (vehicle stopped) and one intersection with priority (vehicle deceleration followed by acceleration).
distance
double
Distance travelled in meter
speedMean
double
Mean vehicle speed in km/h
tripDuration
double
Total trip duration in second
drivingDuration
double
Vehicle movement duration in second
idlingDuration
double
Total duration of idling phases (vehicle stopped)
in second
drivingPercentage
double
Percentage of vehicle movement
idlingPercentage
double
Percentage of idling phases
subdispNb
in
t
Number of sub-displacements detected during the trip
meteo
int
day
boolean
true
if day, false
if night
weekDay
boolean
true
: Monday to Friday, false
: Saturday to Sunday
transportationMode
int
ItineraryData
startDate
date
Trip start date
Date format: YYYY-MM-dd’T’HH:mm:ss.SSSZ
endDate
date
Trip end date
Date format: YYYY-MM-dd’T’HH:mm:ss.SSSZ
departureCity
string
Name of the departure city
arrivalCity
string
Name of the arrival city
departureAddress
string
Departure full address
arrivalAddress
string
Arrival full address
Eco-driving
Description
Eco-driving module performs an analysis of the entire trip, characterized by a succession of events and road segments. The driving efficiency is computed by comparing the vehicle speed recorded with an optimal speed profile, for each segment. This calculation takes into account the actual driving conditions and a physical vehicle model that captures the inertial dynamics of the vehicle and the efficiency of the powertrain components. The eco-driving score ranges from 0 and 10, and is calculated by comparing the actual energy consumed during the trip with the energy that would have been consumed using the optimal speed profile. The best eco-driving score corresponds to the highest driving efficiency.
score
double
Eco-driving score (min: 0, max: 10). If trip is too short to be scored, score is set to 11.
scoreAccel
double
Score of the acceleration phases. If trip is too short to be scored, score is set to 6.
scoreMain
double
Score of the stabilized speed phases. If trip is too short to be scored, score is set to 6.
scoreDecel
double
Score of the deceleration phases. If trip is too short to be scored, score is set to 6.
stdDevAccel
double
Standard deviation of acceleration score
stdDevMain
double
Standard deviation of stabilized speed score
stdDevDecel
double
Standard deviation of deceleration score
energyClass
int
0: energy class A
1: energy class B
2: energy class C
3: energy class D
4: energy class E
Scores definitions
Acceleration, deceleration and speed maintain phases have a large impact on the vehicle’s fuel consumption. As a consequence, by comparing the real and the optimal speed profiles, eco-driving analysis module returns 3 key driving indicators.
The acceleration and deceleration scores range from -5 to +5. For a value of (-5), your acceleration or deceleration is too slow. For the highest value (+5) you are accelerating or decelerating too fast. A score of (0) indicates that your acceleration or deceleration perfectly matches with an eco-driving style.
The speed maintain score ranges from 0 to 5. The minimum value (0) indicates that the driver has an appropriate behavior and drives at a constant speed. On the other hand, if the driving analysis module detects an oscillating speed profile, this score increases. The highest value (+5) indicates that you can improve to keep a constant speed to reduce your fuel consumption.
These indicators will help you improve your driving efficiency and reduce your energy consumption. They can also illustrate the level of anticipation that the drivers should adopt to avoid harsh accelerations and brakings.
The numerical values of driving scores can be transformed into driving tips. The tables below give examples of content that can be returned to a driver based on the driving notes of a trip:
-5 to -4
Acceleration is too low
-4 to -2
Weak acceleration
-2 to 1
Good acceleration
1 to 3
Strong acceleration
3 to 5
Acceleration is too high
0 to 1.5
Good speed maintain
1.5 to 3.5
Irregular speed
3.5 to 5
Very fluctuating speed
-5 to -4
Deceleration is too low
-4 to -2
Weak deceleration
-2 to 1
Good deceleration
1 to 3
Strong deceleration
3 to 5
Deceleration is too high
The eco-driving analysis is performed for vehicle displacement greater than 100 meters and speed higher than 10 km/h. This avoids providing inaccurate driving scores during vehicle maneuvers (slow driving in traffic jams or in parking lots...). In that case, eco-driving analysis module returns the following error codes:
11 for the eco-driving score
6 for acceleration phase, stabilized speed phase and deceleration phase
Energy class
The energy class « energyClass » depends on the average fuel consumption of the vehicle. It positions the trip fuel consumption with respect to the average consumption of the vehicle.
Advanced eco-driving
ecoDrivingContext
array[object]
In order to provide fair scoring and to facilitate drivers comparison, the trip scores can be accompanied by road class scores. These scores are included in the EcoDrivingContext class into the Advanced Modules. This service differentiates 5 types of road conditions (contextId) to contextualize the driving scores:
0 - Traffic jam: This corresponds to vehicle displacements of less than 100 meters and performed with speeds below 10 km/h. In traffic jams, it is obviously not possible to improve your driving, that is why scoring are not provided for this type of road.
1 - Heavy urban traffic
2 - City
3 - Suburban
4 - Expressways
In case a road type is not included in the trip, the distance and duration percentages are equal to zero, the efficiency score is set to 11 and the driving scores (Accel/Main/Decel) are set to 6.
EcoDrivingContext
distance
double
Percentage of distance travelled in a road type
duration
double
Percentage of elapsed time in a road type
efficiencyScore
double
Eco-driving score
scoreAccel
double
Score of the acceleration phases
scoreMain
double
Score of the stabilized speed phases
scoreDecel
double
Score of the deceleration phases
contextId
int
Fuel estimation
Description
The fuel consumption is obtained from a backward computation based on a mathematical modeling of the vehicle and powertrain. Fuel consumption estimation asseses the mechanical traction power from the vehicle speed and mass. A power transfer is performed between each component of the powertrain to compute the engine torque. Finally, the engine torque combined with the vehicle speed help to process the fuel mass from an engine consumption map developed by IFPEN. This fuel mapping is adapted according to the vehicle parameters and is valid for any type of vehicle or fleet of vehicles.
This approach is particularly adapted to estimate real-driving fuel consumption which can be more than 20% above the homologation data provided by car manufacturers. The main advantage lies in the accuracy of the estimate that can reach 5% when all input variables are available and the vehicle parameters set. The estimation method accounts for the physical fuel characteristics. These parameters are listed below:
Gasoline
0.755
44
70.26
2.3340
Diesel
0.845
42
75.70
2.6866
Values calculated by fuel estimation module are described below:
co2Mass
double
co2Emission
double
fuelConsumption
double
Average fuel consumption per unit of distance in l/100km
fuelVolume
double
Total fuel consumption in liter
idleFuelPercentage
double
Idle fuel consumption percentage
idleFuelConsumption
double
Idle fuel consumption per unit of time in l/h
idleCo2Emission
double
idleCo2Mass
double
engineTempStatus
boolean
Engine cold start?
coldFuelVolume
double
Cold engine fuel volume
Advanced fuel estimation
fuelEstimationContext
array[object]
In order to provide detailed fuel consumption estimation across the vehicle trips, the advanced fuel estimation service may return the fuel consumption for each driving context of the vehicle. This service differentiates 5 types of road conditions (contextId):
0 - Traffic jam
1 - Heavy urban traffic
2 - City
3 - Suburban
4 - Expressways
In case a road type is not included in the trip, the percentages of distance and duration are equals to zero as well as the co2Mass, co2Emission, fuelVolume and fuelConsumption.
FuelEstimationContext
contextId
int
Road conditions
distance
double
Percentage of distance travelled in a road type
duration
double
Percentage of elapsed time in a road type
co2Mass
double
co2Emission
double
fuelVolume
double
Total fuel consumption in liter
fuelConsumption
double
Average fuel consumption in l/100km
EnergyEstimation
For electric vehicles, DriveQuant provides energy information instead of fuel estimation.
energy
double
Estimated energy in kWh
energyConsumption
double
Estimated energy consumption in kWh/100km
energyOpti
double
Optimal energy in kWh
energyOptiConsumption
double
Optimal energy consumption in kWh/100km
The EnergyEstimation sub-document is only present in the response body for electric vehicles. If the configured vehicle is a conventional vehicle, the energy estimation is not added in the response body.
AdvancedEnergyEstimation
To provide more details on the energy consumption, the service may return the energy data for each driving context of the vehicle.
energy
double
Estimated energy in kWh
energyConsumption
double
Estimated energy consumption in kWh/100km
energyOpti
double
Optimal energy in kWh
energyOptiConsumption
double
Optimal energy in kWh/100km
contextId
int
Road conditions
distance
double
Percentage of distance travelled in a road type
duration
double
Percentage of elapsed time in a road type
The AdvancedEnergyEstimation sub-document is only present in the response body for electric vehicles. If the configured vehicle is a conventional vehicle, the energy estimation is not added in the response body.
Safety
safetyScore
double
Driver risk index for a given itinerary
Ranges from 3 to 10
nbAdh
int
Number of adherence threshold crossing
nbAccel
int
Number of strong accelerations
nbDecel
int
Number of strong decelerations
nbAdhCrit
int
Number of adherence threshold crossing (critical)
nbAccelCrit
int
Number of critical accelerations (critical)
nbDecelCrit
int
Number of critical decelerations (critical)
If trip is too short to be scored, safetyScore
is set to 11.
Advanced safety
safetyContext
array[object]
SafetyContext
distance
double
Percentage of distance travelled in a road type
duration
double
Percentage of elapsed time in a road type
safetyScore
double
Ranges from 3 to 10
nbAdh
int
Number of adherence threshold crossing
nbAccel
int
Number of strong accelerations
nbDecel
int
Number of strong decelerations
nbAdhCrit
int
Number of adherence threshold crossing (critical)
nbAccelCrit
int
Number of critical accelerations (critical)
nbDecelCrit
int
Number of critical decelerations (critical)
contextId
int
Road conditions
In case a road type is no included in the trip, the distance and duration percentages are equal to zero and the safety score is set to 11.
SafetyEvents
The data provided in the following table helps to display safety events on your map system and deliver the locations of harsh braking or acceleration as well as the coordinates where a tire to road adherence threshold has been crossed.
time
double
Time since the beginning of the trip in second
latitude
double
Latitude in degree
longitude
double
Longitude in degree
velocity
double
Vehicle speed in km/h
heading
double
Vehicle heading in degree
elevation
double
Altitude in meter
distance
double
Distance travelled since the beginning of the trip in meter
type
int
Type of event 1. Adherence 2. Acceleration 3. Braking
level
int
Intensity related to the event 1. Strong 2. Harsh
value
int
Absolute value of the event:
in m/s2 for acceleration and braking events
normalized between 0 and 1 for the adherence events
The service provides the time, coordinate and severity level of each event. Two levels of severity are calculated using specific threshold values for each event.
Acceleration
m/s2
2.0
2.5
Braking
m/s2
-1.8
-2.4
Adherence limit
-
0.2
0.3
Pollutants
co
double
Carbon monoxide (CO) emissions expressed in mg/km
hc
double
Hydrocarbons (HC) emissions expressed in mg/km
nox
double
Nitrogen oxide emissions (NOx) expressed in mg/km
soot
double
Soot emissions expressed in mg/km
Tire and brake wear estimates
Description
The wear analysis service has been designed to monitor the brake pads and tires wear levels. This service was designed to improve vehicle maintenance solutions and can be used to create maintenance alerts.
The wear estimation relates to the power dissipated in the tire - road or brake disc - brake contact. To compute this variable our service relies on the vehicle’s dynamic modelling that estimates the braking efforts and the efforts at the contact between the tire and the road.
For each trip, the service gives for each components (front/rear brakes/tires):
The worn mass fraction during the trip.
The total worn percentage since the installation of new tires or brakes.
Tire and brake wear indicators for a single trip
The wear analysis service measures tire wear and brake pad wear. The service allows to distinguish the front and rear axles of the vehicle. The wear is assumed to be the same for the right tire and the left tire of the vehicle. A similar assumption is made for the brake pads.
The output value corresponds to a mass fraction of the worn component (tire or brake pad). This value is expressed in thousandth part of parts-per-million (ppm) which is a unit equivalent to a parts-per-billion (ppb).
The worn mass fraction (tire or brake pad) is given for each individual trip. To obtain the total worn mass fraction, the sum of all the trip’s values must be done. The total worn mass fraction value is bounded between a minimum and a maximum value:
Minimum value = 0 ppb. If the total worn mass fraction is 0, the component (tire or brake pad) is assumed to have no wear.
The wear calculation service estimates for each trip:
The worn fraction of front tires
The worn fraction of the rear tire
The worn fraction of the front brakes
The worn fraction of the rear brakes.
Example of tire autonomy calculation:
where ω is the tire worn mass fraction for the trip i (in ppb) and di is the distance (in km) of the trip i. The wear function f(ω) is a decreasing function that goes from infinity to zero. When f(ω) equals zero, the tire has no longer autonomy and must be replaced. This function is displayed below:
Total tire and brake wear indicators
In order to facilitate the integration within a vehicle maintenance service, the DriveQuant API provides for all your requests the following set of data related to any component (tires or brakes):
The total distance traveled with a given component (Distance)
The level of wear of the considered component (TotalWear)
The remaining autonomy before a complete wear (Autonomy)
The average wear speed of the considered component (WearRate)
The total autonomy of the considered component is assumed to be equal to the total travelled distance plus the remaining autonomy (Distance + Autonomy).
The diagram below illustrates the principle and the meaning of these quantities. The figure shows the evolution of the wear as a function of the distance traveled with the component. This is a generic representation that applies to a brake pad or a tire.
The autonomy of a set of tires or brakes is calculated for each axle (front and rear). For example, the most worn tire between the left tire and the right tire on the same axle is used.
frontTireWear
int
Worn mass fraction of the front tires (right/ left) for current trip
Unit : thousandths part of ppm = ppb
rearTireWear
int
Worn mass fraction of the rear tires (right/left) for current trip
Unit : thousandths part of ppm = ppb
frontBrakePadWear
int
Worn mass fraction of the front brakes (right/left) for current trip
Unit : thousandths part of ppm = ppb
rearBrakePadWear
int
Worn mass fraction of the rear brakes (right/left) for current trip
Unit : thousandths part of ppm = ppb
frontTireDistance
int
Total distance analyzed for the front tires (in km)
Min. value = 0 / Max. value = 1 000 000
rearTireDistance
int
Total distance analyzed for the rear tires (in km)
Min. value = 0 / Max. value = 1 000 000
frontBrakeDistance
int
Total distance analyzed for the front brakes (in km)
Min. value = 0 / Max. value = 1 000 000
rearBrakeDistance
int
Total distance analyzed for the rear brakes (in km)
Min. value = 0 / Max. value = 1 000 000
frontTireAutonomy
int
Front tires remaining distance before change (in km)
Min. value = 0 / Max. value = 1 000 000
rearTireAutonomy
int
Rear tires remaining distance before change (in km)
Min. value = 0 / Max. value = 1 000 000
frontBrakeAutonomy
int
Front brakes remaining distance before change (in km)
Min. value = 0 / Max. value = 1 000 000
rearBrakeAutonomy
int
Rear brakes remaining distance before change (in km)
Min. value = 0 / Max. value = 1 000 000
frontTireTotalWear
double
Total worn mass percentage of the front tires (right/left)
Min. value = 0% / Max. value = 100%
rearTireTotalWear
double
Total worn mass percentage of the rear tires (right/left)
Min. value = 0% / Max. value = 100%
frontBrakeTotalWear
double
Total worn mass percentage of the front brakes (right/left)
Min. value = 0% / Max. value = 100%
rearBrakeTotalWear
double
Total worn mass percentage of the rear brakes (right/left)
Min. value = 0% / Max. value = 100%
frontTireWearRate
double
Average wear rate for the front tires (in %/1000 km )
rearTireWearRate
double
Average wear rate for the rear tires (in %/1000 km )
frontBrakeWearRate
double
Average wear rate for the rear brakes (in %/1000 km )
rearBrakeWearRate
double
Average wear rate for the rear brakes (in %/1000 km )
The wear rate measures the component wear (in %) as a function of distance. This variable allows to compare vehicles and to inform a vehicle fleet manager whose components are wearing out too quickly. The wear rate is related to the type of vehicle, the driving style, the type of road used and the driving condition. This is why its value can change if the typology of trips changes and if the vehicle is driven by several drivers who have different driving styles.
Driver distraction (score)
Distracted driving becomes a serious problem and is becoming a major road safety issue.
That's why we've developed a service that measures the driver's interactions with his smartphone while driving. The objective is to increase driver awareness through a distraction score. This can be used to compare drivers, to classify them or to organize driving challenges.
The DriveKit SDK is capable of measuring the two main indicators of distracted driving:
screen unlocks,
and outgoing or incoming (and answered) phone calls.
The distraction score depends on 2 parameters :
the smartphone unlocking frequency;
the total duration of the call (or calls if there are several in the same trip).
Each parameter is giving a sub-score from 0 to 10. The distraction score is the minimum between these two sub-scores.
The sensitivity function linking the number of unlocks per 100 km to the unlock score is shown below.
The sensitivity function linking the call duration to the call score is shown below.
This service is only available with the DriveKit mobile SDK.
The response body includes the trip scores as well as detailed data related to unlocks and calls. This way you can better understand the score construction and provide clear explanations to the driver.
The data returned by the service are listed in the table below:
nbUnlock
int
Number of phone screen unlock events
nbLock
int
Number of phone screen lock events
distance
double
Relative distance traveled with the screen on (in %)
distanceM
double
Distance traveled with the screen on (in m)
duration
double
Relative duration traveled with the screen on (in %)
durationS
double
Duration traveled with the screen on (in s)
score
double
Phone distraction score (Min. value = 0, Max. value = 10)
scoreUnlock
double
Distraction sub-score which takes into account the number of locking/unlocking
scoreCall
double
Distraction sub-score which takes into account the number of calls during the trip
calls
array[object]
Call
The Driver distraction score provides an array with all the calls answered or made by the driver. For each call, it contains information about its conditions.
id
int
Unique identifier of the call
start
double
Seconds from beginning of the trip when call starts
end
double
Seconds from beginning of the trip when call ends
durationS
double
Duration traveled in call (in s)
duration
double
Relative duration traveled in call (in %)
distanceM
double
Distance traveled in call (in m)
distance
double
Relative distance traveled in call (in %)
status
string
INCOMING : incoming call
OUTGOING : outgoing call
UNKNOWN : unknown call status
audioSystem
string
Audio system used to make the call (SPEAKER, LOUDSPEAKER, A2DP, HANDSFREE, HEADPHONE, CAR_AUDIO, UNKNOWN)
forbidden
boolean
true
if the call is forbidden
false
if the call is authorized (made with handsfree)
Response body example
Example of use
The screenshot below shows how to display the phone use data on a mobile phone interface:
Driver distraction (events)
The distraction score service provides additional information related to screen unlock and screen lock events. Thus, it is possible to get the location of events related to phone use. These informations are useful if you need to display these data on your mapping system or if you want to perform advanced data analysis.
The table below lists all the data returned by the service:
time
double
Time since the beginning of the trip (in s)
latitude
double
Latitude (in deg)
longitude
double
Longitude (in deg)
velocity
double
Vehicle speed (in km/h)
heading
double
Vehicle heading (in deg)
elevation
double
Altitude (in m)
distance
double
Distance travelled since the beginning of the trip (in m)
type
int
Type of event : (1) Screen ON and (2) Screen OFF
Response body example
CallEvents
Thanks to the distracted driving analysis service, you will be able to obtain contextualized and geolocalized data related to the detected events. This information is of great importance for the evaluation of the road risk and to help the driver to improve (by presenting this information on a map for example).
time
double
Time in second since the beginning of the trip
latitude
double
Latitude in degree
longitude
double
Longitude in degree
velocity
double
Vehicle speed in km/h
heading
double
Vehicle heading in degree
elevation
double
Altitude in meter
distance
double
Distance travelled during the call in meter
type
int
3: Call start
4: Call end
duration
int
Call duration in seconds
index
int
Position of the beginning of the event in the route date (phone call beginning of phone unlocking)
audioSystem
string
Audio system used to make the call (SPEAKER
, LOUDSPEAKER
, A2DP
, HANDSFREE
, HEADPHONE
, CAR_AUDIO
, UNKNOWN
)
callType
string
Call type
Allowed values: INCOMING
, OUTGOING
, UNKNOWN
forbidden
boolean
true
if the call is forbidden
false
if the call is authorized (made with handsfree)
Response body example
Speed Limit
This service measures distance and driving time when the vehicle speed exceeds the speed limit.
From this information, a speed limit score is calculated. The speed limit score is 10 if the overspeed distance is zero. The speed limit score decreases with the increase in the percentage of distance spent in overspeeding.
The sensitivity function linking the relative speeding distance (in %) with the speeding score is shown below.
This service returns a global (or trip) score for the entire trip as well as several sub-scores corresponding to each of the legal speed portions traveled during the trip.
The global (or trip) score is the average of the sub-scores weighted by distance.
distance
int
trip distance (m)
duration
int
trip duration (s)
speedingDistance
int
Distance travelled at a speed above the limit (m)
speedingDuration
int
Duration spent at a speed above the limit (s)
score
double
Speeding score
speedLimitContexts
array[object]
SpeedLimitContexts
speedLimit
int
Speed limit (in km/h) for the portion of the trip
distance
int
Total distance (in m) for the portion of the trip limited at the speed limit value
duration
int
Total duration (in s) for the portion of the trip limited at the speed limit value
speedingDistance
int
Distance travelled at a speed above the limit (in m) within the speed limit portion
speedingDuration
int
Duration spent at a speed above the limit (in s) within the speed limit portion
score
double
Speeding score for a given speed limit portion
Response body example
SpeedingEvents
The service that computes the speeding score also returns location-based information about overspeeding events.
This type of information is used to indicate on a map the places on the trip where the speed of the vehicle exceeds the speed limit.
The start and end positions of overspeeding segments are included in the SpeedingEvents table.
time
double
Time in second since the beginning of the trip
latitude
double
Latitude in degree
longitude
double
Longitude in degree
type
int
1 = Overspeeding segment start point
0 = Overspeeding segment endpoint
index
int
Index of the speeding event in the matched route vector.
Response body example
Last updated