ImageMosaic: partial/blank rendering when reprojecting to EPSG:3857 at high zoom (regression in GeoTools 34)
## Summary
ImageMosaic layers backed by GeoTIFF fail to render correctly when the requested CRS differs from the native CRS and the BBOX is small (high zoom). The rendered image only fills a portion (bottom-left corner) of the output tile. The issue worsens progressively as the BBOX narrows — at ~100m extent in EPSG:3857, the output is completely blank.
Rendering in the native CRS works correctly at all zoom levels.
This is a regression from GeoTools 33.4 (GeoServer 2.27.3) to GeoTools 34.4 (GeoServer 2.28.4). The same code exists in GeoTools 35.1, so GeoServer 3.0.0 is also affected.
## Affects Version
- GeoTools 34.4 (GeoServer 2.28.4)
- GeoTools 35.1 (GeoServer 3.0.0)
## Working Version
- GeoTools 33.4 (GeoServer 2.27.3)
## Environment
- Docker image: kartoza/geoserver:2.28.4
- OS: Debian (Docker on GCP VMs)
- Java: OpenJDK 17
## Steps to Reproduce
1. Create an ImageMosaic coverage store with GeoTIFF granules in EPSG:31370 (Belgian Lambert 72)
2. The mosaic has high native resolution (~0.023m/pixel) and large grid (749,345 x 744,954 pixels)
3. Request WMS GetMap in the native CRS at high zoom — works correctly:
.../wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&LAYERS=ortho:layer
&SRS=EPSG:31370&BBOX=149950,170000,150050,170050&WIDTH=512&HEIGHT=512&FORMAT=image/png
4. Request the same area in EPSG:3857 — fails:
.../wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&LAYERS=ortho:layer
&SRS=EPSG:3857&BBOX=486416,6592990,486516,6593090&WIDTH=512&HEIGHT=512&FORMAT=image/png
## Expected Result
Full aerial imagery filling the entire 512x512 output image.
## Actual Result
At ~100m BBOX in EPSG:3857: completely blank/transparent image (5.6 KB).
At ~200m BBOX: imagery fills only the bottom-left ~50% of the image.
At ~500m BBOX and wider: renders correctly.
The same pattern occurs with EPSG:4326 and EPSG:3812 at sufficiently high zoom.
## Observations
### Response size comparison (same geographic area)
| BBOX extent | EPSG:31370 (native) | EPSG:3857 | EPSG:4326 |
|---|---|---|---|
| 1 km | 679 KB | 447 KB | 484 KB |
| 500 m | 679 KB | 305 KB | 374 KB |
| 200 m | 679 KB | 143 KB | — |
| 100 m | 562 KB | 5.6 KB | — |
| 20 m | 103 KB | — | — |
### Log warnings during broken request
WARN [operation.projection] - Possible use of "Popular Visualisation Pseudo Mercator"
projection outside its valid area. Longitude 2147483287°00.0'W is out of range (±180°).
WARN [lite.gridcoverage2d] - Could not reduce the grid geometry inside the valid area bounds:
ReferencedEnvelope[-2.147483647E9 : 2.147483647E9, -85.0 : 85.0] DefaultGeographicCRS[WGS84(DD)]
Grid geometry isGridGeometry2D[GridEnvelope2D[0..1949, 0..1725], PARAM_MT["Affine",
PARAMETER["elt_0_0", 0.043939320812586315],
PARAMETER["elt_0_2", 150768.7107758104],
PARAMETER["elt_1_1", -0.043817284121205384],
PARAMETER["elt_1_2", 170326.26076801604]]]
Note: The Integer.MAX_VALUE in MercatorHandlerFactory.VALID_AREA has been there since before the regression. The GridGeometryReducer warning is harmless — when reduction fails, the original grid geometry passes through unmodified. The actual rendering failure is elsewhere in the reprojection pipeline.
### What changed between GeoTools 33 and 34
The primary change is the JAI → Eclipse ImageN migration (javax.media.jai → org.eclipse.imagen). The rendering code in GridCoverageRenderer, GridCoverageRendererUtilities, and GridCoverageReaderHelper is otherwise identical between 33.4 and 34.4 (verified by source diff), suggesting the regression is in the ImageN warp/affine operation or the coverage resampling code path.
### Coverage configuration
- Type: ImageMosaic
- Native CRS: EPSG:31370
- Native resolution: ~0.023 m/pixel (2.3 cm)
- Grid dimensions: 749,345 x 744,954
- Projection policy: FORCE_DECLARED
- Interpolation: nearest neighbor
- FootprintBehavior: Transparent
- InputTransparentColor: #000000
- OutputTransparentColor: #000000