--- title: 'Custom Airtable Map Interface with Mapbox, KML and GPX' description: 'Build a custom Airtable map interface using Mapbox that renders KML service areas and GPX routes — with native interface filtering and record linking.' canonical_url: 'https://www.business-automated.com/tutorials/airtable-custom-map-interface-mapbox-kml-gpx' md_url: 'https://www.business-automated.com/tutorials/airtable-custom-map-interface-mapbox-kml-gpx.md' last_updated: 2026-05-02 --- Airtable's built-in map view plots where your records are, but it cannot draw the boundary of a sales territory, render the path a delivery rider actually took, or show which service zones overlap a given order. The Airtable Interface SDK gives you the mechanism to go further. This tutorial covers a custom interface extension that connects [Airtable](/tools/airtable) to Mapbox and renders geographic data from two file formats your team is probably already collecting: KML for areas and GPX for routes. The result is a fully interactive map embedded inside your existing Airtable interface, respecting the same filters your team already uses. If you prefer working with an [Airtable consultant](/airtable-consultant) rather than building from scratch, the final section covers when to bring in outside help. ## Video Tutorial ## What KML and GPX Give You Before looking at the build, it is worth understanding why these two file formats are worth connecting to Airtable in the first place. **KML files define areas.** A KML (Keyhole Markup Language) file stores polygon coordinates that trace the outline of a region — a delivery zone, a sales territory, a construction site boundary, or a national park. Critically, KML files also embed styling: the fill colour and border colour you see in tools like Google Earth are stored inside the file itself. When Mapbox reads a KML file, it renders those embedded colours without any additional configuration on your part. **GPX files define routes.** A GPX (GPS Exchange Format) file records the actual path a person or vehicle followed, captured by a GPS device. This includes latitude, longitude, timestamp, and often elevation data at each point. Garmin watches produce GPX files. Field tracking apps produce GPX files. Vehicle telematics systems can export GPX files. Each file is a faithful record of where someone went and when. Together, these two formats answer questions that a simple pin-on-a-map never could: not just "where is the customer?" but "which service zone covers them?" and "what route did the technician take to get there?" ## Architecture of the Mapbox Interface The extension is built using the Airtable Interface SDK, which allows developers to write custom React components and embed them as blocks inside any interface page. This matters because it means the map sits within your existing interface layout — alongside your KPIs, list views, and summary fields — rather than being a separate standalone application your team has to navigate to separately. The data model that powers the extension uses three tables: - **Areas table** — each record represents a geographic zone. The key field is an attachment field containing the KML file for that zone, alongside descriptive fields like name, region, and any metrics you want to surface. - **Orders table** (or equivalent) — each record represents a job, delivery, or visit. It links to one or more areas and carries a GPX attachment recording the route taken. - **Configuration at the extension level** — the Mapbox API key is stored in the extension's custom properties panel, not in a table field. When you copy the base, you add your own token here. Within the extension settings, you map each field role: which attachment field contains KML, which contains GPX, and which text fields should appear in the popup when a user clicks a route. Once configured, the extension reads the current filtered record set from Airtable (honouring any filters the user has applied at the interface level) and passes those file URLs to Mapbox for rendering. ## Loading KML and GPX into Mapbox Layers Mapbox GL JS supports GeoJSON as its native vector format, but KML and GPX are not GeoJSON. The extension handles conversion client-side: when it retrieves an attachment URL from Airtable, it fetches the file, parses it, and converts the coordinate data into GeoJSON before passing it to Mapbox as a source layer. Each file becomes its own layer with an independent toggle. Areas and routes can be shown or hidden independently using the visibility controls built into the interface — useful when the map becomes visually crowded with both polygon fills and route lines overlapping. The layer styling for polygons inherits the colour definitions embedded in the KML file. This is a practical advantage: whoever created the territory boundaries in a mapping tool like Google Earth or ArcGIS has already done the colour design work. The extension reads those values directly instead of requiring manual theme configuration. A minimal example of how the extension registers an area as a Mapbox GeoJSON source looks like this: ```json { "type": "geojson", "data": { "type": "FeatureCollection", "features": [ { "type": "Feature", "geometry": { "type": "Polygon", "coordinates": [ [ [-0.1276, 51.5074], [-0.1376, 51.5074], [-0.1376, 51.4974], [-0.1276, 51.4974], [-0.1276, 51.5074] ] ] }, "properties": { "name": "Central Zone", "fillColor": "#3887be", "fillOpacity": 0.4 } } ] } } ``` The properties block carries the styling values parsed from the original KML, which Mapbox then applies via a layer paint expression. Route lines from GPX files follow the same pattern — converted to `LineString` features and rendered with a distinct stroke colour and weight. ## Filtering and Record Linking Back to Airtable One of the most practical aspects of embedding this extension inside an existing interface is filter inheritance. Airtable interface pages support native filter controls — dropdowns, date pickers, linked-record selectors — that scope the records visible to every component on that page. The custom map extension reads that scoped record set rather than all records in the table. In practice, this means a dispatcher can filter the interface to a specific delivery zone and see only the routes and areas relevant to that zone rendered on the map — without the extension needing any of its own filter UI. The interface filter does the work once, and all components respond. Clicking a route on the map opens a popup with the fields you configured during setup — in the demo, that is the rider's name and the date the route was recorded. The popup also contains a "View in Airtable" button. When clicked, it opens the full record detail page inside the interface using the Interface SDK's built-in record navigation. This requires granting the extension access to the relevant tables and permission to open other interface layouts within the base — both configured in the extension's settings panel, not in code. This bidirectional connection — Airtable records feeding map layers, and map clicks surfacing Airtable records — is what distinguishes an embedded interface extension from a standalone GIS tool. The data lives in Airtable. The map is a view into that data, not a separate system of record. ## Business Use Cases This pattern applies broadly across any operation that manages physical geography alongside its data. The use cases below reflect where we see the most immediate return. **Field service and workforce management.** Service companies that divide territory into zones for technician dispatch can store zone boundaries as KML files on area records. Dispatchers filter the interface by area and see which technician routes fall within or near the zone. This directly supports the workflows covered in our [field workforce management solutions](/solutions/field-workforce-management). For outside sales teams, the same logic applies — see our [field sales solutions](/solutions/service-field-sales). **Real estate.** Portfolio managers can map property catchment areas or prospect territories as KML polygons. Site visits recorded as GPX tracks give a geographic view of activity that a spreadsheet cannot replicate. Our [real estate solutions](/solutions/real-estate) go deeper on Airtable-based portfolio management. **Construction.** Site boundaries defined in KML give project managers a visual overview of all active sites without leaving Airtable. Crew movement exported as GPX can be attached to daily log records and reviewed against site boundaries. See how we approach [construction operations](/solutions/construction). **Logistics.** Delivery businesses already collect GPX route data from driver devices. Rendering those files against service-zone KML polygons gives operations managers a visual audit trail — when a delivery runs outside its assigned zone, that is immediately visible. **Tourism and outdoor experiences.** Tour operators can store guided route files as GPX attachments on tour records. Staff filtering by difficulty, region, or date see only relevant routes on the map, and clicking a route surfaces the booking record directly in Airtable. If you are assessing whether Airtable is the right platform, our overview of [what Airtable is and what it can do](/tutorials/what-is-airtable-omni) is a good starting point. For interface design fundamentals, read our guide on [building interfaces with Airtable](/tutorials/build-interfaces-with-airtable-omni). ## When to Hire Help The shareable base linked in the video is a working proof of concept. You can copy it, add your Mapbox API key, swap in your own KML and GPX files, and have a functional map inside your Airtable interface without writing a line of code. That approach has limits. The pre-built extension handles one area table and one route table with a fixed popup template. Multiple data layers, custom popup layouts, route-to-area intersection logic, colour rules driven by Airtable field values, or integration with live GPS feeds all require working in the Interface SDK directly. Consider bringing in a specialist when: - The map needs to drive downstream automations — for example, flagging when a route falls outside its zone and triggering a workflow in [Make](/make-automation-agency) - Your team needs role-based visibility, so dispatchers see all zones while riders see only their own - You want additional context layers such as customer locations alongside area polygons - The extension needs to write data back to Airtable on user interaction - You need a client-facing version embedded in a reporting dashboard — our guide on [Airtable client reporting dashboards](/tutorials/airtable-client-reporting-dashboards) shows what that looks like We build custom Airtable interface extensions at Business Automated, designed around your tables, workflows, and styling requirements. [Talk to our Airtable team](/airtable-consultant) to scope what your map interface needs. ## Next Steps If this tutorial has given you a clear picture of what a Mapbox-powered Airtable interface can do, here is where to go next: - Copy the base from the video description, add your Mapbox token, and verify your KML files render correctly before investing in customisation - Review your existing Airtable base for attachment fields that could carry geographic files — you may have more data ready to map than you realise - Read our [field workforce management](/solutions/field-workforce-management) and [field sales](/solutions/service-field-sales) solution pages to see how map interfaces fit a broader operational system - For construction site boundaries or crew tracking, explore our [construction solutions](/solutions/construction) page - For real estate applications, the [real estate solutions](/solutions/real-estate) page covers territory management and portfolio visualisation Geographic data already lives in your operations — in territory spreadsheets, driver app exports, and GPS device downloads. Connecting those files to Airtable and rendering them through a Mapbox interface is the step that makes that data actionable for the people who need to use it daily. ## Sitemap See the full [sitemap](/sitemap.md) for all pages.