Skip to content

Out-of-Bounds / Invalid Coordinates

vectorGeoJSONPointEPSG:4326tinybundled

A point at latitude 100°, beyond the valid ±90° range — the classic symptom of swapped latitude and longitude (EPSG axis order) in the input.

Point geometry of out_of_bounds_coordinates, 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 out_of_bounds_coordinates
Category vector
Format GeoJSON
Geometry type Point
CRS EPSG:4326
Location Undefined -- coordinates fall outside the WGS84 domain
Test tier unit
Size class tiny
Storage class bundled
Redistributable yes
Loader geopandas
Status validated

Use this case

import pytest


@pytest.mark.geocase_case("out_of_bounds_coordinates")
def test_out_of_bounds_coordinates(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

Expose code that silently accepts coordinates outside valid geographic ranges. Latitude must be in [-90, 90], longitude in [-180, 180]. Values exceeding these ranges indicate data errors or coordinate order swaps.

Risk types covered

  • crs/lat_lon_swap
  • crs/projection_failure
  • extent/coordinate_range_error
  • format/spatial_index_failure
  • geometry/silent_invalid

Expected behavior

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

Notes

Purpose

Tests detection of coordinates that exceed valid geographic ranges.

Valid Coordinate Ranges

Dimension Range Notes
Latitude [-90, 90] North/South of Equator
Longitude [-180, 180] East/West of Prime Meridian

This Case

  • Longitude: -0.1° (valid)
  • Latitude: 100° (INVALID - exceeds 90° maximum)

Common Causes

  1. Lat/Lon Swap: GeoJSON uses [Lon, Lat] but data came from [Lat, Lon] system
  2. Unit Confusion: Degrees vs radians vs other units
  3. Projection Errors: Projected coordinates mistakenly stored as geographic

Expected Behavior

  • Spatial indexes: Should reject (can't index invalid coordinates)
  • Coordinate validation: Should detect and report
  • Reprojection: Will fail or produce garbage results

Real-World Occurrence

  • Excel/CSV imports where column order is assumed
  • API responses from systems using [Lat, Lon] order
  • Copy-paste errors in manual data entry

Why this case does not carry the axis_order risk type

It is the obvious candidate — cause 1 above is literally a lat/lon swap — but the term belongs to the six *_gml_baseline cases instead, and the distinction is worth stating so it is not rediscovered.

This case detects a swap only because latitude 100 happens to be out of range. That is a validity signal: the same check catches a unit error, a projected coordinate stored as geographic, or a corrupted digit. Swap a point at latitude 45 and longitude 10 and this case's mechanism sees nothing wrong.

axis_order names a different property: a file whose declared coordinate order differs from the reader's assumed one, with every value perfectly valid on both readings. The GML baselines carry that — urn:ogc:def:crs:EPSG::4326 forces latitude-first on disk — and they carry it for in-range coordinates, which is what makes the swap silent rather than detectable.

Required capabilities

  • load
  • geometry-validation
  • coordinate-validation

Files

Browse this case on GitHub

Source and license

  • Source: geocase-curated
  • License: MIT

Tags

coordinate_error invalid lat_lon_swap out_of_bounds point vector