[Suggestion] Define Scale instead of bed size

[ekainz]

It could be interesting to set a scale factor instead of defining the bed size. This would allow the layer lines to convey meaningful information. While the math for this can be done manually, it is difficult when using KMLs.

[ChHarding]

So how would that look like in practice? Would we have a scale-down-by factor (say 1000) that would divide the real world size by it? Or are you talking about z-scaling in a way that each layer will correspond to say 10 m intervals?

On Feb 2, 2023, at 23:19, Fwappy @.**@.>> wrote:

It could be interesting to set a scale factor instead of defining the bed size. This would allow the layer lines to convey meaningful information. While the math for this can be done manually, it is difficult when using KMLs.

— Reply to this email directly, view it on GitHubhttps://github.com/ChHarding/TouchTerrain_for_CAGEO/issues/67, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEYDF5OI3AE5W7ZDG23GQHLWVSIPNANCNFSM6AAAAAAUP3AQ4U. You are receiving this because you are subscribed to this thread.Message ID: @.***>

Chris Harding Associate Professor Department of Geological & Atmospheric Sciences Touchterrain.geol.iastate.eduhttp://Touchterrain.geol.iastate.edu

[ekainz]

yeah exactly, we would divide the real world by lets say 1000 in every direction. I am currently printing a few islands for a friend and it is difficult to maintain scale between the islands unless I export everything in one session.

[ChHarding]

I can explore that but with some caveats:

You would have to use this as a manual setting, sth like “set_scale”:1000 . Otherwise it would prb be confusing to most other users and I want to keep the UI simple.

There is an issue with getting exactly the scale you want b/c initially the area extent is in lat/long (on the Google map) and only further down the line will your area by converted into a meter based system (UTM) and that will slightly warp the area. That means that you want a scale in 1:1000 but it’s com out as 1:1006.233434. The exact imprecision depends on the latitude, it will be worse the farther you get to a pole.

Also, this is just me thinking about it, I’ve not actually looked into the code so maybe I’m overlooking something important.

On Feb 3, 2023, at 13:07, Fwappy @.**@.>> wrote:

yeah exactly, we would divide the real world by lets say 1000 in every direction. I am currently printing a few islands for a friend and it is difficult to maintain scale between the islands unless I export everything in one session.

— Reply to this email directly, view it on GitHubhttps://github.com/ChHarding/TouchTerrain_for_CAGEO/issues/67#issuecomment-1416283090, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEYDF5PLDZTDFSU2LVESHCLWVVJNJANCNFSM6AAAAAAUP3AQ4U. You are receiving this because you commented.Message ID: @.***>

Chris Harding Associate Professor Department of Geological & Atmospheric Sciences Touchterrain.geol.iastate.eduhttp://Touchterrain.geol.iastate.edu

[ekainz]

That's totally fine, thanks for looking into this idea!

[ChHarding]

I think this is do-able. I'm currently considering dividing the real-world width of the selection box by your scale factor. E.g 2000 m wide divided by a factor of 10,000 would set the buildplate to be 0.2 m wide Is that OK or would you want want that number to be in mm, which seems to be the common unit for buildplates?

[ChHarding]

I've implemented a tilewidth_scale option that calculates a new tilewidth (i.e. buildplate width) from that (in mm). I tested it with online data and it seems to work, but the final scale is a bit off (I requested 1:100,000 and the final output was 1:104,000) This has to do with trying to compensate for distortions but the compensation is pretty simplistic.

[ekainz]

Awesome thank you!