Background
GNSS raw outputs are mostly WGS‑84. Domestic public map services generally use the GCJ‑02 encrypted by the National Surveying and Mapping Bureau (commonly known as Mars coordinates), which has a nonlinear deviation of several hundred meters from WGS‑84. If you directly overlay module WGS points on a GCJ map, noticeable misalignment will occur. Some fields also have local variants like BD‑09.
Engineering Processing
Perform coordinate conversion uniformly on the server or within the SDK; legally, algorithms and interfaces approved by the competent authorities should be used. Geofencing determinations must be carried out within the same coordinate system.
Cross-Border
Overseas maps use WGS without offset, and cross-country vehicle trajectory stitching needs to be processed segment by segment.
Implementation Details and Accuracy
Coordinate transformation is not a simple linear translation; the offset varies with geographic location. Using official or authorized algorithm libraries is necessary for batch conversion. When the server caches conversion results, boundary effects must be considered, as errors may be amplified near provincial borders and maritime areas. Regarding elevation, ellipsoidal height differs from normal height. Engineering surveying and hydraulic scenarios require a geoid model. When modules output NMEA and mix fields from different coordinate systems, integration issues easily arise, so CRS and version should be explicitly marked at the protocol layer.
Compliance, surveying, and data outbound
Public display and storage of geographic information must comply with surveying and data security regulations. Using unreviewed foreign base maps and coordinate transformation interfaces carries compliance risks. For cross-border fleets, trajectory data transfer must be evaluated and anonymized. E-fence and law enforcement evidence scenarios require traceability of coordinates and timestamps. Original observations and conversion parameters should be saved in logs to avoid irreproducibility in disputes.
Engineering Practice Supplement
Cross-team collaboration on "domestic coordinate systems": hardware provides impedance and power budget, RF provides spurious and sensitivity margin, embedded clarifies thread model and storage lifespan, cloud specifies SLA and rate limiting. For NB-IoT and similar scenarios, the business model should match wake-up cycles, packet length, and downlink capacity; for vehicular and mobile scenarios, session continuity during handover and roaming must be considered. At project closure, conduct a "red team" style review: ensure defined behaviors exist for weak networks, power loss, certificate expiration, clock jumps, and full storage.
A geofence and a point must use the same coordinates
The coordinate problem in China is that the Earth-centered coordinates from a satellite receiver and the encrypted coordinates on a public map are not the same numbers. Modules commonly output WGS-84. Map tiles commonly use offset GCJ-02, and some services add another local variant on top. Plotting a raw point directly on an encrypted map misses by a stable distance, and that distance changes with location. It is not one constant for the whole country. The condition is that storage, display, and geofence tests name the coordinate system all the way through, that conversion happens in exactly one layer, and that the original observation is still kept.
If a geofence is drawn in encrypted coordinates and the reported point is still raw, a vehicle enters and leaves the boundary repeatedly. When the server caches a conversion, shift by the point, not by a single offset for an administrative region. Near a provincial border, a coastline, or a survey control point, the nonlinear offset is more obvious. Using a neighboring province’s sample error in place of the local error judges the point wrong.
Do not mix height datums or cross-border tracks
After the horizontal coordinates line up, height can still disagree. Ellipsoidal height and orthometric height differ by the geoid. Water and engineering surveys cannot treat a satellite height as elevation. If some protocol fields are raw and others are already converted, but none carries a name, someone in integration will use the wrong one. Put a coordinate-system identifier and a conversion version on every position record.
Once a track leaves the country, public maps no longer use the domestic offset. A cross-border track has to be converted in segments. One algorithm cannot run the whole polyline. A coarse position from assisted positioning has to use the same datum as the map; see A-GNSS assistance. When a tunnel switches to dead reckoning, the reckoned coordinates must carry the same name as the satellite points, or the correction instant shows a false jump. See vehicle dead reckoning.
An offset measured in one city does not cover the province
A bias measured in one city cannot be added as the same constant for the whole province. The encrypted offset changes with longitude and latitude. The east and west ends of a province are not the same. Batch conversion needs an algorithm that changes with position, and raw points near the boundary should be checked again. The geofence vertices themselves have to be converted. Converting only the reported points, and not the fence, still judges entries and exits wrong. A sample check should keep both the raw coordinate and the converted coordinate, so a later algorithm change can be replayed, rather than keeping only the final point. When replaying an old track, use the conversion version from that time. Do not recompute historical points with today’s algorithm.