Find files, editable templates and browser test targets by what you need to make or test. Explore complete business kits for connected records, templates and expected results.
Page 115 of 221; 24 results per page.
The same 14 features as KML Placemarks, with the multi-point buoys expressed as a MultiGeometry and the two holed polygons using innerBoundaryIs. KML orders coordinates longitude-first like GeoJSON, which makes it the least surprising twin in this group.
The territory as one GeoJSON Feature per line, the shape streaming pipelines and BigQuery/Athena loaders expect. There is no enclosing FeatureCollection, so a reader that insists on one will reject it.
The master dataset for this category: five towns, three roads, three parcels (one with a courtyard hole), a lake with an island, a buoy MultiPoint and the county boundary, as an RFC 7946 FeatureCollection. Kestrel Bay County is invented: open ocean at 47 N / 12.5 W, matching no real place, settlement, road or parcel.
The same 14 features with every optional byte of whitespace removed. Pair it with the pretty-printed master to test that a parser's output is whitespace-independent and that a formatter round-trips without reordering members.
Every geometry in the territory as a bare WKT string, one per line and in master order. Attributes are deliberately absent so the file isolates geometry serialisation from attribute mapping.
The towns and roads in OSM XML: tagged nodes, three highway ways sharing the junction node at Kestrel Bay, and a route relation over them. All object IDs are negative (the convention for objects that have never been uploaded), so nothing here can be mistaken for real OSM data.
The territory as TopoJSON with no quantization and no transform, so arc coordinates are the raw WGS 84 positions. Decoding it must reproduce the master GeoJSON exactly. Which makes it the reference case before the quantized fixtures introduce rounding.
The five towns as a plain CSV with separate longitude and latitude columns: the most common way point data actually arrives. Convert it to GeoJSON and diff against the Point features in the master to score column-order and axis-order handling.
A KML document with named placemarks, for testing Google Earth / mapping importers.
Attributes carried in `ExtendedData/Data` elements, which have names and display names but no declared types: every value is a string. Importers must infer that population is a number, and this is where a silently wrong inference starts.
Four extruded points whose third coordinate means three different things depending on the `altitudeMode` beside it: ignored when clamped, height above terrain when relative, height above the ellipsoid when absolute. Copying the number without the mode changes what the data says.
A `gx:Track` from the Google KML extension: ten `when` timestamps followed by ten `gx:coord` positions, paired by index rather than nested. Note the coordinates are space-separated here even though core KML uses commas: a detail that breaks parsers reusing the same splitting code.
A georeferenced GroundOverlay pinned to the territory's bounding box and a ScreenOverlay anchored to a pixel position. Both reference images that are not present, which is the normal state for a bare .kml and the reason KMZ exists.
The three roads as LineString Placemarks with `tessellate` set, which tells a globe renderer to drape the line over terrain rather than drawing it as a straight chord. Converters that drop the flag produce lines that tunnel through hills.
One Placemark whose MultiGeometry mixes three Points with a LineString. GeoJSON has no equivalent single type for a heterogeneous set, so this must become a GeometryCollection, and converters that reach for MultiPoint instead lose the line.
Eight Placemarks arranged in three levels of Folder, the hierarchy KML uses for layer trees. GeoJSON has nothing equivalent, so a converter must either flatten and record the path or lose the structure entirely, and this file makes which one it did obvious.
Five town Placemarks with plain-text descriptions and no styling: the smallest useful KML and the baseline for the rest of this subcategory. Coordinates match the master territory, so a KML-to-GeoJSON conversion can be diffed against a known answer.
Two polygons that each carry an `innerBoundaryIs` ring: a parcel with a courtyard and a lake with an island. KML names its rings explicitly instead of relying on winding order, so converting to GeoJSON means deciding the winding rather than copying it.
Shared `Style` blocks referenced by `styleUrl`, plus a `StyleMap` pairing normal and highlight states. KML colours are written aabbggrr rather than the usual rrggbbaa, which is why converted maps so often come out with red and blue swapped.
Four Placemarks with a `TimeSpan` and one with an instantaneous `TimeStamp`, which is what drives the time slider in a globe viewer. Time is the first thing a KML-to-GeoJSON conversion drops, because RFC 7946 has no place to put it.
The same five towns with a declared `Schema` and typed `SimpleData` values: KML's answer to untyped ExtendedData. Pair it with the untyped fixture to check that your importer prefers a declared type over a guessed one.
A KMZ whose style points at `files/markers/town.png` inside the same archive. Resolving that relative href against the archive rather than the filesystem is the whole job of a KMZ reader, and it is where extract-then-parse implementations break.
A KMZ that contains a second KML in a subdirectory, reached through a `NetworkLink` with a relative href, plus an overlay image two directories deep. Readers that only load `doc.kml` show the overlay but none of the three parcels.
The minimal KMZ: a ZIP holding exactly one `doc.kml` at the archive root and nothing else. Readers are supposed to open the first .kml they find, and most look for the conventional name: this file satisfies both rules.
We use Google Analytics and show ads via Adsterra. Non-essential cookies and ad scripts run only after you allow the matching categories. See our cookie policy.
