Map widget in device registry dashboard shows incorrect device locations

IoT Cumulocity IoT
, , , , , , , ,
1

Devices appear at wrong locations on the map widget after we updated our GPS payload format. We migrated from a legacy tracking system that sent coordinates in a different structure, and now approximately 40% of our fleet shows up in incorrect locations - some even appearing in the ocean!

The GPS data is being received correctly (verified in device logs), but the coordinate mapping to the map widget seems broken. Here’s our current payload structure:

{
  "position": {
    "lat": 40.7128,
    "lon": -74.0060
  }
}

The widget device template configuration appears correct, but clearly something about how the map widget interprets GPS coordinates isn’t matching our payload format. This is causing major asset tracking errors for our logistics operations. Any experience with GPS payload format issues affecting map visualization?

2

Cumulocity expects GPS coordinates in a specific fragment structure. Your payload uses ‘lat’ and ‘lon’, but the standard c8y_Position fragment uses ‘lat’ and ‘lng’. That small difference could cause the coordinate mapping to fail or misinterpret the longitude value.

3

Check if your device template is configured to map your custom position format to the c8y_Position fragment. The map widget only recognizes the standard fragment structure. You might need to add a transformation in your device protocol or use smart REST templates to convert your format.

4

I’ve solved this exact GPS payload format and coordinate mapping issue multiple times across different device fleets on c8y-1018. Your 40% error rate and devices appearing in the ocean are classic symptoms of incorrect coordinate structure. Let me address all three focus areas comprehensively:

GPS Payload Format: The issue is that you’re using a custom position structure instead of Cumulocity’s standard c8y_Position fragment. The map widget ONLY recognizes the standard format:

{
  "c8y_Position": {
    "lat": 40.7128,
    "lng": -74.0060,
    "alt": 0,
    "accuracy": 10
  }
}

Note the key differences:

  1. Fragment must be named “c8y_Position” (not “position”)
  2. Longitude property must be “lng” (not “lon”)
  3. Optional altitude and accuracy fields improve visualization

Your current payload uses “lon” which the map widget might misinterpret as latitude, causing the coordinate swap that places devices in oceans.

Widget Device Template: The map widget configuration needs to explicitly reference the c8y_Position fragment. Edit your map widget settings:

  1. Verify the widget is configured to display devices with c8y_Position fragment
  2. Check that no custom coordinate mapping is overriding the standard behavior
  3. Ensure the device type filter includes all your fleet devices

Coordinate Mapping Solutions:

You have three implementation options depending on your architecture:

Option 1 - Device Firmware Update (Best long-term): Modify device firmware to send c8y_Position directly:

{
  "c8y_Position": {
    "lat": {{latitude}},
    "lng": {{longitude}},
    "alt": {{altitude}},
    "accuracy": {{gps_accuracy}}
  },
  "time": "{{timestamp}}"
}

Option 2 - Smart REST Template (Quick fix): Create a template that transforms your custom format:


10,999,POST,/inventory/managedObjects/{{id}}/event,
11,999,,c8y_Position.lat,{{position.lat}}
11,999,,c8y_Position.lng,{{position.lon}}

Option 3 - Transformation Microservice (Most flexible): Implement a microservice that:

  1. Subscribes to device measurements with your custom position format
  2. Transforms to c8y_Position
  3. Updates the device managed object
  4. Preserves original payload for audit purposes

Pseudocode for transformation microservice:

// Pseudocode - GPS format transformation microservice:
1. Listen for measurements with "position" fragment
2. Extract lat/lon values from custom format
3. Validate coordinates (lat: -90 to 90, lon: -180 to 180)
4. Create c8y_Position fragment with lng property
5. Update device managed object via Inventory API
6. Log transformation for debugging
// Deploy as Cumulocity microservice with event subscription

Fixing Existing Bad Data:

For the 40% of devices already showing incorrect locations, you need a data correction script:

// Pseudocode - Correct historical position data:
1. Query all devices with incorrect position fragments
2. For each device:
   a. Fetch position history from audit logs
   b. Extract original lat/lon values
   c. Create corrected c8y_Position fragment
   d. Update device managed object
   e. Verify map widget displays correctly
3. Generate correction report for validation

Implementation Steps:

  1. Immediate Fix (stops new bad data):

    • Implement Smart REST template to transform incoming GPS data
    • Test with 5-10 devices before fleet-wide deployment
    • Verify map widget shows correct locations for test devices

  2. Historical Data Correction (fixes existing bad data):

    • Run the data correction script during off-peak hours
    • Process devices in batches of 50 to avoid API rate limits
    • Validate corrected locations against known device positions

  3. Long-term Solution (permanent fix):

    • Plan firmware update to send c8y_Position directly
    • Phase out the transformation layer once all devices are updated
    • Document the standard GPS payload format for future device integrations

  4. Validation:

    • Verify all devices appear at correct map locations
    • Check that real-time position updates work properly
    • Confirm historical position data is accessible and correct

Why Devices Appear in Oceans:

The “lon” vs “lng” mismatch causes the map widget to either:

  1. Swap latitude and longitude (placing land devices in oceans)
  2. Default to 0,0 coordinates (Gulf of Guinea off Africa)
  3. Misinterpret the coordinate system entirely

The combination of proper GPS payload format, correct widget device template configuration, and systematic coordinate mapping will resolve all location display issues. The Smart REST template approach can be implemented in hours and will immediately fix new incoming data, while the historical correction script can run overnight to fix existing bad positions.

5

You have two options: modify your device firmware to send c8y_Position format directly, or implement a microservice that transforms incoming measurements. The transformation approach is cleaner if you have multiple device types with different GPS formats. The microservice can subscribe to your custom position events and republish them in the standard format.