Closed seisman closed 4 months ago
We also have some mysterious failures with Fiona as mentioned in https://github.com/GenericMappingTools/pygmt/issues/3180#issuecomment-2081801690. Migrating from Fiona to pyogrio also help us avoid such failures.
Not sure if we can migrate completely away from fiona
yet, at least in terms of writing out OGR_GMT files. Pyogrio doesn't list OGR_GMT under https://pyogrio.readthedocs.io/en/latest/supported_formats.html#full-read-and-write-support, though it seems to depend on what GDAL was compiled with. We might just need to test things out and see first.
OGR_GMT is built-in by default in GDAL (https://gdal.org/drivers/vector/gmt.html), so we should be safe unless some package distributors decide to disable OGR_GMT explicitly.
Ok, opened a proof of concept PR at #3237 to switch from fiona to pyogrio. The way it works is that we get a GeoJSON representation from __geo_interface__
, which pyogrio reads into a geopandas.GeoDataFrame
, and that gets output to an OGR_GMT file.
Downside is that this means geopandas would become a stronger optional dependency. Before, someone could install just fiona without geopandas and plot shapely objects, but now, doing so via pyogrio would require geopandas.
Maybe we can try geopandas first, then pyogrio, then fiona? But we may still see fiona errors reported in https://github.com/GenericMappingTools/pygmt/issues/3180#issuecomment-2081801690.
GeoPandas v1.0.0-alpha1 has been released (https://geopandas.org/en/latest/docs/changelog.html#version-1-0-0-alpha1-apr-13-2024). The biggest change is that the default I/O engine is changed from Fiona to pyogrio.
So, when geopandas v1.0.0 is released, PyGMT will fail to work, because:
scheme
parameter so some codes will break.I think we should start the migration now following the instructions.
pyogrio
as a optional dependency since geopandas 0.x doesn't install it by defaultengine="pyogrio"
to use the pyogrioThoughts @GenericMappingTools/pygmt-maintainers especially @weiji14?