Hey,

Wondering if anyone could give me some insight on a small issue I'm having. Trying to create some US tiles using the 1/3" USGS mesh. I modified the appropriate files from this post, as the default built-in function seem to have stopped working.

Using the binary version of Ortho4XP does not seem to download the .tif files. It quickly says it's downloading an .img file and renders the mesh completely flat.

Using the Python version does correctly identify the change and downloads the DEM files, yet I'm hit with a "WARNING: unsupported raster (install Gdal)" that also gives me a flat mesh. Despite having installed GDAL correctly per the instructions and added the Python / GDAL folders to PATH

Manually downloading the mesh from here and using it in the binary version works fine but is obviously tedious work. 

 

So how do I get the binary version to correctly read the src folder changes? or how do I stop the python version from complaining about GDAL missing?

11 hours ago, Sethos said:

or how do I stop the python version from complaining about GDAL missing?

Can you call GDAL from a cmd window? If not, you might need to add the path to the GDAL exe to your user env path so that Python can see it too? That or modify the .py  src further to call the exe with the full path? It might be assuming it's in the Utils dir alongside DSFTool and the others.

The binary version is a compiled binary blob. It won't see any changes you make in the src folder.

9 hours ago, blingthinger said:

Can you call GDAL from a cmd window? If not, you might need to add the path to the GDAL exe to your user env path so that Python can see it too? That or modify the .py  src further to call the exe with the full path? It might be assuming it's in the Utils dir alongside DSFTool and the others.

The binary version is a compiled binary blob. It won't see any changes you make in the src folder.

Hey,

Yeah I can call the GDAL commands that I've found it uses through various .py files, both gdalwarp and gdal_translate. Plus I can also call it on gdalinfo --version; https://i.imgur.com/XA9nG6q.jpg

In my search through those .py files, as you suggested, I also tried finding if it called them from a specific location, i.e a folder or something but I can't seem to spot it. Seems like it's just trying to call the command.

I'll do some more digging through the src files, see if anything stands out but at this point I'm rather stumped.

4 hours ago, Sethos said:

Seems like it's just trying to call the command.

I haven't touched o4xp for a while now...been using vstates for ortho. Though it is much more coarse than 1/3", which looks amazing when it works.

Yeah, so that's my point. In those (looks like os.system calls) lines, insert the full path to the exe 'c:\...'. Or figure out where it's assuming the exe will be, and drop gdal.exe into that dir.

I return with what appears to be a solution. After spending far too long on this problem, I stumbled on a comment that gave me a heureka-moment.

Ortho4XP is built around older versions of GDAL. I saw someone mention that "import gdal", that Ortho4XP calls, is no longer working in the new versions. New command is "from osgeo import gdal".

So I headed into "O4_DEM_Utils.py" in the src folder and changed "try: import gdal" to "try: from osgeo import gdal", on line 11.

Now it's correctly building the mesh.

EDIT: It appears I may have been sitting on an outdated version of 1.30(?), at least one that includes the binary, because the latest GitHub of Ortho4XP does seem to have that change.

Edited August 6, 20232 yr by Sethos

Ah yes. Python-version-upgrade-pain.

Many thanks for starting this topic. I used USGS 1/3" and the results are absolutely stunning!