send location now error in china

[boommanpro]

When using the owntracks iOS app in China, the location reported by 'send location now' differs from the latitude and longitude reported by MQTT.

[ckrey]

Sent location now is transmitted the same way as other location messages (MQTT or HTTP).
Send location now uses the current location as shown on the map.

As we are not based in China you will have to provide some examples

[boommanpro]

mqtt
send location now
{ "_type": "location", "acc": 9, "alt": 41, "batt": 20, "bs": 1, "cog": 7, "conn": "m", "inregions": [], "inrids": [], "lat": 39.980035, "lon": 116.470433, "m": 2, "motionactivities": [ "stationary" ], "p": 99.628, "t": "u", "tid": "2F", "tst": 1754399511, "vac": 3, "vel": 0 }

move auto send
{ "_type": "location", "acc": 6, "alt": 41, "batt": 20, "bs": 1, "cog": 7, "conn": "m", "inregions": [], "inrids": [], "lat": 39.978731, "lon": 116.464319, "m": 2, "motionactivities": [ "stationary" ], "p": 99.628, "t": "t", "tid": "2F", "tst": 1754399488, "vac": 3, "vel": 0 }

@ckrey

[ckrey]

Which location do you think is the "correct" one?

Please share your settings (ignoreInaccurateLocations, locatordDisplacement, ...) with us.
And please share the log file containing the relevant timestamp and a few minutes earlier with us (via mail to support@owntracks.org)

[ckrey]

Maybe explained here.

[boommanpro]

I know that the map in China is special, but I sent the information from the same location, and there is a big difference in geographical position through two methods. Is there a difference in the implementation logic here? Where is this issue, and can I also help to fix it?

[ckrey]

Both locations are taken from iOS' Core Location framework, though the send location now uses the current user position from the Map Kit because it is updated more frequently while on screen.
I don't know what the issue is, there are no hints in the documentation. But I guess the Map does the corrections necessary for the Chinese Coordinate system.
No idea how to fix this or how to find out if my guess is valid.

[SirTypesALot]

I did some experimentation with this issue last year, the way it behaves is indeed sort of weird.

First of all, a quick context class. China's GIS providers uses a different coordinate system called GCJ-02 instead of the international standard WGS84. GCJ-02, also known as the Mars coordinate system, because it is a non linear coordinate system, meaning the distortion range and direction is different for each WGS84 coordinates that you try to plot on a Chinese map.

As for OwnTracks, the coordinates sent in a location update in the background uses the WGS84 system, while coordinates of location update sent manually uses GCJ-02. I don't know why the OS uses two coordinates system while in China.

With that being said, there are algorithms that can perform rough estimation and conversions between the two systems.

[Hmmmmmmmmmm]

Had the same issue on my end in mainland China, and I did some cross-checking against the iOS code and my OwnTracks logs.

I think the immediate issue is not random GPS drift or MQTT/GPX serialization. The app seems to publish/store exactly the CLLocation object it is handed. The discrepancy comes from different iOS location sources producing coordinates that behave like different coordinate systems in mainland China.

What I observed

Using my own logs, with exact coordinates redacted:

• Automatic/background updates align with WGS84.
• Coordinates that display correctly on OSM also align with WGS84.
• Foreground Send location now from the iOS map screen aligns with GCJ-02 in mainland China.
• The offset is deterministic: applying a WGS84 -> GCJ-02 transform to the automatic/background point lands within a few meters of the foreground sendNow point.
• Reported accuracy values are good, so this does not look like poor GPS accuracy.

I also triggered a fresh foreground Send location now event. The MQTT message had t: "u" and good accuracy, but the coordinate matched the GCJ-02-style cluster, not the WGS84 cluster. Exact lat/lon are redacted because they are my current location.

Code path discrepancy

From the iOS code, the foreground map screen Send location now uses MapKit:

CLLocation *location = self.mapView.userLocation.location;

Then it passes that location to:

[ad sendNow:location withPOI:poi withImage:image withImageName:imageName];

So this path is roughly:

MKMapView.userLocation.location
  -> ViewController sendNow
  -> AppDelegate sendNow
  -> publishLocation
  -> waypoint.lat/lon = location.coordinate

In mainland China, MKMapView.userLocation.location appears to behave like a GCJ-02 coordinate.

By contrast, automatic/background updates use LocationManager, which wraps CLLocationManager:

CLLocationManager didUpdateLocations
  -> LocationManager delegate newLocation/timerLocation/visitLocation
  -> publishLocation

Those points appear to be WGS84 in my logs.

Shortcut / app-intent sendNow also appears to use LocationManager, not MapKit:

[self sendNow:[LocationManager sharedInstance].location
      withPOI:nil
    withImage:nil
withImageName:nil];

So t: "u" alone is not enough to identify the coordinate system. A foreground map-screen manual send can come from MapKit/GCJ-02-like coordinates, while shortcut/user-activity manual send can come from LocationManager/WGS84.

POI path

The foreground POI paths appear to call the same ViewController sendNow:withImage:withImageName: method:

[self sendNow:ac.textFields[0].text withImage:nil withImageName:nil];

and photo POI eventually calls:

[self sendNow:poi.text withImage:jpg withImageName:imageName];

So foreground POI likely has the same MapKit-origin coordinate behavior in mainland China.

The POI intent path in the app delegate appears to use:

[LocationManager sharedInstance].location

so that path should behave like the LocationManager/WGS84 path.

Apple Maps vs OSM tradeoff

One important detail: although OSM is supported, the iOS app primarily uses Apple Maps, and Apple Maps has much better map detail in mainland China than OSM.

This creates a real tradeoff:

• If OwnTracks keeps all coordinates as WGS84:

  • OSM display works correctly in the iOS OSM mode and in the web UI/frontend.
  • But points can appear shifted on Apple Maps in mainland China.

• If OwnTracks uses GCJ-02-style coordinates in mainland China:

  • Apple Maps display in the iOS app works better, also, current POI (I guess geofences too) feature works.
  • But OSM/web UI display will look shifted unless the server/frontend converts back to WGS84 or becomes coordinate-system aware.

What is clearly problematic today is that the app can emit both coordinate systems for the same physical location, depending on whether the point came from foreground MapKit sendNow or background LocationManager. That produces fake jumps of around 500-600m in mainland China.

Suggested direction

For an immediate iOS-side patch, I think the priority should be consistency inside mainland China.

Since the iOS app display is primarily Apple Maps, one practical approach would be stick with coordinates used by the Apple Maps path to GCJ-02, including automatic/background LocationManager updates. That would mean the background LocationManager/CLLocationManager update path should be adjusted before publishing/storing, so it does not emit WGS84 while the foreground MapKit path emits GCJ-02-style coordinates.

In other words, instead of patching sendNow to use WGS84, we need to patch the background update to be using GCJ-02 coordination system as well. This would avoid the current mixed-coordinate track problem on the iOS app. Longer term, the server/web frontend probably needs a coordinate-system conversion/display feature for a unified experience:

I can help test a patch from mainland China if useful.

[naitsimp]

I’ve used OwnTracks in China before and didn’t notice this behavior.

From a design perspective, I think the most robust approach is to always use WGS84 as the single source of truth, regardless of location or app mode (manual, significant, move,...).

GPS inherently provides coordinates in WGS84.
In China, map providers use GCJ-02, which means coordinates must be converted for display, not for storage.

If OwnTracks starts publishing GCJ-02 coordinates in some cases, this introduces inconsistency. The same physical location could be stored in different coordinate systems depending on how the point was recorded. That would create artificial jumps and make downstream processing difficult.

In my setup, OwnTracks publishes positions via MQTT, which I store and later display on an OSM-based frontend. That system expects WGS84 coordinates. If positions from China are published in GCJ-02, they will appear shifted unless converted back—adding unnecessary complexity and potential inaccuracies.
This would effectively introduce a conversion chain like:
WGS84 → GCJ-02 → WGS84

Since the GCJ-02 transformation is not officially published, reverse conversions are only approximations and may introduce errors.

So I would suggest the following approach:

• Always store and publish positions in WGS84, regardless of location or app mode
• Do not mix coordinate systems in recorded/published data
• Convert to GCJ-02 only for display on maps, when needed (e.g. in China)

This keeps the raw data consistent and avoids long-term issues with mixed coordinate systems, while still allowing correct map display in China.