Summary
MetPy depends on GIS machinery internally (pyproj is a hard dependency, Cartopy powers all mapping, and CFProjection parses CF grid_mapping metadata), but it exposes no interoperability layer with the wider GIS ecosystem. Data can be read and computed on in its native projected coordinates, yet it cannot be exchanged with standard GIS software (QGIS, ArcGIS, GDAL-based tooling) nor re-gridded between projections. This issue collects three related, concrete gaps.
1. Raster GIS (GeoTIFF / rasterio) support is entirely absent
There is no code path for reading or writing GeoTIFF (or any GDAL/rasterio raster format). A search of src/metpy for rasterio|gdal|geotiff returns nothing.
Impact: a MetPy gridded field (e.g. a reflectivity mosaic, a model field, or a computed derived field) cannot be exported as a georeferenced raster for use in general-purpose GIS software, and georeferenced rasters cannot be ingested.
Possible direction: offer an optional rioxarray-based bridge, e.g. writing/reading a metpy_crs-tagged DataArray to/from GeoTIFF while preserving the CRS.
2. No reprojection / regridding / warping between projections
MetPy has no reproject / regrid / warp utility. Two grids stored in different projections cannot be aligned to a common grid without the user manually combining pyproj with scipy/xarray interpolation. The building blocks exist (CFProjection.to_pyproj(), the .metpy.pyproj_crs accessor, assign_y_x / assign_latitude_longitude), but there is no high-level function that resamples field A onto the grid of field B (or onto an arbitrary target CRS and extent).
Impact: cross-source workflows (combining model + satellite + radar grids) require significant boilerplate and are error-prone with respect to map-factor and datum handling.
3. No vector GIS export
MetPy can create vector geometries — metpy.io.text.parse_wpc_surface_bulletin() returns Shapely points/lines/polygons — but there is no way to write them (or any derived geometry) out to a standard vector format (GeoJSON, Shapefile, GeoPackage). The optional geopandas dependency is used only for plotting via PlotGeometry, not for I/O.
Impact: parsed fronts/pressure-center geometries and other analysis output stay locked inside MetPy for rendering only; they cannot be handed to downstream GIS tools.
Why this matters
The three gaps share one root cause: MetPy treats projections as an internal concern for correct computation and plotting, but does not provide an interchange boundary with the GIS world. Closing even one of these (GeoTIFF export via rioxarray is likely the lowest-effort, highest-value first step) would substantially improve MetPy's usefulness in mixed meteorology + GIS pipelines.
Notes
pyproj is listed as a hard dependency in pyproject.toml, though the README still describes it as optional — a minor doc inconsistency worth fixing alongside this.- Related, pre-existing precision
TODO: make_latlon in src/metpy/plots/mapping.py always returns PlateCarree() (sphere), ignoring the datum; the default Geod(ellps='sphere') in calc/tools.py similarly assumes a sphere rather than WGS84.
Summary
MetPy depends on GIS machinery internally (
pyprojis a hard dependency, Cartopy powers all mapping, andCFProjectionparses CFgrid_mappingmetadata), but it exposes no interoperability layer with the wider GIS ecosystem. Data can be read and computed on in its native projected coordinates, yet it cannot be exchanged with standard GIS software (QGIS, ArcGIS, GDAL-based tooling) nor re-gridded between projections. This issue collects three related, concrete gaps.1. Raster GIS (GeoTIFF / rasterio) support is entirely absent
There is no code path for reading or writing GeoTIFF (or any GDAL/
rasterioraster format). A search ofsrc/metpyforrasterio|gdal|geotiffreturns nothing.Impact: a MetPy gridded field (e.g. a reflectivity mosaic, a model field, or a computed derived field) cannot be exported as a georeferenced raster for use in general-purpose GIS software, and georeferenced rasters cannot be ingested.
Possible direction: offer an optional
rioxarray-based bridge, e.g. writing/reading ametpy_crs-taggedDataArrayto/from GeoTIFF while preserving the CRS.2. No reprojection / regridding / warping between projections
MetPy has no
reproject/regrid/warputility. Two grids stored in different projections cannot be aligned to a common grid without the user manually combiningpyprojwithscipy/xarrayinterpolation. The building blocks exist (CFProjection.to_pyproj(), the.metpy.pyproj_crsaccessor,assign_y_x/assign_latitude_longitude), but there is no high-level function that resamples field A onto the grid of field B (or onto an arbitrary target CRS and extent).Impact: cross-source workflows (combining model + satellite + radar grids) require significant boilerplate and are error-prone with respect to map-factor and datum handling.
3. No vector GIS export
MetPy can create vector geometries —
metpy.io.text.parse_wpc_surface_bulletin()returns Shapely points/lines/polygons — but there is no way to write them (or any derived geometry) out to a standard vector format (GeoJSON, Shapefile, GeoPackage). The optionalgeopandasdependency is used only for plotting viaPlotGeometry, not for I/O.Impact: parsed fronts/pressure-center geometries and other analysis output stay locked inside MetPy for rendering only; they cannot be handed to downstream GIS tools.
Why this matters
The three gaps share one root cause: MetPy treats projections as an internal concern for correct computation and plotting, but does not provide an interchange boundary with the GIS world. Closing even one of these (GeoTIFF export via
rioxarrayis likely the lowest-effort, highest-value first step) would substantially improve MetPy's usefulness in mixed meteorology + GIS pipelines.Notes
pyprojis listed as a hard dependency inpyproject.toml, though the README still describes it as optional — a minor doc inconsistency worth fixing alongside this.TODO:make_latloninsrc/metpy/plots/mapping.pyalways returnsPlateCarree()(sphere), ignoring the datum; the defaultGeod(ellps='sphere')incalc/tools.pysimilarly assumes a sphere rather than WGS84.