Optical Dateline Small¶
An RGB GeoTIFF whose bounds straddle the antimeridian at +180 longitude. Exercises bounds normalization and antimeridian splitting on raster inputs.
| Property | Value |
|---|---|
| Case ID | optical_dateline_small |
| Category | raster |
| Format | GeoTIFF |
| CRS | EPSG:4326 |
| Location | Antimeridian, North Pacific — 179.90°E, 0.68°N → 179.78°W, 1.00°N (crosses the antimeridian — the box runs east from the first corner, over 180°) |
| Test tier | integration |
| Size class | tiny |
| Storage class | bundled |
| Redistributable | yes |
| Loader | rasterio |
| Status | validated |
Use this case¶
import pytest
@pytest.mark.geocase_case("optical_dateline_small")
def test_optical_dateline_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:
What this case checks¶
Confirm GeoCase handles an RGB optical scene whose extent crosses the antimeridian.
Risk types covered¶
Expected behavior¶
| Assertion | Expected |
|---|---|
expect_loadable |
yes |
expect_crs |
yes |
expected_epsg |
4326 |
expected_band_count |
3 |
expected_dtype |
uint8 |
expected_shape |
[16, 16] |
expected_compression |
deflate |
expected_band_names |
red, green, blue |
Known answer¶
Computed from the actual bytes and gated against them. Grade your own output against these.
| Quantity | Value |
|---|---|
| NoData pixels | 0 |
| Bounds (case CRS) | [179.9, 0.68, 180.22, 1.0] |
Known consumer divergences¶
Disagreements already investigated on this case. If your reader reproduces one of these, it is catalogued — not a new finding.
naive-tile-indexing — any consumer flooring an unwrapped longitude into a tile index
The footprint is unsplit and reaches longitude 180.22, so a consumer that derives a tile index by flooring the eastern bound requests a tile at longitude 180 -- outside the valid range for every tiling scheme, which raises rather than returning empty. Round 4 found this as a real crash, but only after hand-rolling the tile arithmetic to see where the footprint pointed: the geometry was already in the file and was not enough. Split the footprint at the antimeridian, or normalise to the wrapped (minx > maxx) convention, before indexing.
titiler — titiler 0.24 / rio-tiler 8.x, GDAL 3.12.2
TileJSON bounds/center and /info.geojson carry longitudes greater than 180 for this unwrapped antimeridian-crossing raster, which is out of spec for both formats. bounds_to_geometry handles only the wrapped (minx > maxx) convention.
gdal — GDAL d6fd56f52d (also GDAL 3.12.2), any projected target SRS
gdal.AutoCreateWarpedVRT(ds, None, "EPSG:3857") returns a dataset with RasterYSize == 0 for this raster, with CE_None and no warning. PROJ wraps the eastern bound of 180.22 to -20013018 m, so GDALSuggestedWarpOutput2 sees an X span of ~40000 km against a Y span of ~35 km, derives one square pixel size from the diagonal, and at alg/gdaltransformer.cpp:1141-1142 rounds *pnLines to 0. The too-large direction is clamped twelve lines above; the rounds-to-zero direction is not. The antimeridian handling at gdaltransformer.cpp:1474-1491 fires only when the destination SRS is geographic, so a projected target gets none. The caller sees an invalid GDALDataset and only a later Create reports "Attempt to create 23x0 dataset is illegal", which names the symptom and not the cause. Split or wrap the footprint before warping to a projected CRS.
Required capabilities¶
loadcrs-check
Files¶
- Primary:
optical_dateline_small.tif
Source and license¶
- Source: geocase-synthetic
- License: MIT
Tags¶
delivery:single-file eo geography:dateline geotiff optical product:optical raster
Related cases¶
- Optical Dateline West Small --
optical_dateline_west_small - Optical Equator Small --
optical_equator_small - Optical Polar Small --
optical_polar_small - Optical RGB Small --
optical_rgb_small - DEM Small --
dem_small