Fix PixelIsPoint overview coord offset (#1642)

[brendancol]

Summary

• Closes open_geotiff overview_level coord offset wrong for PixelIsPoint COGs #1642.
• extract_geo_info_with_overview_inheritance now shifts the inherited
  origin by (scale - 1) * 0.5 * pixel_size_lvl0 along each axis when
  the effective raster_type is PixelIsPoint, so an overview pixel's
  reported center matches the centroid of the level-0 pixels it covers.
• PixelIsArea path is byte-equivalent to before -- origin stays at
  the level-0 upper-left corner. The geotiff: open_geotiff(overview_level>=1) drops CRS, transform, and georeferenced coords #1640 contract is unchanged for
  the default convention.

Why

PR #1641 (issue #1640) made overview reads inherit the level-0
GeoKeys / ModelPixelScale / ModelTiepoint, but it kept origin_x and
origin_y unchanged. The default PixelIsArea convention says the
origin is the upper-left corner of pixel (0, 0), so that's correct
there. PixelIsPoint (GeoKey 1025 = 2) says the origin is the
center of pixel (0, 0). An overview pixel covering the first
scale_x columns of level 0 has its center at the centroid of those
level-0 pixels, so the inherited origin needs a shift.

The bug silently snapped coords by half an overview pixel on every
DEM-style PixelIsPoint COG (USGS, OpenTopography, Copernicus DEM all
emit RasterPixelIsPoint). da.sel, da.interp, and downstream
reproject/hillshade/slope chains pick up the wrong pixel position
without raising.

Before / after on a 1024x1024 PixelIsPoint COG with 10 m pixels and
origin (0, 0):

level0 x[:3]: [ 0. 10. 20.]
# before
level1 x[:3]: [ 0. 20. 40.]
# after
level1 x[:3]: [ 5. 25. 45.]   # centroid of level-0 0,1 = 5
level2 x[:3]: [15. 55. 95.]   # centroid of level-0 0..3 = 15
level3 x[:3]: [35. 115. 195.] # centroid of level-0 0..7 = 35

Test plan

• python -m pytest xrspatial/geotiff/tests/test_overview_pixel_is_point_1642.py (13 passed)
• python -m pytest xrspatial/geotiff/tests/test_overview_geo_inheritance_1640.py (15 passed; geotiff: open_geotiff(overview_level>=1) drops CRS, transform, and georeferenced coords #1640 contract intact)
• python -m pytest xrspatial/geotiff/tests/ -k "not http and not network" (1397 passed; 3 pre-existing matplotlib palette failures unrelated)
• CI on GitHub

Notes

The 13 new tests cover all four backends (numpy, dask+numpy, cupy,
dask+cupy) for both PixelIsPoint and a PixelIsArea regression
check, plus three unit-level helper tests via stubbed
extract_geo_info that exercise the math without going through the
writer/reader pipeline.

Found by /sweep-accuracy pass 18 on the geotiff module.

[Copilot]

Pull request overview

Fixes GeoTIFF overview georeferencing for raster_type=PixelIsPoint by adjusting the inherited origin so overview pixel centers align with the centroid of the level-0 pixels they aggregate (closing #1642). This keeps the PixelIsArea behavior unchanged while making overview reads accurate for DEM-style PixelIsPoint COGs.

Changes:

• Update extract_geo_info_with_overview_inheritance to apply a (scale - 1) * 0.5 * pixel_size_lvl0 origin shift when the effective raster type is PixelIsPoint.
• Add comprehensive regression tests covering all four read backends and both raster-type paths.
• Update .claude/sweep-accuracy-state.csv to record the sweep result for #1642.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
xrspatial/geotiff/_geotags.py	Applies a raster-type-dependent origin shift when inheriting level-0 georef for overview IFDs.
xrspatial/geotiff/tests/test_overview_pixel_is_point_1642.py	New end-to-end + unit-level regression tests validating correct PixelIsPoint overview coords/transform across backends.
.claude/sweep-accuracy-state.csv	Records the sweep-accuracy pass note for issue #1642.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.