Find files, editable templates and browser test targets by what you need to make or test. The directory below is cut by format; the two collections under it cut the same library by subject and by workflow.
Page 2 of 7; 24 results per page.
Intentionally invalid: the file is perfectly good JSON but the coordinates are quoted strings, which RFC 7946 does not allow. It is exactly what a CSV-to-GeoJSON script produces when it forgets to cast, and a permissive reader will coerce it and hide the bug.
Intentionally invalid: the second ring is a whole separate parcel filed as an interior ring of the first, which OGC Simple Features forbids. It is what happens when a MultiPolygon is flattened into a Polygon by concatenating rings.
Intentionally invalid: the five towns with their coordinates written latitude-first. RFC 7946 fixes the order as longitude then latitude, and this is the mistake that arrives via an EPSG-URN-ordered source such as the GML twin in the territory subcategory.
Intentionally invalid: latitude 95, five degrees past the north pole. This is the value that appears when longitude and latitude have been swapped somewhere upstream, so catching it early usually finds an axis-order bug rather than a data-entry one.
Intentionally invalid: a point at longitude 200. It is a plausible-looking number that usually comes from adding an offset without wrapping, and it survives JSON schema checks that only test for `number`.
Intentionally invalid: a ring of three positions that closes back on itself and therefore encloses nothing. RFC 7946 requires at least four positions for a linear ring, and this is the shape a simplification pass produces when it over-thins a small polygon.
Intentionally invalid: a bowtie ring whose two lobes wind in opposite directions, so the shoelace areas nearly cancel. Buffer, intersection and area operations on this geometry return nonsense rather than failing, which is why it belongs in a validation suite.
Intentionally invalid: the parcel's exterior ring omits the repeated closing position that RFC 7946 requires. Many readers close it silently, which hides the producer's bug until a stricter consumer downstream rejects the data.
Intentionally invalid: Web Mercator metres inside a file that claims to be GeoJSON, with a legacy `crs` member as the only hint. RFC 7946 allows exactly one coordinate system, so this file is what a desktop GIS produces when someone exports a projected layer to GeoJSON without reprojecting it first.
The same transect cut at the 180th meridian into a two-part MultiLineString, which is what RFC 7946 section 3.1.9 recommends. The split latitude is the linear interpolation of the unsplit twin, so the two files describe the same ground path.
The straddling block cut at 180 into two polygons that share an edge on the meridian: the interoperable form. Use it as the expected output when testing an antimeridian-splitting routine against the unsplit twin.
A top-level Geometry object with no Feature or FeatureCollection around it. This is legal GeoJSON and is what PostGIS `ST_AsGeoJSON` returns, but a surprising number of importers only accept a FeatureCollection.
Three features that each carry their own bbox. Spatial indexes are often built from these declared boxes instead of the geometry, so a wrong or stale one produces a query that silently misses features.
The five towns with a four-element bounding box on the collection, ordered west, south, east, north as RFC 7946 requires. The values are the true extent of the contained points, so a reader that recomputes the box can be scored against the declared one.
Both rings of the Mill Court parcel are wound the wrong way round: the exterior clockwise, the interior counter-clockwise. RFC 7946 mandates the right-hand rule, and consumers that rely on winding to tell holes from shells will read this polygon inside out.
One feature whose properties mix every JSON type and nest three levels deep. Formats with a flat attribute table (shapefile DBF, most SQL layers) cannot represent this, so the fixture shows whether a converter flattens, JSON-encodes, or discards the nested values.
A structurally valid FeatureCollection with an empty `features` array: what a spatial query legitimately returns when nothing matches. It is the standard fixture for the empty-state path of a map component.
A GeometryCollection with an empty `geometries` array: structurally valid, semantically the empty geometry. Converters that map a collection onto a multi-geometry type usually emit null here, quietly changing the record's meaning.
A feature carrying a LineString with an empty coordinate array. Empty geometries are what spatial operations legitimately return (an intersection that misses, a clip that removes everything), and index and rendering code routinely assumes at least one coordinate exists.
A feature carrying a Polygon with no rings at all. Empty geometries are what spatial operations legitimately return (an intersection that misses, a clip that removes everything), and index and rendering code routinely assumes at least one coordinate exists.
RFC 7946 section 6 allows members it does not define to sit alongside the ones it does, and requires parsers to ignore rather than reject them. This collection carries three such members at the top level.
A FeatureCollection carrying the `crs` member from the 2008 GeoJSON specification. RFC 7946 removed it and fixed the CRS as WGS 84, so a modern reader should treat this as an ignorable foreign member, but plenty of exporters still write it and some readers still obey it.
A two-point line whose longitudes step from 179.6 to -179.7. Interpolating naively draws a 359.3-degree line all the way back around the world instead of the 0.7-degree hop across the 180th meridian: the classic antimeridian artefact.
A flight path that goes up one meridian, touches the pole, and comes down the antipodal meridian, so longitude jumps by exactly 180 degrees at the middle vertex. Renderers that interpolate in longitude draw a horizontal streak across the whole map instead.
