Context
The reproject module uses pyproj for two distinct purposes:
- CRS metadata (~1ms): parsing EPSG codes, extracting projection parameters, comparing CRS objects
- Coordinate transforms (30-700ms): the per-pixel projection math
We've already replaced #2 with Numba JIT kernels (10 projection families, CPU + CUDA). But #1 still requires pyproj at import time, making it a hard dependency even though the actual math doesn't use it.
What a lightweight CRS parser would need
For the ~20 most common EPSG codes, embed enough metadata to avoid pyproj entirely:
- EPSG lookup table: map integer codes to projection parameters (proj type, lon_0, lat_0, k_0, x_0, y_0, ellipsoid, datum, units)
- Minimal CRS class: object with
to_dict(), to_authority(), to_wkt(), is_geographic that the existing _*_params() functions expect
- Boundary transform: use our Numba forward projection for the ~500-point output grid estimation instead of
pyproj.Transformer
- CRS equality: compare by EPSG code or by projection parameters
What would still fall back to pyproj
- WKT string parsing (complex grammar)
- Non-EPSG CRS definitions (PROJ4 strings, custom CRS)
- Uncommon EPSG codes not in the embedded table
- Datum transformations that need the PROJ database
Scope
This would make pip install xarray-spatial sufficient for basic reprojection (UTM, Web Mercator, LCC, Albers, etc.) without needing pyproj. Users with exotic CRS or datum requirements would still benefit from installing pyproj.
Not urgent -- pyproj installs cleanly on all platforms via pip/conda, and the current architecture already bypasses it for the performance-critical path. This is a nice-to-have for minimal-dependency deployments.
Context
The reproject module uses pyproj for two distinct purposes:
We've already replaced #2 with Numba JIT kernels (10 projection families, CPU + CUDA). But #1 still requires pyproj at import time, making it a hard dependency even though the actual math doesn't use it.
What a lightweight CRS parser would need
For the ~20 most common EPSG codes, embed enough metadata to avoid pyproj entirely:
to_dict(),to_authority(),to_wkt(),is_geographicthat the existing_*_params()functions expectpyproj.TransformerWhat would still fall back to pyproj
Scope
This would make
pip install xarray-spatialsufficient for basic reprojection (UTM, Web Mercator, LCC, Albers, etc.) without needing pyproj. Users with exotic CRS or datum requirements would still benefit from installing pyproj.Not urgent -- pyproj installs cleanly on all platforms via pip/conda, and the current architecture already bypasses it for the performance-critical path. This is a nice-to-have for minimal-dependency deployments.