fgebhart / mapa Goto Github PK

How about offering the possibility to cut the selected (square) area into (square) tiles - 3x3 & 4x4 should be sufficient.
With this feature it would be possible to print a larger area in pieces that can be glued together.

Is it a big deal to enable the user to rotate that selection rectangle?

Pls display the app's version number in e.g. the "About"-window. When testing it I refresh the page but I can't be sure if it's properly reloaded or if I have to flush my browser cache. Having a version number would be great to verify.

This is probably not very important, but it would be nice to have units displayed. For example there's no unit shown on the Z-offset slider. Since this value is directly related to the resulting object's dimensions it would be nice, too to show some information about how large the resulting model will be.

Typical use case: I want the object to be exactly 1cm thick (base height). I set that and generate the object. In my slicer I notice, the object is too large for my printer and I have to scale it down by 50%. Now my object is only 0.5cm thick. Arrrgh! Back to the website, set the offset to 2cm, re-generate, ...

Dream-solution A: after the rectangle has been drawn, the dimensions are displayed with the possibility to scale them (with locked ratio).
Dream-solution-B: a value can be entered for the largest object-dimension - if it's set to "square" that value will be used for both dimensions.

The slider to set the Z-scale is a bit too sensitive. Trying to set that value to e.g. 4 takes several attempts. How about limiting it to .1-steps or implement a kind of snap-to-integer?

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:

There are now a lot of controls to modify the output except one: the simplification-voodoo you do with that geometry.
I exported a large area first and then a smaller part from that area as a second model. I noticed that the smaller area resulted in a larger file = higher resolution. That's great on one hand (great details on the small one) but bad on the other hand (lack of detail on the large one). And yes, this makes sense if the object would be printed in one piece (print resolution) but my plan is/was to export a large area and cut that into smaller parts to print (like the suggestion I made earlier) - but with the lack of detail this is pointless :(

How about a Geometry Compression-slider to let the user decide how fine the resulting model will be created? Maybe with an estimation of polycount & file size displayed?

I rectangled an area and tried to do it as square as possible. I enabled "square output". On the resulting model the desired center was positioned too far to the right.

I wonder if it's possible to draw the rectangle from the center outwards (not from corner to corner) and make that center on the map stay the center on the model.

I just rectangled an area, generated and exported the stl. I then noticed, that the centered city was way off (that's another issue...) and shifted the rectangle sideways (and saved the change). I then re-generated the stl (it was much faster than the first time) and downloaded the new version - same filesize, strange. I then noticed that it was the exact same model!
Conclusion: the edit-rectangle-tool does not change the generated model, it does not re-generate but takes the previous data.

Two sides of the output STL file seem to have issues with open connection between triangles of the 3d surface mesh and the side triangles. See e.g. this screenshot:

The generated model's bottom surface has two flaws:

1. It is not connected to the side walls so those edges down there are all open. This was reported in the slicer and I verified it in an 3D-tool.
2. It is not triangulated properly (only once into two triangles): all those edges coming down the side walls from the top relief end and are not continued further to e.g. a center vertex. This results in two massive n-gons the bottom surface is made of.

Maybe these two issues are related?

The handling is a bit akward because of the different projections. If I want to have a 3x3 tiled squared model I first have to output it untiled to check if the wanted area is correct. I have to do this several times because there are two stages of "blindness": first the selected area has a different ratio on the map-screen then on the object, second the squared-mode alters the selection. When this procedure is finally done I can switch to 3x3 and output the final model.
This workflow is soooo annoying!
Isn't there a way to create a kind of preview? Some outlines on the screen-map to see the resulting ratio & area would be most helpful. I know about the different projections but there has to be a way to calculate this beforehand.
A model-viewer to see the computed model in low-res would be great but I guess a lot of users would mistake the low-res-preview for the final model.