Windows support

[jimenofonseca]

Hi @alexamici , I am trying to get the library to work in windows x64/x32. But I find that either the GNU make library is not working properly, or there is an internal error somewhere.

I managed to install the GNU library from conda -forge
make=3.82=0

These were the commands I am trying:
bounds = (float(lon_min) - .05, float(lat_min) - .05, float(lon_max) + .05, float(lat_max) + .05) elevation.clip(bounds=bounds, output=terrain_tiff_out_path, product='SRTM1') elevation.clean()

This is the error message i get:

I appreciate your advise, thanks!

[sebastienaubry]

Hello,
I think we got exactly the same problem, and that #37 is a duplicate of this issue.

This seems to be an incompatibility with Windows?
Thanks

[romainastie]

For those who are using this package and appear to be having this issue -
I've been banging my head against a wall on this one for the past three days. It seems we are all running some version of Anaconda - and that is the root of the problem. Make doesn't play nice with Conda's environments, and somewhere along the line, your regular Python install gets called. This will cause problems if your system python installation doesn't have the same packages as your conda install. For me, I was missing the command line tool gdal-translate, which on Ubuntu Linux is installable with the Terminal command sudo apt-get install gdal-bin

Running and installing the gdal suite at the system level fixed my problems. Not sure what the windows equivalent would be.

[ioanbalau]

For Windows users:
Try deleting files: java.exe, javaw.exe and javaws.exe from Windows\System32.

I had the same issue and it was generated by old version of Java 1.7

[seedlit]

@romainastie I am facing the same issue, and I am running Ubuntu 20.04
I already have the command line utilities of gdal. And I have never used anaconda on my machine.
I am unable ti find a solution.
Did anyone else solve this on a linux machine?

[and-viceversa]

I ran into this issue on masOS Mojave 10.14.6 while running working code on a different machine.

From both OP's trace and my own, the offending call seems to be in elevation/util.py:

def check_call_make(path, targets=(), variables=()):
    make_targets = ' '.join(targets)
    variables_items = collections.OrderedDict(variables).items()
    make_variables = ' '.join('%s="%s"' % (k.upper(), v) for k, v in variables_items)
    cmd = 'make -C {path} {make_targets} {make_variables}'.format(**locals())
    subprocess.check_call(cmd, shell=True)
    return cmd

It's got shell=True. I was running from PyCharm with a conda env, but in reality bash is invoked during that step. The dirty solution was to install gdal upstream - but there's gotta be a better way. This seems like too common of a use case for there not to be a best practice.

[CHELOBV]

Have someone ever resolve this issue? I have the same exact trace in Windows 10

[JamesMH95]

Was this ever resolved? having the same issue as @and-viceversa in the same situation.