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.
Two adjacent parcels that share their common boundary as a single arc: West Field references it as 0 and East Field as ~0, the negative-index form that means traverse it backwards. Storing the boundary once is the whole point of TopoJSON, and it is also where naive decoders produce gaps or slivers.
A topology whose fourth arc repeats the same position twice, giving a line of zero length. Quantization produces these routinely when two vertices land in the same grid cell, and simplification code that divides by segment length fails on them.
The same point encoded both ways, plus a polygon, as uppercase hex: the form WKB takes when it travels through a text column or a SQL console. The byte-order flag is the first byte of each string, so the two point encodings differ everywhere after it.
Twenty-one raw bytes: a byte-order flag, a little-endian geometry-type code of 1, and two float64 ordinates. This is the wire format PostGIS, GeoPackage and most spatial drivers actually move geometry in.
Intentionally invalid: four WKT strings that each break in a different way, a point with one ordinate, a line whose last vertex is ragged, a polygon missing a closing bracket, and a misspelled keyword. Good parsers report which line and which character failed.
One EMPTY value for each WKT geometry type, one per line. Empty geometries are what spatial operations return when nothing is left, and round-tripping them is where a database driver usually turns a typed empty into a plain NULL.
A single WKT value for a point, a line and a polygon in one value. WKT nests with bare parentheses and no type tags on the inner parts, so the number and depth of brackets is the only thing that distinguishes a polygon ring from a multipolygon member, which is where hand-written parsers go wrong.
A single WKT value for the four-vertex Coast Road. WKT nests with bare parentheses and no type tags on the inner parts, so the number and depth of brackets is the only thing that distinguishes a polygon ring from a multipolygon member, which is where hand-written parsers go wrong.
A point with an M (measure) ordinate rather than a Z. Written without the tag this is indistinguishable from a Z geometry, and a parser that assumes the third ordinate is elevation silently converts a 345-second measure into a 345-metre altitude.
A single WKT value for all three parcels in one geometry. WKT nests with bare parentheses and no type tags on the inner parts, so the number and depth of brackets is the only thing that distinguishes a polygon ring from a multipolygon member, which is where hand-written parsers go wrong.
A single WKT value for the Kestrel Bay town centre. WKT nests with bare parentheses and no type tags on the inner parts, so the number and depth of brackets is the only thing that distinguishes a polygon ring from a multipolygon member, which is where hand-written parsers go wrong.
A single WKT value for the Mill Court parcel and its courtyard. WKT nests with bare parentheses and no type tags on the inner parts, so the number and depth of brackets is the only thing that distinguishes a polygon ring from a multipolygon member, which is where hand-written parsers go wrong.
A point with an explicit Z dimension tag. Some producers write `POINT Z (x y z)` and others write `POINT(x y z)` with no tag at all, so a parser has to cope with the dimension being declared or merely implied by the ordinate count.
A three-vertex line carrying both elevation and a measure, so each position has four ordinates. GeoJSON tops out at three, which makes this the fixture that shows what a WKT-to-GeoJSON conversion has to drop and whether it says so.
