Skip to content

Point GML Baseline

vectorGMLPointEPSG:4326tinybundled

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

Point geometry of point_gml_baseline, rendered from the case's data
Point geometry, rendered from the case's actual geometry. Scale is normalized to the viewport and is not comparable between cases.
Property Value
Case ID point_gml_baseline
Category vector
Format GML
Geometry type Point
CRS EPSG:4326
Location Wellington, New Zealand (synthetic) — 174.78°E, 41.29°S → 174.78°E, 41.29°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("point_gml_baseline")
def test_point_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 point encoded as GML so XML-driver loading can be compared against simpler baseline vector formats.

Risk types covered

Expected behavior

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

Notes

Purpose

Canonical baseline point encoded as GML.

Data

  • Geometry: POINT (174.78 -41.29)
  • Attributes: id = 1, name = point_gml_baseline
  • OGR additionally injects a gml_id column on read.
  • Feature count: 1

Validation

  • Geometry type: Point
  • CRS: EPSG:4326
  • Geometry equals simple_valid_point 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>-41.29 174.78</gml:pos>

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

load_case("point_gml_baseline").load().geometry.iloc[0]   # POINT (174.78 -41.29)

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_point), and generate_vector_fixtures.py --check fails on any drift.

Required capabilities

  • load
  • geometry-validation
  • reprojection

Files

Browse this case on GitHub

Source and license

  • Source: geocase-curated
  • License: MIT

Tags

baseline cross_format_canonical format_comparison gml point valid vector