What is GeoJSON polygon?

GeoJSON is the standard format for describing geographic shapes as JSON, defined by RFC 7946. A polygon is its way of describing an area — a school campus, a delivery region, a geofence.

{
  "type": "Polygon",
  "coordinates": [
    [
      [-9.1425, 38.7245],
      [-9.1375, 38.7245],
      [-9.1375, 38.7205],
      [-9.1425, 38.7205],
      [-9.1425, 38.7245]
    ]
  ]
}

Three things about that structure account for nearly every GeoJSON bug in existence.

1. Longitude comes first

Positions are [longitude, latitude]. Almost every human-facing system — Google Maps, GPS displays, Leaflet’s own LatLng class — writes them the other way round.

Swap them and one of two things happens. If your latitude ends up above 90, you get a clear error, which is the lucky case. If both values happen to fall within ±90, the file parses perfectly and quietly describes somewhere else. A zone in Barcelona at 41.40, 2.17 becomes a point in the Indian Ocean off Somalia. Nothing errors. The map just shows the wrong water.

This is the single most common GeoJSON mistake, and experience does not seem to cure it. The GeoJSON viewer flags out-of-range latitudes immediately; for the ambiguous case, seeing the shape on a map is the only real test.

2. Rings must be closed

A polygon’s boundary is a ring: a list of positions where the last one repeats the first. A square needs five entries, not four.

Strict parsers reject an unclosed ring outright. Lenient ones close it silently, which is worse — it works locally and fails in whatever system you hand it to next. A ring also needs at least four positions, so the minimum valid shape is a closed triangle.

3. coordinates is an array of rings, not points

The extra nesting level exists so a polygon can have holes. The first ring is the outer boundary; every ring after it is a hole punched through that boundary.

"coordinates": [
  [ ...outer boundary... ],
  [ ...hole... ],
  [ ...another hole... ]
]

That is how you model a delivery zone with an excluded block in the middle, or a site with a courtyard that does not count as inside. The area calculator subtracts holes when measuring, so you get the area you can actually use rather than the area of the outline.

RFC 7946 asks for outer rings to wind counter-clockwise and holes clockwise. Most parsers ignore winding and infer holes from position, so getting it wrong rarely breaks rendering — but it can invert inside and outside in stricter geometry engines, which is an unpleasant bug to track down.

Polygon versus circle

GeoJSON has no circle type. Points, lines, and polygons are all it defines.

This matters because a circular geofence — centre plus radius — is the simplest and cheapest kind to evaluate, needing one distance calculation rather than a full point-in-polygon test. When a circle has to pass through a GeoJSON pipeline it gets approximated as a many-sided polygon; 64 sides puts the area within about 0.1% of the true circle.

Geoblip accepts both a native circle definition and a standard GeoJSON polygon, so a zone drawn as a circle stays exact rather than being approximated on the way in. The radius map exports either form.

Choosing between them

Use a circle when the zone is genuinely “within X metres of this point” — a house, a pickup spot, an address. Use a polygon when the real shape matters: a campus, a depot yard, a park with an awkward outline that a circle would either miss or overshoot.

Trace one with the geofence builder and it produces valid, closed, correctly-ordered GeoJSON you can paste anywhere.

Last reviewed 7 August 2026.