-
Notifications
You must be signed in to change notification settings - Fork 86
Description
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_geographicthat 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.