Coordinate Converter
| System | Precision | Typical use |
|---|---|---|
| WGS84 | ~0.1 m at 6 decimals | GPS devices, Google Maps, OSM |
| GCJ02 | ~0.1 m at 6 decimals | Amap, Tencent Maps, in-car nav |
| BD09 | ~0.1 m at 6 decimals | Baidu Maps |
How to Use
Overview
One building has three coordinate values: GPS devices report WGS84, Amap and Tencent use GCJ02, the encrypted national standard, and Baidu uses BD09. This tool returns all three plus the offset GCJ02 applies over WGS84, parses the input into degrees, minutes and seconds, computes 9 and 12 character GeoHash and a great-circle distance, and deliberately applies no offset to points outside China so overseas coordinates do not get shifted. A coordinate copied from a domestic map service into a GPS device sits a few hundred metres off until it is converted back, which is the most common source of mislocated points, and the offset figure shown beside the result makes that gap visible before it becomes a field problem. A swapped pair fails the range check at once. The offset is not a rounding artefact but a deliberate encryption of the national standard, applied through a piecewise polynomial, which is why the same coordinates from a phone and from a domestic map service differ by a few hundred metres. Converting back therefore needs iteration: the forward transform is smooth but has no closed inverse, so the tool perturbs the input until the forward result matches. Points outside the boundary keep their original values, which matters when a delivery route crosses a border and only part of the list should shift. The boundary test is approximate, so a point within a few kilometres of the frontier should be checked by hand.
Features
- All three systems at once, with the GCJ02 offset distance shown in metres
- Input accepted as decimal degrees, DMS such as 120°09′18.3″E, or space-separated numbers
- GeoHash at both 9 and 12 characters for mapping and regional aggregation
- Distance between two points by the Haversine formula, in metres and kilometres
- Batch mode takes one pair per line and exports six CSV columns including both geohashes
- Out-of-China points are detected: no offset is applied and the agreement is stated explicitly
How to use
- Fill in longitude then latitude, in that order
- Choose the source system: WGS84 from a GPS device, GCJ02 from Amap or Tencent, BD09 from Baidu
- Read the three results and the offset; the DMS line shows the sexagesimal form
- For distance, enter both points and press the calculate button
- Paste several pairs into the batch box and export CSV for spreadsheet work
Notes
- Each system has its place: GPS devices and most international maps report WGS84, Amap and Tencent use GCJ02, and Baidu applies BD09 as a second offset over GCJ02.
- GCJ02 shifts points only inside China and leaves overseas coordinates untouched, with offsets usually hundreds of metres and about 519.9 m at the built-in sample.
- Returning to WGS84 takes five iterations for centimetre accuracy, and longitude comes first; a swapped pair lands far away and the range check flags it.
- GeoHash uses base32 with longitude in the even bits, roughly 4.8 m at nine characters and 3.7 cm at twelve, while Haversine distance keeps long-range error near 0.5 percent.
- Projected systems such as UTM or Gauss-Kruger and elevation or geoid corrections are excluded; batch CSV keeps six columns plus the source system for traceability.
- DMS parsing accepts degree, minute and second marks as well as d m s letters, and missing parts default to zero; use a minus sign or S/W for south and west