GML 2.1 — Legacy gml:coordinates With Custom Separators
GML 2.1 packed coordinates into a single `gml:coordinates` string whose decimal, coordinate and tuple separators are all declared as attributes and can be anything. GML 3 replaced it with `gml:posList`, but WFS 1.0 servers still emit this, and a parser that assumes the default separators mis-reads any file that changes them.
<?xml version="1.0" encoding="UTF-8"?>
<gml:FeatureCollection xmlns:gml="http://www.opengis.net/gml" xmlns:kb="https://examples.novusstreamsolutions.com/ns/kestrel-bay">
<gml:featureMember>
<kb:Road fid="road-R1">
<kb:name>Coast Road</kb:name>
<kb:classification>primary</kb:classification>
<kb:length_km>9.4</kb:length_km>
<kb:centreline>
<gml:LineString srsName="EPSG:4326">
<gml:coordinates decimal="." cs="," ts=" ">-12.482,47.064 -12.451,47.0812 -12.4203,47.0995 -12.3915,47.112</gml:coordinates>
</gml:LineString>
</kb:centreline>
</kb:Road>
</gml:featureMember>
<gml:featureMember>
<kb:Road fid="road-R2">
<kb:name>Ridge Way</kb:name>
<kb:classification>secondary</kb:classification>
<kb:length_km>8.1</kb:length_km>
<kb:centreline>
<gml:LineString srsName="EPSG:4326">
<gml:coordinates decimal="." cs="," ts=" ">-12.482,47.064 -12.5115,47.049 -12.551,47.018</gml:coordinates>
</gml:LineString>
</kb:centreline>
</kb:Road>
</gml:featureMember>
<gml:featureMember>
<kb:Road fid="road-R3">
<kb:name>Ninepin Lane</kb:name>
<kb:classification>track</kb:classification>
<kb:length_km>10.6</kb:length_km>
<kb:centreline>
<gml:LineString srsName="EPSG:4326">
<gml:coordinates decimal="." cs="," ts=" ">-12.482,47.064 -12.4655,47.021 -12.4402,46.9725</gml:coordinates>
</gml:LineString>
</kb:centreline>
</kb:Road>
</gml:featureMember>
</gml:FeatureCollection>
Specifications
- Format
- GML 2.1
- Features
- 3
- Srs Name
- EPSG:4326 (short form)
- Coordinate Element
- gml:coordinates (deprecated in GML 3)
- Decimal Separator
- .
- Coordinate Separator
- ,
- Tuple Separator
- Coordinate Order
- longitude,latitude (short-form EPSG is conventionally x,y)
- Encoding
- UTF-8
- Line Endings
- LF
Testing contract
Expected to pass- Scenario
- Parse the coordinates honouring the declared cs, ts and decimal attributes.
- Expected result
- Three lines of 4, 3 and 3 vertices are recovered; the parser reads the separators from the attributes rather than assuming comma-and-space.
What is a .gml file?
GML (Geography Markup Language) is the OGC's XML grammar for geographic features. Features carry typed properties and geometry elements such as gml:Point, gml:LineString, gml:Polygon, and their aggregates, with coordinates in gml:posList or gml:coordinates and the coordinate reference system named by an srsName attribute. It is the payload format of WFS services and the base of several national and INSPIRE data standards.
How to use this file
Use an example .gml file to test GML parsers and XML-based GIS pipelines, checking namespace handling, srsName resolution including the axis-order rules that differ between GML versions, and conversion to GeoJSON or shapefile.
How to use this file for testing
“GML 2.1 — Legacy gml:coordinates With Custom Separators” 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 · GML 2.1. 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
- 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.
- geojsonGeoJSON — Intentionally Invalid: Latitude Before LongitudeIntentionally invalid: the five towns with their coordinates written latitude-first. RFC 7946 fixes the order as longitude then latitude, and this is the mistake that arrives via an EPSG-URN-ordered source such as the GML twin in the territory subcategory.
- geojsonGeoJSON — Intentionally Invalid: Self-Intersecting RingIntentionally invalid: a bowtie ring whose two lobes wind in opposite directions, so the shoelace areas nearly cancel. Buffer, intersection and area operations on this geometry return nonsense rather than failing, which is why it belongs in a validation suite.
Generated by generation/geospatial.py. Free for any use, no attribution required — license.