-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Which external drivers to support #65
Comments
This is also a nice reference for what could consitute a good set of drivers to include: https://github.com/OSGeo/gdal/tree/master/docker We should probably aim to cover ultrasmall first, then small. |
UltraSmallRaster drivers: VRT, GTiff, HFA, PNG, JPEG, MEM, JP2OpenJPEG, WEB, GPKG SmallRaster drivers: ultrasmall + built-in + SQLite-based ones + network-based ones NormalRaster drivers: small + netCDF, HDF5, BAG |
On the surface this issue looks complete based on #65 (comment). Are there remaining TODOs? |
I think the remaining TODO's is completing and tracking UltraSmall as listed above, a few are stil missing from that, I believe And next would be finishing Small. Although we also have a few items from Normal, such as |
It would be nice to have support for GeoArrow and GeoParquet as well. This was brought up in #136 (comment). But it would first require switching the build to CMake, which is something we should do soon anyway, since for GDAL 3.6 it will be the only option. EDIT: done in JuliaPackaging/Yggdrasil#5423 I saw conda-forge/gdal-feedstock#628 discussing about the possible advantages to build drivers that are large external dependencies as plugins. We might want to look into that as well for Arrow, Parquet and perhaps netCDF. |
We build GDAL (https://github.com/JuliaPackaging/Yggdrasil/tree/master/G/GDAL) only with the most basic drivers/support for now. This includes:
Which drivers should we also include? See the raster and vector format lists on the GDAL website.
Note that it is not the goal to provide everyone with a GDAL build with all drivers. Many drivers see only little use and would increase both the build size and complexity of maintaining the build too much. Therefore it would be good to try to find a rather minimal build that includes enough drivers for most use cases.
If you do need an esoteric format that will not be included in the default build, this does not mean you cannot use this wrapper. If you provide your own build, you can simply point to that instead, see #64 (comment).
The text was updated successfully, but these errors were encountered: