KML — Nested Folders (three levels)
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.
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<Document>
<name>Kestrel Bay organised map</name>
<Folder>
<name>Settlements</name>
<open>1</open>
<description>Towns and villages</description>
<Placemark>
<name>Kestrel Bay</name>
<description>Reference KB</description>
<Point><coordinates>-12.482,47.064</coordinates></Point>
</Placemark>
<Placemark>
<name>Marram</name>
<description>Reference MR</description>
<Point><coordinates>-12.3915,47.112</coordinates></Point>
</Placemark>
<Placemark>
<name>Holloway</name>
<description>Reference HW</description>
<Point><coordinates>-12.551,47.018</coordinates></Point>
</Placemark>
<Folder>
<name>Outlying</name>
<Placemark>
<name>Ninepin</name>
<description>Reference NP</description>
<Point><coordinates>-12.4402,46.9725</coordinates></Point>
</Placemark>
<Placemark>
<name>Quillan Cross</name>
<description>Reference QC</description>
<Point><coordinates>-12.6135,47.0885</coordinates></Point>
</Placemark>
</Folder>
</Folder>
<Folder>
<name>Land parcels</name>
<Placemark>
<name>Harbour Yard</name>
<description>commercial, 1.42 ha</description>
<Polygon>
<outerBoundaryIs><LinearRing>
<coordinates>-12.49,47.06 -12.474,47.06 -12.474,47.069 -12.49,47.069 -12.49,47.06</coordinates>
</LinearRing></outerBoundaryIs>
</Polygon>
</Placemark>
<Placemark>
<name>Mill Court</name>Specifications
- Format
- KML 2.2
- Namespace
- http://www.opengis.net/kml/2.2
- Crs
- WGS 84 (EPSG:4326)
- Coordinate Order
- longitude,latitude[,altitude]
- Encoding
- UTF-8
- Line Endings
- LF
- Placemarks
- 8
- Folders
- 3
- Max Folder Depth
- 3
- Note
- GeoJSON has no folder concept — hierarchy must be flattened or mapped
Testing contract
Expected to pass- Scenario
- Convert to GeoJSON and look for the folder hierarchy in the output.
- Expected result
- All eight placemarks survive; the folder path is preserved as a property or the flattening is reported, never silently discarded.
What is a .kml file?
KML (Keyhole Markup Language) is an XML format for representing geographic features, popularized by Google Earth and Google Maps. It supports placemarks, paths, polygons, styling, and overlays with WGS84 coordinates. It is widely used for sharing annotated maps and 3D geospatial content.
How to use this file
Use an example KML file to test geospatial parsing, placemark and style handling, and converters between KML, GeoJSON, and GPX.
How to use this file for testing
“KML — Nested Folders (three levels)” is a deterministic Novus Examples fixture for Geospatial, Conversion testing, Metadata testing. GeoJSON, GPX, and KML files with points, lines, polygons, and tracks — for testing map tools, route parsers, and geo importers.
Documented properties for this file: UTF-8 · LF · KML 2.2. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.
Geospatial fixtures publish one invented territory across formats, with the coordinate reference system and feature counts documented in specs. Convert or reproject and diff against the twin in the same group; edge-case geometries state exactly which assumption they are built to break.
Related files
- kmlKML — ExtendedData Untyped Data ElementsAttributes 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.

- geojsonGeoJSON — Legacy 2008 `crs` Member (removed in RFC 7946)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.

- gpkgGeoPackage — Features Stored in Web Mercator (EPSG:3857)The same five towns stored as projected metres rather than degrees, with EPSG:3857 registered in gpkg_spatial_ref_sys and stamped into every geometry blob's header. Unlike GeoJSON, GeoPackage genuinely supports this — so it is the clean way to test that your reader honours the declared SRS instead of assuming 4326.

- kmlKestrel Bay Territory — KML TwinThe 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.

- prjPRJ — UTM Zone 28N (EPSG:32628) in WKT 1The UTM zone that actually contains the invented territory: zone 28N, central meridian 15 W. It is a definition fixture only — no projected coordinates are published for it here, because a transverse Mercator value is not something to take on trust from a fixture.

- prjPRJ — Web Mercator (EPSG:3857) in WKT 1The projection every web map uses, defined as Esri's Mercator_Auxiliary_Sphere. It treats the ellipsoid as a sphere for the projection maths while keeping ellipsoidal latitudes, which is why it is a pseudo-Mercator and why it cannot represent latitudes beyond about 85.05 degrees.

Generated by generation/geospatial.py. Free for any use, no attribution required — license.