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 Testaroo 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.
Generated by generation/geospatial.py. Free for any use, no attribution required, license.
Related files
- 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.

- geojsonGeoJSON, Intentionally Invalid: Unclosed Polygon RingIntentionally invalid: the parcel's exterior ring omits the repeated closing position that RFC 7946 requires. Many readers close it silently, which hides the producer's bug until a stricter consumer downstream rejects the data.

- geojsonGeoJSON, Intentionally Invalid: Web Mercator Metres in a .geojson FileIntentionally invalid: Web Mercator metres inside a file that claims to be GeoJSON, with a legacy `crs` member as the only hint. RFC 7946 allows exactly one coordinate system, so this file is what a desktop GIS produces when someone exports a projected layer to GeoJSON without reprojecting it first.

- 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.
