KML vs GPX vs GeoJSON (and CSV): Which File Format for Land Boundaries?

You have measured a field, walked a fence line, or received a boundary from someone else, and now the file has to go somewhere: Google Earth, a GIS program, a GPS unit, or a spreadsheet. Four formats cover nearly all of these situations: KML (and its zipped form, KMZ), GPX, GeoJSON, and plain CSV. They overlap a lot, but each was designed for a different job, and the differences matter most in exactly the places that cause failed imports: coordinate order, how polygons are closed, and how numbers are written.

The short version

If you only remember one thing: for a land boundary, use KML or GeoJSON. For a walked or driven track, use GPX. For a list you want to read or edit in a spreadsheet, use CSV.

KML and KMZ

KML (Keyhole Markup Language) began as the file format of the Earth viewer that became Google Earth, and it is now an Open Geospatial Consortium (OGC) standard. It is XML, so it is readable in a text editor. Besides geometry it can carry names, descriptions, folders, colors, line widths, and icons, which is why it is the usual choice when a map has to look right in Google Earth.

Shapes live inside a Placemark. A boundary is a Polygon with an outerBoundaryIs ring and, optionally, innerBoundaryIs rings for holes. A line is a LineString.

The detail that trips people up is the <coordinates> element. Each position is written as longitude,latitude or longitude,latitude,altitude, with no spaces inside a position and whitespace between positions. Longitude comes first, which is the reverse of how most people say coordinates aloud. Altitude is in meters.

KMZ is not a different format. It is a zip archive containing a KML file (conventionally named doc.kml) plus any images or icons it refers to. Rename a .kmz to .zip and you can open it with any unzip tool. KMZ files are smaller and keep attachments together, which is useful for email.

GPX

GPX (GPS Exchange Format) is the common language of GPS receivers, hiking and cycling apps, and mapping software. It is also XML, and it knows three kinds of things:

• Waypoints (wpt): single named points, such as a corner marker or a gate.
• Routes (rte with rtept): an ordered list of points you plan to follow.
• Tracks (trk): where you actually went. A track is split into track segments (trkseg), each a list of track points (trkpt).

Every point stores lat and lon as attributes in decimal degrees on the WGS 84 datum, so order is not ambiguous. A point can also hold elevation (ele, in meters) and time (time, in UTC). Segments exist so that a track can have gaps: when a GPS loses signal or you pause recording, a new segment begins, and software should not draw a straight line across the gap.

GPX has no polygon type. A track that ends where it started looks like a boundary, but to GPX it is still a line. Use GPX for tracks and points, not for areas you want other software to treat as areas.

GeoJSON

GeoJSON is JSON for geography, standardized in RFC 7946. It is the native format of many web maps and is read by every mainstream GIS tool. A file holds geometries (Point, LineString, Polygon, and their Multi versions), usually wrapped in a Feature with a properties object for names and other attributes, and features are grouped in a FeatureCollection.

The rules worth knowing:

• Positions are [longitude, latitude], optionally with altitude as a third number. Like KML, longitude comes first.
• Coordinates are always WGS 84 decimal degrees. RFC 7946 dropped the older option of declaring other coordinate systems.
• A polygon is an array of linear rings. The first ring is the outer boundary, and any further rings are holes.
• Every ring must be closed: the last position repeats the first, so a four-cornered field has five positions.
• RFC 7946 says outer rings should run counterclockwise and holes clockwise (the “right-hand rule”), but it also tells readers not to reject polygons that wind the other way, for compatibility with older files.

CSV

CSV is the least formal option: rows of values separated by commas, usually with a header row naming the columns. There is no standard for how a CSV describes a shape. Some files have one row per point with latitude and longitude columns. Others use lat/lon, x/y (where x is longitude), or a single text column holding a whole shape. Point order is simply row order.

That flexibility is why CSV is great for spreadsheets and record keeping, and also why every CSV import needs a mapping step or a known layout.

The same square in each format

Here is one small square, about 100 m on each side near 40° N, 105° W, written four ways. The corners run counterclockwise: southwest, southeast, northeast, northwest. On the spherical Earth model its area is about 10,229 m², which is roughly 1.02 hectares or 2.53 acres.

KML. Longitude first, no spaces inside each position, ring closed:

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
  <Placemark>
    <name>Sample square</name>
    <Polygon>
      <outerBoundaryIs>
        <LinearRing>
          <coordinates>
            -105.0000,40.0000,0 -104.9988,40.0000,0 -104.9988,40.0009,0
            -105.0000,40.0009,0 -105.0000,40.0000,0
          </coordinates>
        </LinearRing>
      </outerBoundaryIs>
    </Polygon>
  </Placemark>
</kml>

GeoJSON. Longitude first, one outer ring, closed, counterclockwise:

{
  "type": "Feature",
  "properties": { "name": "Sample square" },
  "geometry": {
    "type": "Polygon",
    "coordinates": [[
      [-105.0000, 40.0000],
      [-104.9988, 40.0000],
      [-104.9988, 40.0009],
      [-105.0000, 40.0009],
      [-105.0000, 40.0000]
    ]]
  }
}

GPX. No polygon type, so this is a track that walks the square and returns to the start:

<?xml version="1.0" encoding="UTF-8"?>
<gpx version="1.1" creator="example" xmlns="http://www.topografix.com/GPX/1/1">
  <trk>
    <name>Sample square</name>
    <trkseg>
      <trkpt lat="40.0000" lon="-105.0000"/>
      <trkpt lat="40.0000" lon="-104.9988"/>
      <trkpt lat="40.0009" lon="-104.9988"/>
      <trkpt lat="40.0009" lon="-105.0000"/>
      <trkpt lat="40.0000" lon="-105.0000"/>
    </trkseg>
  </trk>
</gpx>

CSV. One row per corner, latitude before longitude because the header says so. The ring closes implicitly:

point_index,latitude,longitude
1,40.0000,-105.0000
2,40.0000,-104.9988
3,40.0009,-104.9988
4,40.0009,-105.0000

You can paste the CSV, KML, or GeoJSON version into the coordinates area calculator to check the area yourself.

Which format to use

Sharing a boundary with a neighbor, buyer, or agent. KML or KMZ. Google Earth opens it with a double-click, and the boundary keeps its name and outline.

Bringing a boundary into GIS. GeoJSON or KML. QGIS and other desktop GIS programs read both, and GeoJSON is the more natural fit for web maps and scripts. Polygons stay polygons, holes included.

A walked, driven, or flown track. GPX. It keeps elevation, timestamps, and segment breaks, and nearly every GPS device and outdoor app can read it.

Points for a spreadsheet, a report, or a quick check. CSV. You can sort, edit, and annotate it, and convert it later.

Pitfalls that break imports

Coordinate order

KML and GeoJSON put longitude first. GPX uses named attributes. CSV depends on its header. If an import fails with an out-of-range latitude, or the boundary lands in the sea or on another continent, latitude and longitude were probably swapped. Our guide to coordinate formats covers this and the related sign mistakes.

Unclosed or self-crossing rings

GeoJSON rings must repeat the first position at the end, and KML expects the same. Some readers close an open ring for you, but strict validators reject it. A ring whose sides cross each other, like a figure eight, has no meaningful area, and careful software refuses it rather than reporting a misleading number.

Spaces inside KML coordinates

-105.0000, 40.0000 with a space after the comma is read as two separate positions in KML, and the shape falls apart. Keep each position as one unbroken lon,lat,alt group.

KMZ treated as text

A KMZ is binary. Opening it in a text editor shows gibberish, and a tool that expects plain KML will fail. Unzip it first, or use software that accepts KMZ directly.

Decimal commas and semicolons in CSV

In locales that write 40,0009 for 40.0009, spreadsheet programs often save CSV with semicolons between columns and commas inside numbers. Most geographic software expects commas between columns and decimal points in numbers. Check the raw text before importing.

Holes and multi-part shapes

A field with a pond cut out of it is one polygon with a hole in GeoJSON and KML. Not every tool handles holes the same way, so check how the receiving software treats them before relying on the area.

What Land Measure reads and writes

The Land Measure app imports KML, KMZ, GeoJSON, GPX, and CSV, with a preview before anything is saved. KML and GeoJSON polygons come in as areas and their lines as distances. GPX tracks come in as GPS tracks, one per track segment, and GPX routes as lines. Polygons with holes are not supported, so import the outer boundary and the excluded area as separate boundaries. Shapes that cross themselves are rejected instead of being imported with a wrong area.

For export, KML and CSV are free. GPX, KMZ, and GeoJSON are part of Land Measure Pro, along with a PDF report and a north-up PNG diagram of the boundary. The app’s CSV starts with the columns point_index, latitude, longitude, altitude, accuracy, timestamp, segment_index, followed by a short summary block with the name, area, and perimeter, so it stays readable in a spreadsheet and imports back cleanly.