Skip to content

LineString GML Baseline

vectorGMLLineStringEPSG:4326tinybundled

Canonical baseline linestring stored as GML for cross-format comparison and format-specific loader behavior testing.

LineString geometry of linestring_gml_baseline, rendered from the case's data
LineString geometry, rendered from the case's actual geometry. Scale is normalized to the viewport and is not comparable between cases.
Property Value
Case ID linestring_gml_baseline
Category vector
Format GML
Geometry type LineString
CRS EPSG:4326
Location Patagonia, Southern Andes (synthetic) — 72.50°W, 50.90°S → 71.50°W, 50.60°S
Test tier unit
Size class tiny
Storage class bundled
Redistributable yes
Loader geopandas
Status validated

Use this case

import pytest


@pytest.mark.geocase_case("linestring_gml_baseline")
def test_linestring_gml_baseline(geocase_case) -> None:
    data = geocase_case.load()
    assert data is not None

Use GeoCase in your tests

Install the complete set of vector, raster, and NetCDF dependencies:

pip install "geocase[all]"

View GeoCase on PyPI.

What this case checks

Provide a canonical linestring encoded as GML so format-specific loader behavior can be compared directly against the GeoJSON baseline.

Risk types covered

Expected behavior

Assertion Expected
expect_loadable yes
expect_valid_geometry yes
expect_crs yes
expected_epsg 4326
expected_geometry_types LineString

Notes

Purpose

Tests LineString geometry loading from GML format.

Data

  • Geometry: LINESTRING (-72.5 -50.9, -72 -50.6, -71.5 -50.8)
  • Attributes: id = 1, name = linestring_gml_baseline
  • OGR additionally injects a gml_id column on read.
  • Feature count: 1

Validation

  • Geometry type: LineString
  • CRS: EPSG:4326
  • Geometry equals simple_valid_linestring under shapely.normalize, which is how tests/unit/test_cross_format_canonical.py compares them. The comparison is winding-insensitive by necessity: the Shapefile specification mandates the opposite ring orientation from RFC 7946, and OGR rewrites winding on write. Orientation itself is asserted by shapefile_ring_orientation.

Axis order — the bytes really are latitude-first

These files are written with srsName="urn:ogc:def:crs:EPSG::4326". The URN form forces EPSG:4326's declared axis order, which is (latitude, longitude) — and it does so regardless of GDAL's OAMS_TRADITIONAL_GIS_ORDER setting, which the generator applies for every other format. So on disk this file reads:

<gml:pos>-50.9 -72.5 -50.6 -72 -50.8 -71.5</gml:pos>

Latitude first. That is correct GML, not a defect, and OGR reads it back lon-first as you would expect:

load_case("linestring_gml_baseline").load().geometry.iloc[0]   # LINESTRING (-72.5 -50.9, -72 -50.6, -71.5 -50.8)

The trap is for anyone who parses the XML as text — an entirely reasonable thing to do with a small GML file. Split gml:pos on whitespace, feed the pair to a constructor expecting (x, y), and you have silently swapped every coordinate. Nothing raises; the geometry is simply somewhere else.

This is why the case carries the axis_order risk type. The content gate checks the claim against the bytes: the file must use the URN form, and the first ordinate must fall inside the declared latitude band.

Note that out_of_bounds_coordinates deliberately does not carry this risk type. It catches a swap only because latitude 100 is outside the valid range — that is a validity signal, not a statement about axis ordering.

Generation

Generated by scripts/generate_vector_fixtures.py — do not hand-edit. The geometry is derived from params.canonical_source_case_id (simple_valid_linestring), and generate_vector_fixtures.py --check fails on any drift.

Required capabilities

  • load
  • geometry-validation
  • bounds-check

Files

Browse this case on GitHub

Source and license

  • Source: geocase-curated
  • License: MIT

Tags

baseline cross_format_canonical format_comparison gml linestring valid vector