Curious if anyone else has encountered this before and may have an explanation:

In my Python workflow, I'm importing fiona (1.8.4) to manipulate shapefiles, and then later downstream I'm shelling out to gdalwarp to reproject a GeoTIFF using python's subprocess.check_output to make system calls..

Most of the time, this works flawlessly. But for certain EPSG codes, I'm seeing some very odd behavior I'm hoping someone can shed light on. With EPSG 26749 as target, the reprojected boundaries are only correct if I don't import fiona in the lines above.

My suspicion is that my pip install of Fiona is pointing to out of date GDAL libraries lurking around my system, but what I really don't understand is how this could possibly be affecting the behavior of the call to the gdalwarp binary outside of Python?

While I dig in and try to fix my Fiona GDAL dependancies, I would love to know if anyone can explain how importing a gdal-dependent module in Python could then affect the behavior of an external GDAL call... but only for the duration of the Python script?

  • How are you "shelling out" the gdalwarp call? – Marc Pfister Dec 19 '18 at 21:41
  • Just using python's subprocess.check_output to make system calls. – Chris Sullivan Dec 19 '18 at 21:48

Importing Fiona can set some GDAL library paths, so you may want to run your subprocess using a copy of your original environment before the Fiona import changes anything.

import subprocess, os
my_env = os.environ.copy()
import fiona
# do your thing
subprocess.check_output(my_command, env=my_env)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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