8

From my understanding, there is gdal installation that you can just access through the shell then there is the Python library version for it with 'Python bindings' that map to the original.

My current code is a mix of working in the GDAL Python library with the functions and classes in that library, and just calling os.system and running the gdal commands directly through that when that feels more convenient.

Is there a reason why that might not be good to do? This is shared code so I think there could theoretically be an issue with finding gdal/ogr if ran through shell with os.system, but by default it seems to work, and you would need to install gdal/ogr anyway to use the Python library.

I guess I'm only asking because it feels like this might be something I shouldn't be doing for some reason or would be frowned upon.

Improve this question

1 Answer 1

Reset to default
3

You can read the rationale from the RFC https://trac.osgeo.org/gdal/wiki/rfc59.1_utilities_as_a_library and from the blog post https://erouault.blogspot.com/2015/10/gdal-and-ogr-utilities-as-library.html.

The main advantages are :

the utilities can be easily called from any of the supported languages : C, C++, Python, Java (C# and Perl untested at time of writing, but should work with slight changes).

in-memory datasets can be used for input and output, avoiding the creation of temporary files on permanent storage.

a callback for progress report and cancellation of the processing can be provided. faster execution for repeated calls (in comparison to the case where an external process was spawned)

There is no need to change your code if you are satisfied with it. The command line tools are using the library functions and the results will be uniform.

Improve this answer
4
  • So if I'm understanding right. GDAL/OGR is the software. The stuff we use in terminal/shell, such as ogr2ogr or ogrinfo, is actually C/C++ code that is using the software's API to create typically used functions. Then the Python module's gdal and ogr that we import are using those C/C++ functions. It can sometimes take longer to get to the same functionality because one of the purposes of the Python module is to create opportunities to stage things in-memory. Am I relatively in the right ball park? Thanks.
    – AskioFrio
    Commented Mar 8, 2021 at 8:32
  • Yes, after all you are finally running C/C++ code from here github.com/OSGeo/gdal/tree/master/gdal. Ogr2ogr library is github.com/OSGeo/gdal/blob/master/gdal/apps/ogr2ogr_lib.cpp and you can use it with Python bindings which are here github.com/OSGeo/gdal/tree/master/gdal/swig/python.
    – user30184
    Commented Mar 8, 2021 at 8:43
  • Oh woah, I never really stopped to think about how it all works. So I downloaded the entire repository when I do something like 'conda install gdal.' That includes the main software in C/C++, the terminal functionality, and the Python bindings. When I import, I do 'from osgeo import gdal' because that is the actual folder structure inside the python folder in the repo. When I run the python code, its primary function in relation to gdal is to generate swig objects. It exits the python module and transfers those swig objects to the C++/C parts of the repo to actually execute the functionality.
    – AskioFrio
    Commented Mar 8, 2021 at 9:49
  • 1
    I had assumed the way it works was that GDAL was essentially reprogrammed into a standalone Python version that I was then using. But from my understanding now, I downloaded all of it included the C/C++ parts when I downloaded the repo, and it is actually constantly moving between the C/C++ files in the repo and the Python files whenever I use any of the functions. I'm not sure if all of that is right, but that is pretty cool. Thanks for your help.
    – AskioFrio
    Commented Mar 8, 2021 at 9:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.