It is time to make GDAL a required prerequisite #6258
Conversation
Lots of GMT functionailty depends on GDAL, from handing images to odd grid formats to shapefiles, and there are plans to handle more table formats via ogr. This PR makes the practicailty of depending on GDAL (already included in the installers) formal.
|
This is good. gdal is good. That said, is this primarily because of gdal libs (i.e. code) being used in gmt, or the drive to make things easier for the user? Having several tools in a toolbox to do different things is by definition (almost) always a good thing. Please do not create a black box. |
Yes, and also because PROJ is mandatory in GDAL and we may want to use more things of PROJ directly (or indirectly). |
Baking in PROJ with gmt (i.e. being able to use PROJ projections) sounds very attractive. |
|
I agree. I think making GDAL a required dependency should be included in the changelog for anyone who's been building GMT without gdal. We'll need to move |
|
I have searched for GDAL in all GMT files and gone through manually and removed any mention of GDAL being optional or requiring special options. It should be all good to go as far as GMT is concerned. Once approved and merged we need to tend to the other issues that @meghanrjones outlined. |
|
When should we change the information on the wiki? The GDAL being required is not true for the official releases yet. |
|
Perhaps @meghanrjones can fix the CI script that does not use GDAL? |
I think at release-time makes sense. |
Various updates from upstream GMT at GenericMappingTools/gmt#6258, GenericMappingTools/gmt@9069967, GenericMappingTools/gmt#7260.
Saving 3-band xarray.DataArray images to a temporary GeoTIFF so that they can be plotted with grdimage. * Refactor to use tempfile_from_image Putting the temporary GeoTIFF creation logic in a dedicated tempfile_from_image helper function, so that it can be reused by other GMT modules besides grdimage. Also ensure that an ImportError is raised when the `.rio` attribute cannot be found when rioxarray is not installed. * Let tilemap use tempfile_from_image func in virtualfile_from_data Refactor Figure.tilemap to use the same tempfile_from_image function that generates a temporary GeoTIFF file from the 3-band xarray.DataArray images. * Update docstring of grdimage with upstream GMT 6.4.0 Various updates from upstream GMT at GenericMappingTools/gmt#6258, GenericMappingTools/gmt@9069967, GenericMappingTools/gmt#7260. * Raise RuntimeWarning when input image dtype is not uint8 Plotting a non-uint8 dtype xarray.DataArray works in grdimage, but the results will likely be incorrect. Warning the user about the incorrect dtype, and suggest recasting to uint8 with 0-255 range, e.g. using a histogram equalization function like skimage.exposure.equalize_hist. --------- Co-authored-by: Dongdong Tian <[email protected]>
Lots of GMT functionality now depends on GDAL, from handling image i/o, including multilevel geotiff data files, making geotiffs from plots, reading a variety of grid formats as well as handling shapefiles (there are plans to handle more table formats via the GDAL/OGR interface). We also plan to start using more proj features as available via GDAL (we will eventually also make PROJ a requirement but since PROJ is required by GDAL it does not really add anything extra). This PR makes the practicality of depending on GDAL (already included in all our installers) formal.
I have left it at WIP for now to make sure we first all agree that
#ifdef HAVE_GDALaround the code is complicating things and those 13 people who manage to use GMT but cannot handle the requirement of GDAL simply need to get onboard for the sake of the rest of us.Once we approve and merge I believe there are other repos (website, others?) that will need some updates. Let us know by adding comments herein.