Kestrel Bay Territory — OpenStreetMap XML Twin
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.
<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="Novus Examples geospatial fixtures">
<bounds minlat="46.95" minlon="-12.64" maxlat="47.14" maxlon="-12.36"/>
<node id="-1" lat="47.064" lon="-12.482">
<tag k="place" v="town"/>
<tag k="name" v="Kestrel Bay"/>
<tag k="population" v="4820"/>
<tag k="ref" v="KB"/>
</node>
<node id="-2" lat="47.112" lon="-12.3915">
<tag k="place" v="town"/>
<tag k="name" v="Marram"/>
<tag k="population" v="1180"/>
<tag k="ref" v="MR"/>
</node>
<node id="-3" lat="47.018" lon="-12.551">
<tag k="place" v="town"/>
<tag k="name" v="Holloway"/>
<tag k="population" v="2670"/>
<tag k="ref" v="HW"/>
</node>
<node id="-4" lat="46.9725" lon="-12.4402">
<tag k="place" v="town"/>
<tag k="name" v="Ninepin"/>
<tag k="population" v="640"/>
<tag k="ref" v="NP"/>
</node>
<node id="-5" lat="47.0885" lon="-12.6135">
<tag k="place" v="town"/>
<tag k="name" v="Quillan Cross"/>
<tag k="population" v="310"/>
<tag k="ref" v="QC"/>
</node>
<node id="-6" lat="47.0812" lon="-12.451"/>
<node id="-7" lat="47.0995" lon="-12.4203"/>
<node id="-8" lat="47.049" lon="-12.5115"/>
<node id="-9" lat="47.021" lon="-12.4655"/>
<way id="-101">
<nd ref="-1"/>
<nd ref="-6"/>
<nd ref="-7"/>
<nd ref="-2"/>
<tag k="highway" v="primary"/>
<tag k="name" v="Coast Road"/>
<tag k="ref" v="R1"/>
</way>
<way id="-102">
<nd ref="-1"/>
<nd ref="-8"/>
<nd ref="-3"/>Specifications
- Territory
- Kestrel Bay County (invented)
- Crs
- WGS 84 (EPSG:4326), longitude/latitude order
- Features
- 14
- Geometry Types
- Point, MultiPoint, LineString, Polygon
- Bbox
- -12.64,46.95,-12.36,47.14
- Encoding
- UTF-8
- Format
- OSM XML 0.6
- Nodes
- 12
- Ways
- 3
- Relations
- 1
- Identifiers
- negative (not-yet-uploaded convention)
- Line Endings
- LF
Testing contract
Expected to pass- Scenario
- Load with an OSM reader and follow the way references back to their nodes.
- Expected result
- 12 nodes, 3 ways and 1 relation load; all three ways resolve to the shared node at -12.482, 47.064.
What is a .osm file?
An .osm file holds OpenStreetMap data in the project's XML schema. The document contains node, way, and relation elements, each with an id, version, and free-form tag children; ways reference their nodes in order, and relations reference members by type, id, and role. It is the format returned by the OSM API and by Overpass queries, and the input to most OSM-based routing and rendering toolchains.
How to use this file
Use an example .osm file to test OSM parsers, tag filters, and routing-graph builders, checking that way node ordering is preserved, that relation roles are read, and that referenced ids missing from the extract are reported rather than skipped silently.
How to use this file for testing
“Kestrel Bay Territory — OpenStreetMap XML Twin” is a deterministic Novus Examples fixture for Geospatial, Conversion testing, Data import. 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: 12 nodes · UTF-8 · LF. 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
- gpkgGeoPackage — Aspatial Attributes Table (no geometry column)A GeoPackage holding an `attributes` table with no geometry at all — the standard's own answer to a lookup table you want to ship alongside your layers. Its gpkg_contents row has null bounds and a null SRS, which is what readers that assume every row is spatial trip over.
- gpkgGeoPackage — Three Feature Layers in One SQLite ContainerThe territory as an OGC GeoPackage: an ordinary SQLite database with the three required metadata tables and three feature layers whose geometry columns hold GeoPackage binary blobs. Unlike a shapefile it carries several geometry types, long column names and real typed columns in one file.
- gpxGPX — Route (rte) Rather Than a TrackA `rte` element: an ordered list of waypoints describing a planned route, with no timestamps because it has not been travelled yet. Many importers only look for `trk` and report this perfectly valid file as empty.
- gpxGPX — Standalone Waypoints OnlyFive `wpt` elements for the towns of the territory, with names, symbols and descriptions but no track or route. It is the GPX equivalent of a point layer, and the third of the three top-level GPX content types.
- kmlKML — LineString Placemarks With tessellateThe 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.
- kmlKML — Point Placemarks With DescriptionsFive 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.
Generated by generation/geospatial.py. Free for any use, no attribution required — license.