KML — Shared Styles and a normal/highlight StyleMap
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.
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<Document>
<name>Kestrel Bay styled map</name>
<Style id="town-normal">
<IconStyle><scale>1.0</scale><color>ff2b58d6</color>
<Icon><href>markers/town.png</href></Icon></IconStyle>
<LabelStyle><scale>0.9</scale></LabelStyle>
</Style>
<Style id="town-highlight">
<IconStyle><scale>1.4</scale><color>ff1f7fe0</color>
<Icon><href>markers/town.png</href></Icon></IconStyle>
<LabelStyle><scale>1.2</scale></LabelStyle>
</Style>
<StyleMap id="town">
<Pair><key>normal</key><styleUrl>#town-normal</styleUrl></Pair>
<Pair><key>highlight</key><styleUrl>#town-highlight</styleUrl></Pair>
</StyleMap>
<Style id="parcel">
<LineStyle><color>ff3c3c3c</color><width>2</width></LineStyle>
<PolyStyle><color>803ca86e</color><fill>1</fill><outline>1</outline></PolyStyle>
</Style>
<Placemark>
<name>Kestrel Bay</name>
<styleUrl>#town</styleUrl>
<Point><coordinates>-12.482,47.064</coordinates></Point>
</Placemark>
<Placemark>
<name>Marram</name>
<styleUrl>#town</styleUrl>
<Point><coordinates>-12.3915,47.112</coordinates></Point>
</Placemark>
<Placemark>
<name>Holloway</name>
<styleUrl>#town</styleUrl>
<Point><coordinates>-12.551,47.018</coordinates></Point>
</Placemark>
<Placemark>
<name>Harbour Yard</name>
<styleUrl>#parcel</styleUrl>
<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>
</Document>
</kml>
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
- 4
- Styles
- 3
- Style Maps
- 1
- Colour Format
- aabbggrr (alpha, blue, green, red)
- Referenced Icons
- markers/town.png
- Styled
- true
Testing contract
Expected to pass- Scenario
- Convert to a format with its own styling model and inspect the resulting colours.
- Expected result
- The fill colour 803ca86e resolves to a 50%-opaque green, not a blue — the aabbggrr byte order is honoured rather than read as rrggbbaa.
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 — Shared Styles and a normal/highlight StyleMap” 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.