Independent review of Uber’s public H3 project. The delivery business, sample counts, and rollout plan are illustrative. H3 is a location indexing tool; a complete dispatch and route-planning application needs additional systems.
1. Turn address records into an operating question
A delivery or field-service business may have many location records but no consistent way to compare demand between areas. Postcodes vary in size, map pins overlap, and arbitrary rectangles can hide neighborhoods that need attention. Start with a decision such as where to add a delivery slot or how to review an underserved area.
Uber’s public H3 repository describes a hierarchical geospatial indexing system based mainly on hexagonal cells. A coordinate can be assigned a cell identifier at a chosen resolution, giving events a common spatial key for grouping and analysis.
The published H3 material establishes that indexing approach. It does not give us access to Uber’s private dispatch rules, current production architecture, or business results. This review applies the public concept to an original delivery-planning example.
2. Understand what the grid can and cannot do
H3 offers resolutions from 0 through 15, moving from coarse to fine cells. Its global grid also contains pentagons, and geographic containment across resolutions has important approximation details. Choose a resolution by the operating decision and the data quality, rather than assuming a finer map is always better.
Once events share a cell key, a reporting system can aggregate demand, completed visits, failed attempts, or service times by area and time window. Comparing these measures can reveal where a manager should investigate capacity or coverage.
An H3 cell is not a driving route, an exact legal territory, or a promise that two nearby addresses have similar travel times. Road networks, one-way restrictions, bridges, vehicle limits, and customer time windows still matter. Use routing and scheduling components for those decisions.
3. Plan a delivery analytics pilot
On small screens, scroll the table sideways to see every column.
| Input | Purpose | Check before use |
|---|---|---|
| Order or visit identifier | Connect a map event to its operational record | Repeated status messages must not become extra deliveries. |
| Latitude and longitude | Assign the location to a cell | Validate coordinate order, range, geocoding quality, and missing values. |
| Requested service window | Compare demand with capacity over time | Use an agreed local time zone and account for boundary times. |
| Outcome and duration | Review service performance by area | Define completed, failed, cancelled, and rescheduled consistently. |
Start with one operating area and a limited historical period. Produce an aggregate map that a dispatcher can compare with their experience. Keep customer-level details available only to authorized operational roles; a management heatmap usually needs less information.
A warehouse or ERP can remain the source of order status while a separate analytics service computes area measures. The integration needs shared identifiers and a refresh policy, not a replacement for every existing system.
4. Use sample counts without confusing them with capacity
Suppose a sample area has 120 requested deliveries in a day and four assigned couriers. The arithmetic average is 30 requests per courier. That is a workload indicator, not evidence that the schedule is feasible: one route may require far more travel or handling time.
- Group valid requests into the selected cells and service windows.
- Compare requested volume with available courier hours and observed service durations.
- Flag areas with uncertain locations, many failed attempts, or insufficient capacity for dispatcher review.
- Use an appropriate routing process to check any proposed reassignment.
If a point appears outside the expected service area, inspect its coordinates and geocoding result before changing coverage. If a cell has very few events, suppress or combine it in broad reports where appropriate. A precise-looking map can still be built from unreliable or identifying data.
5. Test the map against real operating boundaries
The pilot should include addresses near service borders, roads separated by rivers, incomplete addresses, swapped coordinates, and events around the daily cut-off. Confirm how the grid interacts with exact service polygons; a cell crossing a boundary does not authorize service at every point inside it.
Ask dispatchers to review the map alongside representative jobs. Record where the aggregate view supports a decision and where it needs street-level context. Keep the first release advisory so a mistaken grouping does not automatically alter a customer commitment.
The delivery package should include a data-quality report, cell resolution choices, metric definitions, permissions, and a way to trace an aggregate back to permitted source records. Agree who owns corrections and how a changed location is reflected in later reports.
6. Measure whether the view improves decisions
Useful measures include the share of jobs with usable coordinates, uncovered demand by service window, failed-attempt reasons, and planning time. If testing changes to delivery allocation, also examine travel and on-time performance under comparable conditions.
Seasonality, weather, traffic, and order mix can change those results. Establish a baseline and pilot boundary before attributing improvements to the map. This article reports no Uber savings or independently measured delivery gains.
A smaller business can begin with aggregate location reporting and manual review. Add automated dispatch only when location quality, business constraints, and recovery procedures are understood.
7. Frequently asked questions
Does H3 calculate the fastest delivery route?
No. H3 indexes locations into cells for spatial operations and analysis. Road routing, travel-time estimates, vehicle constraints, and scheduling require additional components.
Are all H3 cells identical hexagons?
No. The global grid includes pentagons and geometric variation. Resolution and containment behavior must be considered when using the grid for real business boundaries.
Can we publish a customer-level delivery heatmap?
Choose the detail appropriate to the audience and data obligations. Aggregate or suppress sparse areas when needed, and keep identifying customer or worker records restricted to authorized roles.