odd y-axis scaling of output .stl

[elliotsymons13]

Hello,

I came across your tool and have been trying it out as a more customisable/extensible alternative to Terrain2STL. I am interested in producing a 3D print of the English Lake District. However, I have noticed that the output of mapa appears to be 'sqashed' in the y axis, when compared to Terrain2STL outputs, and to a map also.

Am I missing something in my configuration, or is this a bug?

Happy to provide more info if I can, but hopefully the below is enough

Thanks in advance :)

---

I installed mapa for python 3.10, using py -3.10 -m pip install mapa on Windows. I added mapa to my path in the standard way, and then launched it with mapa in PowerShell. That said, the same distorition was seen in the streamlit app so I am not sure this can be an issue with the python version or similar.

In the below images I have circled a recognisable mountainous feature. I think you can see that it is 'squashed' in the y axis. Other elements also appear squashed. This is further demonstrated by the fact the output of mapa was quite rectangular, when the input area was rather square.
Terrain2STL output for the Lakes:

Map screenshot for Lakes:

mapa streamlit input for Lakes:

mapa streamlit output for Lakes:

I can reproduce a similar distortion of the output in the jupyter notebook version
Input:

Configuration:

path = convert_bbox_to_stl(
    bbox_geometry=drawer.last_draw["geometry"],
    output_file="E:/Projects/3D Printing/Mapping/MapaOutput/mapa_output",
    model_size=100,
    z_offset=3.0,
    z_scale=1.5,
    max_res=False,
    ensure_squared=False,
    split_area_in_tiles="1x1",
    compress=False,
    cache_dir="E:/Projects/3D Printing/Mapping/MapaCache"#"/home/fabian/make/mapa/cache/"
)

Logs:

INFO:mapa:⏳  converting bounding box to STL file with arguments: {'bbox_geometry': {'type': 'Polygon', 'coordinates': [[[-3.43857, 54.223622], [-3.43857, 54.713639], [-2.630972, 54.713639], [-2.630972, 54.223622], [-3.43857, 54.223622]]]}, 'as_ascii': False, 'model_size': 100, 'output_file': 'E:/Projects/3D Printing/Mapping/MapaOutput/mapa_output', 'max_res': False, 'z_offset': 3.0, 'z_scale': 1.5, 'ensure_squared': False, 'split_area_in_tiles': '1x1', 'compress': False, 'allow_caching': True, 'cache_dir': 'E:/Projects/3D Printing/Mapping/MapaCache', 'tiles': TileFormat(x=1, y=1)}
INFO:mapa.stac:⬇️  fetching 2 stac items...
INFO:mapa.stac:🚀  1/2 using cached stac item ALPSMLC30_N054W004_DSM
INFO:mapa.stac:🚀  2/2 using cached stac item ALPSMLC30_N054W003_DSM
INFO:mapa:🎉  successfully generated STL file: E:\Projects\3D Printing\Mapping\MapaOutput\mapa_output.stl

Output:

[fgebhart]

Hi @elliotsymons13 - thanks for trying mapa and reaching out!

I believe this is a map projection issue (see different projections).

I did come across this issue myself and assume it is related to the how the map is projected to our 2 dimensional representation of the map. Mapa uses ipyleaflet and OSM data to display the map and draw a rectangle for your area of interest. The corners of the rectangle are then used to fetch the elevation data from the planetary computer data collection. The OSM representation of the map is projected (mercator I assume) but the planetary computer GeoTIFFs aren't. I believe this is why the resulting 3D model looks skewed in the Y-dimension. But maybe I'm wrong, I'm just not sure (yet). Assuming that my hypothesis is correct, that would mean, that the resulting 3D-model is actual the right representation of how the earth surface looks like and the mercator representation in OSM is actually skewed.

Unfortunately I don't have much time currently to look into this in more detail, but I'll give you (or anyone else) some pointers where mapa deals with projections aka coordinate reference system (CRS), so you could play around a little and investigate the impact of it.
Here:

mapa/mapa/raster.py

Lines 24 to 31 in e8933d1

	out_meta.update(
	{
	"driver": "GTiff",
	"height": out_img.shape[1],
	"width": out_img.shape[2],
	"transform": out_transform,
	"crs": data.crs,
	}

And here:

mapa/mapa/raster.py

Lines 105 to 112 in e8933d1

	out_meta.update(
	{
	"driver": "GTiff",
	"height": mosaic.shape[1],
	"width": mosaic.shape[2],
	"transform": out_trans,
	"crs": data.crs,
	}

My intention was to preserve the CRS of the used data, but one could think to apply a different projection here.

A hacky workaround for the time being would of course to stretch the Y-dimension within your slicer before 3d-printing.