KML — MultiGeometry Mixing Points and a LineString
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.
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<Document>
<name>Kestrel Bay harbour marks</name>
<Placemark>
<name>Harbour buoys</name>
<description>Three navigation marks as one MultiGeometry</description>
<MultiGeometry>
<Point><coordinates>-12.4885,47.0685</coordinates></Point>
<Point><coordinates>-12.4795,47.0712</coordinates></Point>
<Point><coordinates>-12.4712,47.0668</coordinates></Point>
<LineString><coordinates>-12.4885,47.0685 -12.4795,47.0712 -12.4712,47.0668</coordinates></LineString>
</MultiGeometry>
</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
- 1
- Geometry
- MultiGeometry
- Member Geometries
- 4
- Member Types
- Point x3, LineString
- Styled
- false
Testing contract
Expected to pass- Scenario
- Convert the Placemark to GeoJSON.
- Expected result
- A GeometryCollection with four members is produced; nothing is dropped and the result is not coerced into a MultiPoint.
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 — MultiGeometry Mixing Points and a LineString” is a deterministic Novus Examples fixture for Geospatial, Conversion testing, Error handling. 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 — GroundOverlay and ScreenOverlayA 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.
- kmzKMZ — Nested Folders, a Second KML, and a NetworkLinkA 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.
- geojsonGeoJSON — Antimeridian Line Split per RFC 7946The same transect cut at the 180th meridian into a two-part MultiLineString, which is what RFC 7946 section 3.1.9 recommends. The split latitude is the linear interpolation of the unsplit twin, so the two files describe the same ground path.
- geojsonGeoJSON — Antimeridian Polygon Split into a MultiPolygonThe straddling block cut at 180 into two polygons that share an edge on the meridian — the interoperable form. Use it as the expected output when testing an antimeridian-splitting routine against the unsplit twin.
- geojsonGeoJSON — Clockwise Exterior Ring (right-hand rule violated)Both rings of the Mill Court parcel are wound the wrong way round: the exterior clockwise, the interior counter-clockwise. RFC 7946 mandates the right-hand rule, and consumers that rely on winding to tell holes from shells will read this polygon inside out.
- geojsonGeoJSON — Intentionally Invalid: Hole Outside Its ShellIntentionally invalid: the second ring is a whole separate parcel filed as an interior ring of the first, which OGC Simple Features forbids. It is what happens when a MultiPolygon is flattened into a Polygon by concatenating rings.
Generated by generation/geospatial.py. Free for any use, no attribution required — license.