Due to national security concerns, the use of geographic information in the People's Republic of China is restricted to entities that obtain a special authorization from the administrative department for surveying and mapping under the State Council. Consequences of the restriction include fines for unauthorized surveys, lack of geotagging information on many cameras when the GPS chip detects a location within China, incorrect alignment of street maps with satellite maps in various applications, and seeming unlawfulness of crowdsourced mapping efforts such as OpenStreetMap.
According to articles 7, 26, 40 and 42 of the Surveying and Mapping Law of the People's Republic of China, private surveying and mapping activities have been illegal in mainland China since 2002. The law prohibits
publishing, without authorization, significant geographic information and data concerning the territorial air, land and waters, as well as other sea areas under the jurisdiction of the People's Republic of China.— The National Administration of Surveying, Mapping and Geoinformation of China, Surveying and Mapping Law of the People’s Republic of China
Between 2006 and 2011, the authorities pursued nearly 40 illegal cases of mapping and surveying. The media has reported on other cases of unlawful surveys:
As a consequence, major digital camera manufacturers including Panasonic, Leica, FujiFilm, Nikon and Samsung restrict location information within China.
Technical spatial processing must be applied to electronic navigational maps prior to publication, sales, redistribution, and usage.— GB 20263―2006 "Basic security processes for electronic navigational maps", 4.1
Chinese regulations mandate that approved map service providers in China use a specific coordinate system, called GCJ-02. Baidu Maps uses yet another coordinate system - BD-09, which seems to be based on GCJ-02.
GCJ-02 (colloquially Mars Coordinates, officially Chinese: 地形图非线性保密处理算法; literally: 'Topographic map non-linear confidentiality algorithm') is a geodetic datum formulated by the Chinese State Bureau of Surveying and Mapping (Chinese: 国测局; pinyin: guó-cè-jú), and based on WGS-84. It uses an obfuscation algorithm which adds apparently random offsets to both the latitude and longitude, with the alleged goal of improving national security. There is a license fee associated with using this mandatory algorithm in China.
A marker with GCJ-02 coordinates will be displayed at the correct location on a GCJ-02 map. However, the offsets can result in a 100 - 700 meter error from the actual location if a WGS-84 marker (such as a GPS location) is placed on a GCJ-02 map, or vice versa. The Google.com street map is offset by 50–500 meters from its satellite imagery, while the Google.cn map is not. Yahoo! Maps also displays the street map without major errors when compared to the satellite imagery. MapQuest overlays OpenStreetMap data perfectly as well.
From the leaked code, GCJ-02 uses parameters from the SK-42 reference system. The parameters were used to calculate lengths of one degree of latitude and longitude, so that offsets in meters previously calculated can be converted to degrees for the WGS-84 input coordinates.
BD-09 is a geographic coordinate system used by Baidu Maps, adding further obfuscation to GCJ-02 "to better protect users' privacy". Baidu provides an API call to convert from Google or GPS (WGS-84), GCJ-02, BD-09, MapBar or 51ditu coordinates into Baidu or GCJ-02 coordinates. As required by local law, there is no API to convert into WGS-84, but open source implementations in R and various other languages exist.
GCJ-02 appears to use multiple high-frequency noises of the form , effectively generating a transcendental equation and thus eliminating analytical solutions.[original research?] However, the open-source "reverse" transformations make use of the properties of GCJ-02 that the transformed coordinates are not too far from WGS-84 and are mostly monotonic related to corresponding WGS-84 coordinates:
from typing import Callable # Represent coordinates with complex numbers for simplicity coords = complex # Coords-to-coords function C2C = Callable[[coords], coords] def rev_transform_rough(bad: coords, worsen: C2C) -> coords: """ Roughly reverse the ``worsen`` transformation. Since ``bad = worsen(good)`` is close to ``good``, ``worsen(bad) - bad`` can be used to approximate ``bad - good``. First seen in eviltransform. """ return bad - (worsen(bad) - bad) def rev_transform(bad: coords, worsen: C2C) -> coords: """ More precisely reverse the ``worsen`` transformation. Similar to ``rev_transform_rough``, ``worsen(a) - worsen(b)`` can be used to approximate ``a - b``. First seen in geoChina/R/cst.R (caijun 2014). Iteration-only version (without rough initialization) has been known since fengzee-me/ChinaMapShift (November 2013). """ eps = 1e-6 wgs = rev_transform_rough(bad, worsen) improvement = (99+99j) # dummy value while abs(improvement) > eps: improvement = worsen(wgs) - bad wgs = wgs - improvement return wgs
The rough method is reported to give some 1~2 meter accuracy for wgs2gcj, while the exact (fixed point iteration) method is able to get "centimeter accuracy" in two calls to the forward function.[note 1] Since the two properties ensure some basic functionality of the coordinate system, it is unlikely that the methods will change with new coordinate systems.[original research?] The BD-to-GCJ code works in a manner much like the rough method, except that it removes the explicitly-applied constant shift of ~20 seconds of arc on both coordinates first and works in polar coordinates like the forward function does.
The establishment of working conversion methods both ways largely renders obsolete datasets for deviations mentioned below.
The China GPS shift (or offset) problem is a class of issues stemming from the difference between the GCJ-02 and WGS-84 datums. Global Positioning System coordinates are expressed using the WGS-84 standard and when plotted on street maps of China that follow the GCJ-02 coordinates, they appear off by a large (often over 500 meters) and variable amount. Authorized providers of location-based services and digital maps (such as AutoNavi or NavInfo) must purchase a "shift correction" algorithm that enables plotting GPS locations correctly on the map. Satellite imagery and user-contributed street map data sets, such as those from OpenStreetMap also display correctly because they have been collected using GPS devices (albeit technically illegally - see Legislation).
Google has worked with Chinese location-based service provider AutoNavi since 2006 to source its maps in China. google.cn/maps (formerly Google Ditu) uses the GCJ-02 system for both its street maps and satellite imagery. However, the WGS-84 positions reported by a browser are depicted at the wrong positions. On the contrary, google.com/maps also uses GCJ-02 data for the street map, but does not shift the satellite imagery layer, which continues to use WGS-84 coordinates, with the benefit that WGS-84 positions can still be overlaid correctly on the satellite image (but not the street map). Google Earth also uses WGS-84 to display the satellite imagery.
Overlaying GPS tracks on Google.com Maps and any street maps sourced from Google.com via its API, will lead to a similar display offset problem, because GPS tracks use WGS-84, and Google.com maps use GCJ-02. The issue has been reported numerous times on the Google Product Forums since 2009, with 3rd party applications emerging to fix it. Data sets with offsets for large lists of Chinese cities existed for sale. The problem was observed as early as 2008, and the causes were unclear, with (misguided) speculation that imported GPS chips were tampered with code that caused incorrect reporting of coordinates.
Under One Country Two Systems, legislation in mainland China does not apply in Hong Kong and Macau SARs and there are no similar restrictions in the SARs. Therefore, the GPS shift problem does not apply. However, at the border between the SARs and mainland China, the data shown by online maps are broken where the shifted data and correct data overlap. This poses problems to users travelling across the border, especially visitors not aware of the issue.
wgs -= worsen(wgs) - baddone twice, with
badso that the first iteration is equivalent to a rough pass.
Articles 7, 26, 40 and 42