Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problematic logic on lower-than-sea pixels #11

Open
ahmetlii opened this issue Jul 13, 2024 · 1 comment
Open

Problematic logic on lower-than-sea pixels #11

ahmetlii opened this issue Jul 13, 2024 · 1 comment

Comments

@ahmetlii
Copy link

ahmetlii commented Jul 13, 2024

Steps to reproduce:

  • bother --scale-data 0.5 --bounds 38.05 39.33 48.00 51.00 test.png --raise-undersea
  • Scale the map and open in OpenTTD

As one might notice, passing --raise-undersea exacerbates the issue, most of the intended land is still below water. What happens if --raise-low is passed? The situation becomes even worse, not only that it doesn't work it causes huge rectangles over the sea to show up.
After tinkering out a bit and looking at alternatives such as Tangram, I figured out that the idea behind --raise-undersea is just wrong. What should have been, is that the option would specify what is the threshold for minimum land level, which should have been around -28m for this use-case instead of 0, and should convert that to above sea level before scaling between 0-255. of course one might also say that using --lakes could solve that, but as far as I figured out it doesn't.

@bunburya
Copy link
Owner

Thanks for flagging this. It seems what is happening is that values < 0 are being raised to 1m above sea level, but are then subsequently rounded back down to 0 when converting elevation to 0-255. This is indeed what --raise-low is intended to address, but as you note it just produces nonsensical results here. The reason seems to be that a large part of the Caspian Sea is in fact given an elevation of -29 in the underlying data (not NODATA as one might expect with a large body of water). So it is not distinguished from land that is below sea level and also gets raised (the squares of water that remain are the areas that are NODATA).

So the way to solve for that is to use --lakes, but using it with the default setting (treating all areas of 80 pixels or more identical elevation as lakes) turns a lot of the map into lakes. I played around with larger values and got somewhat better results. So this command:

bother --scale-data 0.5 --bounds 38.05 39.33 48.00 51.00 --scale-image 512x1024 test_lakes.png --raise-undersea --raise-low --lakes 15000

gives the below map:

1721496375

I scaled it to 512x1024 so it might look a bit skewed but water placement at least seems improved. Using lower values for the --lakes argument will add more lakes (which may or may not be an improvement).

What should have been, is that the option would specify what is the threshold for minimum land level, which should have been around -28m for this use-case instead of 0, and should convert that to above sea level before scaling between 0-255.

I think a problem with this is that other water values which are >= -28m in the data will also get raised to above sea level. For example, a lot of the Black Sea in this map has an elevation value of 0. So then you're back to calling --lakes to fix that. (Also, you'd have to know what the minimum land level is.)

To be clear, raising undersea pixels does happen before scaling to 0-255. That is part of the problem, because if they are not raised high enough they will just get rounded back down to zero (which is what --raise-low is supposed to fix).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants