New assets: geotiff2scad.py script and worldmap_360x180.scad

[amatulic]

@RAMilewski - here are two new files:

• /examples/worldmap_360x180.scad - for using with the include command to make a texture
• /scripts/geotiff2scad.py - for converting GeotTIFF data to .scad or .json formats

Use the command

python geotiff2scad.py --help

for a description of commandline options. All have defaults if you don't specify anything at all, but then your input file needs to be named geotiff.tif and you'll get a file terrain.scad for 360 px wide and a proportional height based on aspect ratio.

The code comments have some suggestions for getting other GeoTiff data but it seems you have to dig pretty hard.

[RAMilewski]

When I try to execute it I get:

./geotiff2scad.py: line 36: syntax error near unexpected token (' ./geotiff2scad.py: line 36: parser = argparse.ArgumentParser('

Are there any dependencies I need to have. I'm on MacOS on Apple Silicon.

[amatulic]

Do you have rasterio library installed for python?

[amatulic]

I have updated geotiff2scad.py to include checks for the required libraries and output instructions if any are missing.

[RAMilewski]

Something still isn't right.
It also looks like it may be related to my ImageMagick installation. I've included the full terminal session in error.txt.
error.txt
Also attached is the zip file containint the geotiff I've been using to test. (Salem.tif).
Salem.tif.zip
Github won't let me attach a .tif file here.

[amatulic]

Why is imagemagick being invoked when you run geotiff2scad.py?

Try running it as
python geotiff2scad.py --help
instead.

[amatulic]

OK, I tested it with your Salem.tif file and found a small issue. However, I cannot reproduce the error you're getting.
The first time you run it, do it standalone without invoking it indirectly through some other program.
Run it as python geotiff2scad.py --help the first time, which documents the commandline parameters.

Version 3 is now in this PR.

[RAMilewski]

OK! That seems to be working. Can you explain the scaling a bit? Is it all three axes, or just the Z axis?

[amatulic]

The --resize argument scales the x and y sizes to the width and height you specify. If you specify only width, then you get that width, and the height is determined by the aspect ratio of the original image.

For z, elevations above zero are scaled to the range 0-1, which is what BOSL2 texturing expects. That scale factor is then applied to negative elevations. Negative elevations would end up in the range 0 to -1. For Earth, because the oceans are deeper than the tallest mountains, the lowest values go down a little lower than -1.

There is a default "gap" inserted from -0.03 to +0.03 at sea level. This is to raise all low-level land features slightly above sea level, and lower all sea features slightly below sea level. In this way a map of the earth doesn't end up with near-sea-level lands like the Florida penninsula being indistinguishable from the sea. In effect, the land isn't scaled from 0 to 1, but from 0.03 to 1.

[RAMilewski]

It looks like it always outputs 2:1 aspect ratio data if you specify only the width with -r.

[amatulic]

Aargh. I had the commandline documentation say it used aspect ratio but didn't put that in the code. Trivial fix.

Now when I read Salem.tif with --resize 360, it comes out 360x262 instead of 360x180.

[RAMilewski]

I think if you invoke geotiff2scad.py with no arguments at all it should either show a list of the arguments (e.g. -h, -o, -v, -r, -s) or just show the help as -h does.

Oddly if I pull the 3 arc-sec SRTM geotiff for Salem, OR from the USGS Earth Explorer and run it through geotiff2scad.py then try to use that on a textured_tile() it fails with:

Assertion '(check == [])' failed: "texture extends too far below zero (-3.2) to fit entirely within height 0.1"

I guess I have to play with --min_land_value. It might be good to have the comments at the start of the output file also sent to the console at run time.

[RAMilewski]

I think I just needed a thicker tile for that data. Still testing.....

[RAMilewski]

If I set --min_land_value 0 the OpenSCAD parser throws a syntax error in terrain.scad.

... and if set to > 1 it inverts the z. It should maybe be a boolean?

[RAMilewski]

Zipped Salem.tif and Mt.Hood.tif
tifs.zip

[amatulic]

OK, new version for 14 May 2025:

• Added .png file output capability
• Removed --json argument. --output file type is now determined by the file extension in the output file name. The extension can be .scad, .json, or .png.

Tested with the old salem.tif to save a png file and found it interesting, with a black circle in the middle and text at the bottom, which weren't obvious in the .scad texture. I'm glad I added that PNG output capability. It's a good way to preview the GeoTiff data.

Let me know if any other changes are needed, otherwise this could be merged into the library.

Also, should worldmap360x180.scad be included for a demo? It's in this PR. I can include a different one if you want, based on what you're doing.

[RAMilewski]

I think the worldmap should be included. I'll be using that as an example in the tutorial. I think rationalizing the file naming between geotiff2scad.py and img2scad.html would be helpful. (dropping the widthxheight in the file name). That would mean you don't have to re-write the include to switch between the two in a project.

[amatulic]

Actually I was thinking of adding WxH to the file name in geotiff2scad.py. In my tests I was creating several different sizes and needed an easy way to tell them apart.

On the other hand, geotiff2scad.py includes this information in code comments in the output file. I could do that with img2html.scad too.

[RAMilewski]

I would prefer to have the size in the code comments. Also it would be good to send those comments to std out for the python scripts.

[amatulic]

Latest changes:

• img2scad.html now puts the size in the code comments. The size is still part of the file name, because I find myself outputting different file sizes for the same input file and array name.
• geotiff2scad.py now outputs stats to the console.

[RAMilewski]

Do we really need 2 greyscale conversions in img2scad.html? If so, then maybe relabel Linear to Linear (sRGB)?

[amatulic]

The conversions are visually different for color images. The idea was to let you choose whichever one appears best, which would depend on what colors dominate the input image. It doesn't matter if the input image is already grayscale. So far, in the examples I've tried, the NTSC conversion looks best to me, but people may want the other one because OpenSCAD uses it in surface().