One of the persistent frustrations in applied GIS work is the gap between the platform where analysis happens and the environment where decisions get acted on. You build something useful on a desktop, and then you have to figure out how to get it into the field, or into the next application in the workflow, or into the hands of someone who does not use the same software you do.

Geodata export formats exist to close that gap. GPX, KML, and GeoJSON are each open standards, each widely supported, and each optimised for slightly different use cases. The ability to move spatial data between platforms using these formats has become a basic expectation in professional geospatial work. What is interesting is watching that expectation migrate into specialist consumer applications — and what it reveals about the maturity of the users those applications are built for.

The HuntingNZ web map supports export in all three formats. For a hunting application, that is not a cosmetic feature. It is a signal about how that tool understands its users’ actual workflow.

GPX: Built for the Device in Your Hand

GPX — the GPS Exchange Format — is an XML schema designed specifically for GPS track, waypoint, and route data. It is the native language of handheld GPS devices and most outdoor navigation apps. Garmin devices read it natively. Coros and Suunto watches import it. Applications like Gaia GPS, Avenza Maps, and CalTopo use it as a standard exchange format.

For a hunter who plans a route in a web application and then needs to load that route onto a device they will carry into the field, GPX is the correct format. It carries the geometric data — coordinates and elevation — in a structure that GPS receivers are specifically designed to ingest. The planning session on a laptop translates directly into a loaded route on a wrist or a handheld, without re-digitising anything by hand.

The workflow this enables is meaningful. Planning in a rich desktop environment with multiple data layers and analytical tools, then exporting a clean route into field navigation software, is a significant improvement over either committing everything to memory or navigating purely from a phone with an active data connection.

KML: Built for Sharing and Visualisation

KML — Keyhole Markup Language, now an OGC standard — is the native format of Google Earth and Google Maps, and it carries more visual styling information than GPX. A KML file can specify the colour and icon of a placemark, the styling of a line, and the label associated with a feature. It is the format of choice when the goal is sharing spatial data in a way that retains some visual intent.

For hunters, KML is useful for sharing planned areas, glassing points, or camp locations with other members of a party. Google Earth handles KML natively, which means the recipient does not need any specialist GIS software to open the file and see the data in context. It is also a useful format for archiving — a KML file from a previous season retains not just coordinates but enough structure to be meaningfully re-examined in a mapping application.

From a GIS perspective, KML is not the most analytically flexible format. It was designed for visualisation, not for data interchange between analytical systems. But for the use cases it fits — sharing, presentation, Google Earth workflows — it fits well.

GeoJSON: Built for the Broader Ecosystem

GeoJSON is the most technically general of the three formats and the one most likely to matter to the segment of HuntingNZ’s users who have any GIS background. It is a JSON-based open standard for encoding geographic features, and it is the format of choice for web mapping, data analysis, and custom application development.

A GeoJSON file exported from a hunting map can be loaded directly into QGIS, ingested by a Python script using geopandas, consumed by a web mapping library like Leaflet or MapLibre, or pushed into a spatial database. It requires no conversion and no intermediary software. It is the format that speaks most naturally to the broader geospatial technology ecosystem.

For a hunting application to include GeoJSON export is an acknowledgement that some of its users are not just consumers of the tool but participants in a wider geospatial workflow. They may want to combine their hunting routes with other datasets, perform analysis that the hunting app does not offer natively, or build something custom for their own use.

Interoperability as a Design Philosophy

The decision to support all three export formats in a single application is not technically complex — these are well-specified open standards with mature libraries for generating them. But it reflects a design philosophy worth noting. A tool that locks its data inside a proprietary format treats its users as captive consumers of a single platform. A tool that exports to open standards treats its users as participants in an ecosystem.

The HuntingNZ map makes a clear choice in the second direction. Combined with its underlying reliance on LINZ, DOC, and Walking Access Commission data — all open government sources — it reflects the kind of open-data-first approach that the GIS community has been advocating for years, applied to a domain where it is still relatively rare.

For geospatial professionals, the interoperability story is the most technically interesting thing about a hunting map having these capabilities at all. For the hunter with a Garmin on their wrist and a route to plan, it is simply the feature that makes the tool worth using. Both perspectives are valid, and the best tools serve both at once. Explore the HuntingNZ map to see how all three formats work in practice.