Skip to content

UTM Zone 33N / 32N Adjacent Pair

vectorGeoJSONPolygonEPSG:4326tinybundled

One geometry, straddling the 12E meridian, recorded twice -- once as it appears in UTM zone 33N and once in the adjacent zone 32N. Both features are stored in WGS84 so they are directly comparable; each carries its source EPSG and projected corner in properties. A consumer can assert round-trip agreement between the two zones within tolerance.

Polygon geometry of utm_zone_33n_to_32n_pair, 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_33n_to_32n_pair
Category vector
Format GeoJSON
Geometry type Polygon
CRS EPSG:4326
Location Brandenburg, Germany (synthetic, spanning UTM 32N/33N) — 11.60°E, 52.00°N → 12.40°E, 52.40°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_33n_to_32n_pair")
def test_utm_zone_33n_to_32n_pair(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 the same ground footprint reprojected via two adjacent UTM zones agrees to within reprojection tolerance, rather than differing by the ~412 km the two zones' false eastings imply.

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

The construction

One ground footprint -- 11.6E-12.4E, 52.0N-52.4N, chosen to sit across the 12E meridian that divides UTM zones 32N and 33N -- recorded as two features. Both hold identical WGS84 coordinates; they differ only in the properties recording which zone each was projected through:

feature source EPSG easting of the SW corner
as_recorded_in_zone_33n 32633 266 621 m
as_recorded_in_zone_32n 32632 676 881 m

Same point on the ground, eastings 412 km apart. That is not an error; it is what adjacent UTM zones do, and it is precisely the magnitude of the bug a consumer produces when it mixes the two.

What to assert

Project each feature through its own source_epsg and back to WGS84. The two results must agree to within params.agreement_tolerance_m (1 m). A consumer that assumes one zone for the whole dataset, or that derives the zone from a bounding-box centroid without checking the extent crosses an edge, will disagree by hundreds of kilometres on at least one feature.

Both features are stored in WGS84 rather than in their respective projected CRSs deliberately: a GeoJSON FeatureCollection has one CRS, so storing them projected would require two files and lose the direct comparability that is the case's entire purpose.

utm_zone_boundary_straddle covers the single-geometry version of the same hazard -- one polygon extending past its own zone's edge.

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