Skip to content

UTM Zone Boundary Straddle

vectorGeoJSONPolygonEPSG:32632tinybundled

A polygon spanning 5.5E-6.5E declared in EPSG:32632. Zone 32N covers 6E-12E, so the western half of this geometry lies outside its own declared zone -- legal, common in real data, and the case that makes cross-zone reprojection error testable.

Polygon geometry of utm_zone_boundary_straddle, 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 utm_zone_boundary_straddle
Category vector
Format GeoJSON
Geometry type Polygon
CRS EPSG:32632
Location Luxembourg / Saarland border (synthetic, straddling UTM 31N/32N) — 5.50°E, 49.50°N → 6.50°E, 50.20°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("utm_zone_boundary_straddle")
def test_utm_zone_boundary_straddle(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

Confirm that a polygon extending past its declared UTM zone's edge is reprojected using the declared CRS throughout, rather than being silently re-zoned per vertex or clipped at the zone boundary.

Risk types covered

Expected behavior

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

Notes

What straddling means

UTM zone 32N spans 6E-12E. This polygon spans 5.5E-6.5E, so a little under half of it lies west of its own declared zone's edge, with eastings down to ~246 600 m -- outside the 166 000-834 000 m band a point inside zone 32 would occupy.

This is legal, not corrupt. Every UTM projection is defined across the whole globe; the zone bounds mark where distortion stays acceptable, not where the maths stops. Real datasets straddle zone edges constantly, because administrative and physical boundaries do not respect 6-degree meridians.

The failure it catches

The tempting-but-wrong behaviour is to re-derive the zone from each vertex's longitude and reproject piecewise. That produces a polygon whose western half is transformed with zone 31's central meridian and eastern half with zone 32's, tearing the geometry along 6E -- typically as a several-hundred-kilometre jump, or a self-intersection where the rings no longer meet.

A correct consumer uses the declared CRS for every vertex and accepts the mild extra distortion outside the nominal band.

Why it did not exist before

Every UTM case in the bundled catalog resolved to zone 33N, and both cases named for zone behaviour (geotiff_utm_boundary, utm_zone_33_polygon) sat entirely inside one zone. Cross-zone reprojection was therefore untestable against the bundled data. This case, plus utm_zone_33n_to_32n_pair, closes that.

Required capabilities

  • load
  • bounds-check
  • reprojection

Files

Browse this case on GitHub

Source and license

  • Source: geocase-curated
  • License: MIT

Tags

crs polygon utm utm_zone_boundary valid vector