KML: Typed SchemaData With a Declared Schema
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.
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<Document>
<name>Kestrel Bay typed attributes</name>
<Schema name="TownSchema" id="town-schema">
<SimpleField type="string" name="code"><displayName>Reference</displayName></SimpleField>
<SimpleField type="int" name="population"></SimpleField>
<SimpleField type="int" name="founded"></SimpleField>
<SimpleField type="bool" name="coastal"></SimpleField>
</Schema>
<Placemark>
<name>Kestrel Bay</name>
<ExtendedData>
<SchemaData schemaUrl="#town-schema">
<SimpleData name="code">KB</SimpleData>
<SimpleData name="population">4820</SimpleData>
<SimpleData name="founded">1786</SimpleData>
<SimpleData name="coastal">true</SimpleData>
</SchemaData>
</ExtendedData>
<Point><coordinates>-12.482,47.064</coordinates></Point>
</Placemark>
<Placemark>
<name>Marram</name>
<ExtendedData>
<SchemaData schemaUrl="#town-schema">
<SimpleData name="code">MR</SimpleData>
<SimpleData name="population">1180</SimpleData>
<SimpleData name="founded">1834</SimpleData>
<SimpleData name="coastal">true</SimpleData>
</SchemaData>
</ExtendedData>
<Point><coordinates>-12.3915,47.112</coordinates></Point>
</Placemark>
<Placemark>
<name>Holloway</name>
<ExtendedData>
<SchemaData schemaUrl="#town-schema">
<SimpleData name="code">HW</SimpleData>
<SimpleData name="population">2670</SimpleData>
<SimpleData name="founded">1801</SimpleData>
<SimpleData name="coastal">true</SimpleData>
</SchemaData>
</ExtendedData>
<Point><coordinates>-12.551,47.018</coordinates></Point>
</Placemark>
<Placemark>
<name>Ninepin</name>
<ExtendedData>
<SchemaData schemaUrl="#town-schema">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
- 5
- Schemas
- 1
- Simple Fields
- 4
- Declared Types
- string, int, int, bool
- Typed
- true
Testing contract
Expected to pass- Scenario
- Import both this file and the untyped ExtendedData twin and compare the resulting column types.
- Expected result
- Population and founded arrive as integers and coastal as a boolean, taken from the declared schema rather than inferred from the values.
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: Typed SchemaData With a Declared Schema” is a deterministic Testaroo fixture for Geospatial, Metadata testing, Schema validation. 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.
Generated by generation/geospatial.py. Free for any use, no attribution required, license.
Related files
- kmlKML: extrude With Three Different altitudeMode ValuesFour 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.
- kmlKML: 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.
- kmlKML: Shared Styles and a normal/highlight StyleMapShared `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.
- geojsonGeoJSON, Intentionally Invalid: Coordinates as JSON StringsIntentionally 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.
- geojsonGeoJSON, Intentionally Invalid: Latitude Outside -90 to 90Intentionally 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.
- geojsonGeoJSON, Intentionally Invalid: Longitude Outside -180 to 180Intentionally 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`.
