A simple (as is) build engine of GDAL library for .NET.
Provides a minimal setup without requirements to install heavy GDAL binaries into your system.
MaxRev.Gdal.WindowsRuntime.Minimal
MaxRev.Gdal.LinuxRuntime.Minimal
MaxRev.Gdal.MacosRuntime.Minimal
- Packages (NuGet)
- Table Of Contents
- About this library
- How to use
- Using GDAL functions
- Development
- How to compile on Windows
- How to compile on Unix
- About build configuration
- Building runtime libraries
- FAQ
- Q: Packages do not work on CentOS 7, Ubuntu 18.04
- Q: Can I compile it on Ubuntu or another Unix-based system?
- Q: Projections are not working as expected
- Q: Some drivers complain about missing data files
- Q: Missing {some} drivers, can you add more?
- Q: GDAL functions are not working as expected
- Q: Some types throw exceptions from SWIG on Windows
- Q: In some methods performance is slower on Unix
- Q: OSGeo.OGR.SpatialReference throws System.EntryPointNotFoundException exception
- Q: Packages does not work on MacOS Catalina or lower
- Q: The first run on MacOS is slow and takes more than 3 seconds
- About and Contacts
- Acknowledgements
Table of contents generated with markdown-toc
- Only generates assemblies and binds everything into one package.
- Provides easy access to GDAL by installing only core and runtime package
- DOES NOT require installation of GDAL. From 3.7.0 version GDAL_DATA is also shipped. While it contains the
proj.db
database you can requireproj-data
grid shifts.
- Does not compile all drivers. Only configured, they are listed below. By default GDAL has a lot of internal drivers.
- Does not change GDAL source code.
- Does not extend GDAL methods.
- Install core package - MaxRev.Gdal.Core
dotnet add package MaxRev.Gdal.Core
- Install libraries for your runtime. You can install one of them or all with no conflicts. There is no requirement to install all of them or GDAL binaries. If you work on Windows and Linux you can skip MacOS package and vice versa.
# windows supported only for x64
dotnet add package MaxRev.Gdal.WindowsRuntime.Minimal
# install linux bundle which references both arm64 and x64 binaries
dotnet add package MaxRev.Gdal.LinuxRuntime.Minimal
# or install a specific runtime
dotnet add package MaxRev.Gdal.LinuxRuntime.Minimal.arm64
dotnet add package MaxRev.Gdal.LinuxRuntime.Minimal.x64
# install macos bundle which references both arm64 and x64 binaries
dotnet add package MaxRev.Gdal.MacosRuntime.Minimal
# or install a specific runtime
dotnet add package MaxRev.Gdal.MacosRuntime.Minimal.arm64
dotnet add package MaxRev.Gdal.MacosRuntime.Minimal.x64
- Initialize libraries in runtime
using MaxRev.Gdal.Core;
// call it once, before using GDAL
// this will initialize all GDAL drivers and set PROJ6 shared library paths
GdalBase.ConfigureAll();
- Profit! Use it in ordinary flow. See the section below for more info.
If you're struggling using GDAL functions. Here's a good place to start:
Enter win directory to find out how.
Detailed guide is here - unix.
Detailed guide is here - osx.
The package configuration is marked as minimal. That means you don't have to install GDAL binaries. Also, some uncommon drivers are not available (were not built).
Drivers included PROJ, GEOS, and more than 200 other drivers.
To view full list of drivers, To view the complete list of drivers, you can view the full list with GDAL's API or see property DriversInCurrentVersion
here.
NOTE: Runtime drivers availability may differ. Ask me about a specific driver for runtime. Please issue if I need to mention any packages.
Each runtime has to be build separately, but this can be done concurrently as they are using different contexts (build folders). Primary operating bindings (in gdal.core package) are build from windows. Still, the resulting core bindings are the same on each runtime package (OS).
To make everything work smoothly, each configuration targets the same drivers and their versions, respectively.
To start building for a specific runtime, see the README.md in a respective directory.
A: These are old distros and are out of support (EOL). Use docker (see this Dockerfile how to package your app) or a newer distro (GLIBC 2.31+). Packages for older systems are difficult to maintain. From 3.6.x version the Debian 11 distro is used. See this for more info.
A: Yes, you can (see unix folder for readme). All you have to do, is to choose one of the latest distros like Ubuntu 22.04 or Debian 11 (recommended). From the 3.6.x version the Debian 11 distro is used by default. It was changed because of EOL of the previous distro (see answer above). Prior to 3.6.x version packages were built on CentOS - glibc of version 2.17. It's the lowest version (in my opinion) that suits all common systems (Ubuntu, Debian, Fedora).
A: This package only contains the proj.db
database. Make sure you have installed proj-data
package. It contains aditional grid shifts and other data required for projections. Add path to your data folder with MaxRev.Gdal.Core.Proj.Configure()
. See this for more info.
A: This is related to the previous package versions (prior to 3.7.0). From 3.7.0 version, GDAL_DATA
folder is also shipped with core package.
A: Feel free to contribute and I will help you you to add them. Here's the my additional answer.
A: Try to search an issue on github. In 98% of cases, they are working fine.
A: Yes, currently there are some redundant types in OGR namespace. This will be fixed in the next builds.
A: Apparently, it's not a fault of the build engine. I did not face this issue and I use this packages in several production environments.
A: That's a problem with swig bindings. Please, use SpatialReference type from OSR namespace. More info here and here.
A: The current version of packages was compiled on MacOS Ventura and 11.3 SDK respectively. Consider updating your system to at least MacOS 13. The systems that reached EOL (end-of-life) won't be supported.
A: It's a known issue related to the linking of the shared libraries. If you find any solution/workaround, please let me know.
Currently, linker tries to find all shared libraries in the @loader_path/
. It should point to the executable directory.
This work is based on GDAL and GDAL bindings by jgoday.
Contact me in Telegram - MaxRev.
Enjoy!
As the maintainer of this repository, I want to express my heartfelt thanks to Verge Agriculture Inc.. They generously provided the necessary resources that made compiling the macOS bindings and the latest versions of GDAL possible.