Chinese Map Navigation: A Guide to Chinese Map Apps and Services

Choosing between Chinese map providers is not simply a question of which map looks better or has the largest user base. For product teams building an application for mainland China, the mapping layer can affect geocoding, POI search, routing, coordinate handling, API availability, performance, and even the way users interact with the product.

The practical challenge is that a location is not always represented by the same coordinates across different mapping systems. A GPS device may provide WGS84 coordinates, while a Chinese mapping API may expect GCJ-02 or BD-09. If those systems are mixed without an explicit conversion step, a perfectly valid location can appear in the wrong place on the map.

This is why choosing chinese map providers should start with the product requirements rather than with a generic ranking. A navigation application, a logistics platform, a location-based marketplace, and an infrastructure-monitoring system can need very different capabilities from the same map API.

This guide compares AMap, Baidu Maps, and Tencent Maps from an application-development perspective, explains the coordinate systems developers need to account for, and outlines a practical process for testing a mapping integration before launch.

Why Apps in China Need a Local Map Provider

A local map provider becomes particularly important when maps are part of the application’s core workflow.

For a logistics product, the map may need to support address search, POIs, route planning, and live location updates. For an infrastructure platform, the most important feature may be displaying hundreds of company-owned sensors accurately. For a marketplace, search and proximity can matter more than navigation. A consumer application may only require map rendering, geocoding, and basic location search.

The right provider therefore depends on the actual use case.

Before comparing APIs, define:

• where the application will be used;
• which platforms it supports;
• whether users need maps, geocoding, POIs, routes, or all of them;
• where the application’s own location data comes from;
• which coordinate reference system that data uses;
• how much traffic the APIs are expected to handle;
• what happens if the primary mapping service becomes unavailable.

It is also useful to separate the application’s own geospatial data from the provider-specific map layer. Your database should store what a location means to the business, while the mapping integration should be responsible for converting and displaying that location in the format expected by a particular provider.

That separation becomes especially valuable when an application may need to switch providers later.

For teams starting a new map-based product, this work should begin with a clear business requirements analysis. The goal is to define the geography, platforms, map interactions, data sources, POI requirements, routing scenarios, and performance expectations before selecting an API.

AMap vs Baidu vs Tencent Maps APIs

The three providers most relevant to many China-facing applications are AMap (Gaode), Baidu Maps, and Tencent Maps.

They overlap in functionality, but their APIs and SDKs are not interchangeable. Each provider has its own authentication model, coordinate handling, services, documentation, quotas, and attribution requirements. Those details can also change over time, so production decisions should always be based on the current documentation and developer account configuration.

Capability	AMap	Baidu Maps	Tencent Maps
Map rendering	Web and mobile mapping APIs/SDKs	Web and mobile mapping APIs/SDKs	Web and mobile mapping APIs/SDKs
Geocoding	Available	Available	Available
Reverse geocoding	Available	Available	Available
POI search	Available	Available	Available
Route planning	Available through routing services	Available through route-planning services	Available through location and route services
Coordinate system	China mapping workflows use GCJ-02; coordinate conversion is provided for GPS and Baidu coordinates	BD-09 is the default for the Baidu Maps JS API; GCJ-02 can also be handled through the documented coordinate configuration	China mapping services use GCJ-02-based workflows; verify the exact input/output CRS for the selected Tencent API
API access	Developer account and API Key	Developer credentials and service-specific permissions	Developer key and service-specific access
Quotas and pricing	Service- and account-dependent	Service- and account-dependent	Service- and account-dependent
Best evaluated for	Geocoding, POIs, routes, map services, China-focused applications	Applications already aligned with the Baidu mapping ecosystem or BD-09	Products where Tencent's mapping and location services fit the required workflow

AMap’s current Web Service documentation covers geocoding, routes, POI search, autocomplete, geolocation, administrative divisions, and other geospatial services. Its documentation also requires developers to obtain a Web Service API Key before making requests.

For the current list of AMap Web Service capabilities, authentication requirements, and available APIs, see the AMap Web Service API documentation.

AMap also provides a coordinate-conversion API that accepts GPS, Mapbar, and Baidu coordinates and converts them into AMap coordinates. This makes the conversion step an explicit part of the integration rather than something that should be hidden inside application logic.

The exact conversion parameters and supported source coordinate systems are described in the AMap Coordinate Conversion documentation.

Baidu’s current documentation identifies BD-09 as the default coordinate system for the Baidu Maps JavaScript API. It also documents WGS84, GCJ-02, and BD-09 conversion and allows applications to configure GCJ-02 input where appropriate.

Baidu’s coordinate-system behavior and conversion options are documented in the Baidu Maps Coordinate System documentation.

Tencent should be evaluated in the same way: not as an abstract alternative, but against the exact APIs and SDKs the product will use. Before committing to the provider, verify current authentication requirements, available services, coordinate expectations, quotas, pricing, and attribution in Tencent’s developer documentation.

What should a provider PoC test?

A useful Proof of Concept should use the same dataset for every candidate.

Test whether each provider can:

• render the required geography;
• geocode the addresses your users actually submit;
• return the POIs your application needs;
• reverse-geocode known coordinates;
• calculate the required routes;
• accept the application’s source coordinate system;
• respond within the required latency range;
• handle the expected request volume;
• provide the required services under the selected account;
• meet attribution and usage requirements.

This produces a much more useful comparison than declaring one provider the universal winner.

OpenStreetMap is a different option

OpenStreetMap should not be placed in the same category as AMap, Baidu, and Tencent.

OSM is a geospatial data ecosystem rather than a Chinese commercial map API. Teams can work with OSM-derived data through third-party providers or their own infrastructure, depending on the requirements of the product.

The distinction between OSM data and the public OpenStreetMap tile server is particularly important.

OpenStreetMap data is available under its applicable open-data license, but the standard public tile servers are community-funded infrastructure with their own usage policy. The OpenStreetMap Foundation requires visible attribution, a valid identifying User-Agent, appropriate caching, and prohibits bulk downloading and offline prefetching. Availability is best-effort and does not provide a commercial SLA.

These requirements are defined in the OpenStreetMap Tile Usage Policy.

For a production application, this means that “OSM is free” is not a complete architecture decision. The team still needs to decide how tiles or vector data will be served, what licensing conditions apply, and whether the chosen infrastructure can support production traffic.

China Map Coordinate Systems Explained

Coordinate handling is one of the most common causes of incorrect map markers.

The key systems developers are likely to encounter are WGS84, GCJ-02, and BD-09.

WGS84

WGS84 is a global geographic coordinate reference system widely used by GPS and geospatial systems.

For example, a sensor or external service might provide:

longitude: 116.3912

latitude: 39.9075

CRS: WGS84

Those numbers identify a geographic location, but they do not tell a map API everything it needs to know. The receiving API must interpret the coordinates using the correct CRS.

GCJ-02

GCJ-02 is a coordinate system used by Chinese mapping services. It differs from WGS84, so WGS84 coordinates should not automatically be passed to a service expecting GCJ-02.

The important engineering rule is simple:

Every latitude/longitude value in the system should have a known coordinate reference system.

A database field containing only latitude and longitude is therefore incomplete from an integration perspective if the CRS is not documented.

BD-09

BD-09 is Baidu’s coordinate system. Baidu’s current documentation describes BD-09 as being based on GCJ-02 and states that the Baidu Maps API uses BD-09 by default for its domestic mapping APIs.

Baidu also documents conversion between WGS84, GCJ-02, and BD-09 and provides mechanisms for applications that work with GCJ-02 data.

This means that the same physical location can legitimately have different coordinate values in different mapping systems.

Why does a marker appear in the wrong place?

Imagine that a GPS device sends a location in WGS84:

Sensor → WGS84

The application then sends that coordinate directly to a map layer expecting BD-09:

WGS84 → Baidu map expecting BD-09

The numerical values are valid latitude and longitude values, but they describe different coordinate systems. The map therefore renders the marker at the wrong position.

The problem is not necessarily inaccurate GPS data. It can simply be a CRS mismatch.

The solution is to make the transformation explicit:

Source data

   ↓

Identify CRS

   ↓

Convert to provider CRS

   ↓

Send to map API

   ↓

Render marker

Do not assume that every Chinese provider requires exactly the same conversion pipeline.

Convert and Validate Coordinates

A robust implementation starts by documenting the CRS of every input and output.

For example:

External sensor

      |

      | WGS84

      v

Application backend

      |

      | coordinate transformation

      v

Provider-specific CRS

      |

      v

Map API

For an AMap integration, the official coordinate-conversion service accepts GPS and Baidu coordinates and converts them to AMap coordinates. For Baidu, the official documentation provides conversion functionality and also allows developers to configure GCJ-02 input for the JavaScript API.

This means that the application should not contain an unexplained chain such as “convert everything twice because Chinese maps are different.” The transformation should correspond to the actual source CRS and the target provider.

A reproducible validation scenario

Suppose a monitoring device reports:

Input:

116.3912, 39.9075

CRS:

WGS84

The test should not be “does the marker look approximately right?”

Instead:

1. Record the original coordinate and CRS.
2. Convert it using the selected provider’s documented method.
3. Record the resulting coordinate and CRS.
4. Display the converted point.
5. Reverse-geocode the displayed point.
6. Compare the returned address with the known physical location.
7. Repeat the same test with at least two additional locations.

Run the test in different parts of the target geography and include a location near the boundary of the application’s operating region.

The same process should be applied to POIs and route endpoints. A marker can be correct while a route or geocoded address is still affected by a different coordinate-handling assumption.

The goal is not to memorize a universal offset. There is no single fixed distance that can be safely applied to every location. The goal is to establish and test the transformation required by the actual provider and dataset.

Integrate and Test a Chinese Map API

Once the provider requirements and coordinate systems are clear, the implementation can follow a repeatable process.

Start with the product requirements

Define the application’s target geography, platforms, map features, data sources, coordinate systems, expected request volume, and required user interactions.

For example, a logistics application may need routing and traffic information, while an infrastructure-monitoring application may care much more about marker accuracy, clustering, search, and the ability to display large numbers of assets.

These requirements should also include the interface itself. Users need to understand markers, statuses, search results, routes, filters, loading states, and errors. For a map-heavy application, map interface design is therefore part of the product experience, not just a visual layer added after the API has been integrated.

Choose two providers for the PoC

Select two realistic candidates based on the requirements and run the same test cases against both.

For example:

100 known asset locations

50 real addresses

20 POIs

10 representative routes

The exact dataset should reflect the product rather than an artificial benchmark.

Configure API access

Create the required developer accounts, API keys, and permissions for the services being tested.

Do not assume that access to a map SDK automatically means that geocoding, POI search, routing, or other Web Services are enabled under the same conditions.

AMap’s current documentation, for example, requires a developer account and Web Service API Key for its Web Service APIs. Baidu likewise uses developer credentials and service-specific access controls.

Normalize coordinates in one place

Coordinate conversion should have a clearly defined responsibility in the application.

A useful architecture is:

This makes it easier to replace a provider later and prevents conversion logic from being duplicated across individual React components, API calls, or map markers.

Test geocoding, POIs, and routes independently

A map loading successfully does not mean the integration is ready.

Test the complete workflow:

Address → Coordinates

Coordinates → Address

Keyword → POI

POI → Coordinates

Origin + Destination → Route

Route geometry → Map

Use real addresses, real POI categories, and representative routes from the application’s target geography.

Measure real performance

Performance should be measured from the environment in which the product will actually operate.

Record:

Provider

Endpoint

Request type

Region

Request volume

Median response time

95th percentile

Error rate

Timeout rate

Quota errors

This matters particularly for applications that depend on live search, routing, or location updates. A map can perform well in development and still produce a poor experience under production conditions.

Define the fallback scenario

A map integration should also have a failure strategy.

Depending on the product, the fallback might be another provider, cached data, a simplified map view, a list-based representation, or a retry mechanism.

The important point is to define the degraded experience before the application depends on the provider in production.

Check Operational and Legal Constraints

Map integrations have operational and legal considerations, but they should not be reduced to universal claims about server location, company registration, or API access.

Requirements can depend on the provider, service, application architecture, data involved, deployment model, and applicable regulations.

Before production, review four areas.

Provider terms

Check the current terms for:

• commercial use;
• API access;
• attribution;
• caching and storage;
• redistribution;
• request limits;
• data retention;
• use of returned map data.

Data handling

Document which information is sent to the provider.

This can include:

• user locations;
• device locations;
• customer addresses;
• asset coordinates;
• search queries;
• identifiers associated with location requests.

The more sensitive the location data, the more important it is to understand the complete data flow.

Infrastructure

Instead of assuming that a particular hosting location is universally required, document the actual architecture:

User / device

      ↓

Application

      ↓

Map provider API

      ↓

Geospatial response

      ↓

Map interface

Then review the requirements applicable to that architecture.

Compliance

If the product handles sensitive geospatial information or is subject to specific Chinese regulatory requirements, involve the appropriate legal and compliance specialists.

The engineering team should document the data flows, providers, APIs, and infrastructure. Legal requirements should then be assessed against the actual product rather than a generic checklist copied from another application.

How JetRuby Solved NeptunusDetect Mapping Issues

NeptunusDetect is a water loss and leak detection application that helps users locate leaks and monitor water infrastructure.

During the project’s adaptation for the Chinese market, some sensors placed by Chinese distributors appeared in the wrong locations on the map. In the original project experience, some sensor locations appeared to be in a river even though the physical devices had been installed elsewhere.

The problem made it clear that the team could not simply connect an existing global map and assume that the client’s geospatial data would be interpreted correctly.

JetRuby approached the problem through a Proof of Concept. The client’s API was connected to different Chinese map providers so the team could compare how the same project data behaved across mapping systems.

The architecture also allowed the map provider to be switched. This made it possible to compare providers without rebuilding the entire application around one specific API.

For the mapping interface, the project used React and Leaflet. The team also used configurations for different Chinese map providers to accelerate the comparison and integration process. Coordinate-conversion tooling was used to adapt the client’s location data to the coordinate systems required by the selected mapping services.

The key lesson from NeptunusDetect is not that one provider is universally better than another. The important part is the validation process: use real project data, test several providers, make coordinate transformations explicit, and keep the mapping layer replaceable.

JetRuby’s portfolio currently describes NeptunusDetect as a water loss and leak detection application focused on helping users locate leaks in water systems. The project is a useful example of why map integration should be treated as a product and engineering problem rather than as a simple UI component.

You can read the full NeptunusDetect case study to see how the project was approached.

Which Provider Fits Your Use Case?

The best Chinese map provider depends on the application’s actual workflow.

Use case	Main requirement	What to test
Navigation	Routes, traffic, route geometry, latency	Representative routes and route recalculation
POI-heavy application	Search quality, categories, geocoding	Real user queries and POI categories
Monitoring your own sensors	Coordinate handling and marker accuracy	Known coordinates across several regions
Global application entering China	CRS interoperability and API availability	The same feature set inside and outside China
Map-based enterprise web app	API limits, performance, UX	Realistic traffic and user workflows
Application using OSM-derived data	Data licensing and tile/vector infrastructure	The complete production data pipeline

For map-based products, choosing the right API is only one part of the product experience. Search, markers, filters, map controls, and the way users move between geographic data and other app functions can have an equally significant impact on usability. Our map-based web app UX case study shows how UX decisions can improve the experience of a complex web application.

For products with their own geospatial data, the strongest architecture is often one that separates the business location model from provider-specific mapping logic.

Your application should know that an asset belongs to a particular customer and has a particular physical location. The map adapter should know how to represent that location for AMap, Baidu, Tencent, or another provider.

That makes it easier to test alternatives and reduces the cost of changing providers later.

A Practical Map Integration Checklist

A China-facing map feature should be validated from requirements through production monitoring.

Product requirements

• Define the target geography.
• Define the supported platforms.
• List required map features.
• Identify the required POIs and routes.
• Document the application’s own geospatial data sources.
• Define the source CRS for every location dataset.
• Map the core user journeys around the map.

Provider selection

• Select two realistic candidates for the initial PoC.
• Review the current official documentation.
• Check API and SDK availability for the required platform.
• Obtain test credentials.
• Verify service-specific permissions.
• Check current quotas and pricing.
• Check attribution requirements.

Coordinate validation

• Identify the CRS of every input.
• Identify the CRS expected by every API.
• Define WGS84, GCJ-02, and BD-09 transformations where required.
• Test several known physical locations.
• Test forward and reverse geocoding.
• Test POI coordinates.
• Test route endpoints.
• Verify the rendered positions against known locations.

Performance and reliability

• Measure latency from the target environment.
• Measure error and timeout rates.
• Test realistic request volumes.
• Monitor quota consumption.
• Define retry behavior.
• Define a fallback or degraded experience.

Operational and legal review

• Review provider terms.
• Check commercial-use conditions.
• Check attribution requirements.
• Document the data sent to external providers.
• Review caching and storage rules.
• Review applicable privacy and geospatial-data requirements with the appropriate specialists.

UX validation

A technically correct map can still create a poor product experience.

Test whether users can quickly understand the map, find locations, distinguish important markers, search for addresses and POIs, interpret routes, recover from errors, and understand loading or unavailable states.

For map-based products, this is where map interface design becomes part of product development. The objective is not to use design as a replacement for engineering, but to make sure the technical mapping layer supports the workflows users actually need.

FAQ

Which map API should an app use in China?

There is no universal winner. Start with the application’s geography, platform, map features, data sources, coordinate systems, traffic expectations, and operational requirements. Then compare AMap, Baidu Maps, Tencent Maps, or another suitable provider through a PoC using real product data.

What is the difference between AMap and Baidu Maps APIs?

One of the most important differences is coordinate handling. Baidu Maps uses BD-09 by default for its JavaScript API, while AMap provides its own coordinate-conversion services and works with China-specific mapping coordinates. Their APIs, SDKs, authentication models, service availability, quotas, and attribution requirements also differ.

The practical way to compare them is to test the same addresses, POIs, coordinates, and routes against both.

Why do GPS markers appear shifted on Chinese maps?

A coordinate-system mismatch is a common reason.

GPS or another external system may provide WGS84 coordinates, while the selected map API may expect GCJ-02 or BD-09. Passing the original coordinates directly to the map can therefore result in a visibly displaced marker.

The correct solution is to identify the source CRS and convert the data according to the target API’s documented coordinate requirements.

How do WGS84, GCJ-02, and BD-09 differ?

WGS84 is a global geographic coordinate reference system commonly used by GPS systems. GCJ-02 is a coordinate system used by Chinese mapping services, while BD-09 is Baidu’s coordinate system based on GCJ-02.

Because the systems represent locations differently, the same physical point can have different numerical coordinates in each system.

Can I use Google Maps in a China-facing app?

Do not treat this as a universal yes-or-no rule.

The relevant question is whether the specific Google Maps product, API, application architecture, and target environment meet the application’s availability and operational requirements in mainland China.

For a production application, test the complete mapping workflow from the target environment and compare it with suitable local providers.

Can OpenStreetMap tiles be used in a commercial app?

OSM data and the public OpenStreetMap tile servers are not the same thing.

The OpenStreetMap Foundation’s public tile service has specific requirements for attribution, identification, caching, and request behavior. Bulk downloading and offline prefetching are not permitted, and the service is provided on a best-effort basis rather than with a commercial SLA.

For a production application, evaluate whether the public tile service is appropriate for the expected traffic. If it is not, use a suitable OSM-derived provider or infrastructure that is designed for the application’s requirements.

What should developers test before launching map features in China?

At minimum, test coordinate transformations, geocoding, reverse geocoding, POI search, routing, marker accuracy, API latency, error rates, quotas, attribution, data handling, and fallback behavior.

The tests should use real locations and realistic product workflows rather than checking only whether the map itself loads.

If you are building a map-based product for China, JetRuby can help validate the product requirements, mapping workflow, and user experience before development goes too far. Explore JetRuby UI and UX design services for map-based products.