Skip to content

UTM Zone 1N Polygon

vectorGeoJSONPolygonEPSG:32601tinybundled

A polygon recorded in EPSG:32601 -- UTM zone 1N, the westernmost zone, whose western edge is the antimeridian. Pairs with the dateline cases: reprojecting this to WGS84 lands hard against 180 degrees, where a longitude-wrapping bug surfaces as a polygon spanning the whole world.

Polygon geometry of utm_zone_1n_small, 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_1n_small
Category vector
Format GeoJSON
Geometry type Polygon
CRS EPSG:32601
Location Equatorial Pacific, west of the antimeridian (synthetic, UTM 1N) — 179.80°W, 0.50°N → 177.20°W, 2.50°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_1n_small")
def test_utm_zone_1n_small(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 projected polygon in the first UTM zone reprojects to WGS84 without wrapping past the antimeridian into a world-spanning extent.

Risk types covered

Expected behavior

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

Notes

Why zone 1

UTM zone 1N's western edge is the antimeridian. That makes it the zone where longitude-wrapping bugs stop being theoretical: reproject this polygon to EPSG:4326 with a naive implementation and the result can come back straddling 180 degrees, which a bounding-box computation then reports as a footprint spanning the entire planet.

Before this case the whole catalog resolved to a single UTM zone (33N), so no bundled fixture reached any zone edge, let alone this one.

What to assert

The polygon is stored projected, in EPSG:32601 metres -- not in WGS84 with a zone recorded as a parameter, which is how utm_zone_33_polygon works. Both forms are worth having: that one tests zone selection from geographic coordinates, this one tests handling of coordinates that are already in a projected CRS whose bounds are awkward.

Reprojected to WGS84 the extent is roughly 179.8W-177.2W, 0.5N-2.5N: entirely east of the antimeridian, contiguous, and nowhere near 360 degrees wide.

Pairs naturally with dateline_crossing_polygon and classic_antimeridian_polygon, which come at the same line from the geographic side.

Required capabilities

  • load
  • bounds-check
  • reprojection

Files

Browse this case on GitHub

Source and license

  • Source: geocase-curated
  • License: MIT

Tags

antimeridian crs polygon utm valid vector