Skip to content

Polygon GML Baseline

vectorGMLPolygonEPSG:4326tinybundled

Canonical baseline polygon stored as GML to exercise XML-based polygon loading with explicit CRS metadata.

Polygon geometry of polygon_gml_baseline, rendered from the case's data
Polygon geometry, rendered from the case's actual geometry. Scale is normalized to the viewport and is not comparable between cases.
Property Value
Case ID polygon_gml_baseline
Category vector
Format GML
Geometry type Polygon
CRS EPSG:4326
Location Central Europe (synthetic) — 10.00°E, 50.00°N → 11.00°E, 51.00°N
Test tier unit
Size class tiny
Storage class bundled
Redistributable yes
Loader geopandas
Status validated

Use this case

import pytest


@pytest.mark.geocase_case("polygon_gml_baseline")
def test_polygon_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 polygon encoded as GML so polygon XML-driver loading can be compared against simpler baseline formats.

Risk types covered

Expected behavior

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

Notes

Purpose

Canonical baseline polygon encoded as GML.

Data

  • Geometry: POLYGON ((10 50, 11 50, 11 51, 10 51, 10 50))
  • Attributes: id = 1, name = polygon_gml_baseline
  • OGR additionally injects a gml_id column on read.
  • Feature count: 1

Validation

  • Geometry type: Polygon
  • CRS: EPSG:4326
  • Geometry equals simple_valid_polygon 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 10 50 11 51 11 51 10 50 10</gml:pos>

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

load_case("polygon_gml_baseline").load().geometry.iloc[0]   # POLYGON ((10 50, 11 50, 11 51, 10 51, 10 50))

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_polygon), 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 polygon valid vector