Skip to content

Provider Mappings

Introduction

The telematics ecosystem is highly fragmented, with each provider exposing data fields in their own proprietary formats and naming conventions. This fragmentation makes it difficult to integrate, compare, and analyze data across fleets using different providers. Provider mappings are essential for achieving interoperability, enabling organizations to unify data from multiple sources into a single schema. By standardizing field names, units, and structures, we can perform meaningful cross-provider analysis, benchmarking, and integration—crucial for both research and business operations.

This section shows how common SaaS telematics providers expose data fields, and how they map into the Telemachus Core schema.


Comparative Mapping

Provider Field Example Provider Telemachus Core Field Notes
latitude, longitude Geotab, Webfleet, Samsara position.lat, position.lon Consistent across providers
speed (kph) Geotab, Webfleet motion.speed_kph Units sometimes in mph → convert
heading / bearing Samsara position.heading_deg Optional in others
altitude Geotab (limited) position.altitude_m Often missing
fuelLevel (%) Geotab engine.fuel_pct May require OBD-II access
odometer (km) Webfleet engine.odometer_km Sometimes reported as miles
engineRpm Samsara engine.rpm Not always accessible
eventType (e.g. harshBrake) All 3 events[].type Severity often not provided
satelliteCount Samsara quality.num_satellites Rarely exposed by SaaS
hdop (none in SaaS) quality.hdop Typically absent
gyroX/Y/Z (none in SaaS) imu.gyro IMU data almost never exposed
accelX/Y/Z (none in SaaS) imu.accel Available only in raw device logs
ignitionOn / ignitionOff Geotab, Webfleet events[].type Mapped as events in Telemachus
harshAcceleration All 3 events[].type Severity/threshold varies
VIN Geotab, Samsara source.device_id Sometimes reported as separate field
driverId Samsara, Webfleet context.fleet.driver_id Sometimes unavailable or optional

Key Insights

  • Consistency issues: Field names and units vary widely across providers, requiring normalization.
  • Unit conversions: Speed and distance may be reported in either metric or imperial units and must be converted for consistency.
  • Missing quality/IMU data: GNSS quality (e.g., satellite count, HDOP) and IMU sensor data are rarely available via SaaS APIs.
  • Optional vs required fields: Some fields are always present (e.g., GPS), while others (engine, driver, quality) are optional or provider-specific.

Observations

  • Strong overlap: GPS position, speed, and events exist across all providers.
  • Partial overlap: Engine data (fuel, odometer, RPM) vary by provider and often need OBD-II integration.
  • Gaps: IMU and GNSS quality fields are almost never available via SaaS APIs.
  • Implication: Telemachus Core acts as a superset. Providers can fill what they have, and leave the rest empty.
  • Device-level detail: Teltonika (device-level integration) exposes more raw fields—including IMU and GNSS quality—compared to typical SaaS APIs, which are more limited in scope.

Conclusion

By mapping provider-specific fields into Telemachus Core, we achieve cross-provider interoperability.
Even if some providers expose only GPS + events, while others add engine data, the unified format makes datasets comparable and prepares the ground for Telemachus Completeness Score (TCS). This mapping supports both research—by enabling fair comparisons across providers—and business, by simplifying multi-fleet and multi-provider integration into a single analytics pipeline.