Drawing delivery zones with KML

• KML zones
• geolocation checks
• webhooks on updates
• built with logistics

The problem

Deliveries only work where the service can actually reach. Knowing where that is, and keeping it accurate as the service area changes, is harder than it sounds. The logistics team needed to mark exactly which areas were being served, change them when things changed, and have every system that cared find out straight away.

Zones as KML

The tool was built around KML, the standard format for shapes on a map. The team marked the grids where the service was available, and each one was saved as KML.

Using a standard format meant the zones weren't locked inside one app. The same file opens in any common map tool, so zones could be checked visually and shared without converting anything.

Geolocation does the checking

With the zones in place, the question "is this location served?" became a geolocation check: take a location and see whether it falls inside one of the marked grids.

logistics team ──▶ map tool ──▶ KML grids
                                    │
location ──▶ geolocation check ◀────┘ ──▶ served / not served
                    │
                    └──▶ webhooks on location updates

A clean interface

The people using this were the logistics team, not engineers. So the interface was kept simple: see the map, mark or change a grid, save. Nobody had to edit a file or know what KML was.

Webhooks on every update

Zones and locations change, and the systems that depend on them can't wait for someone to tell them. The tool sent webhooks whenever a location was updated, so other systems heard about the change straight away instead of checking for it. That's what kept delivery zones accurate in real time.

Takeaway

Put the map in the hands of the people who know the ground, store it in a format every tool understands, and push changes out as they happen. A geofence is only accurate if updating it is easy and everyone hears about the update.