Topic: Mark rivers on a map

[isidoro]

I'm building with my cousin a ST map based on real geography.  It isn't very hard, and we have already done it, to get a height map and import it to ST.  But rivers are a pain.  If we could place rivers more easily, cities could also be placed easily relative to them.

I've got an idea, but I need to know if that's feasible.  River data can be extracted from Open Street Map quite forwardly.  Geographic coordinates can easily be translated to ST tile coordinates as well.  But is there a way to mark those tiles so that, afterwards, we could manually build the rivers?

I've thought of the Squirrel scripting interface.  Is there a function in the interface to mark a tile (with a sign, for instance)?  Can I read an external file from Squirrel, parse it and place the signs accordingly?

[Dwachs]

I've thought of the Squirrel scripting interface.  Is there a function in the interface to mark a tile (with a sign, for instance)? 

yes, there is: label_x::create http://dwachs.github.io/simutrans-sqapi-doc/group__game__cmd.html#ga54a82cd7bbe9e98f649ba51da9849e1d

Can I read an external file from Squirrel, parse it and place the signs accordingly?

There are very low-level functions (fopen, fread, etc), see squirrel/sqstdlib/sqstdio.cc

There is also the possibility to include other squirrel (*.nut) files. Squirrel syntax for arrays is very similar to JSON. This might be the easiest way to import something, as you do not have to parse the data.

You could also write a script, which places the river.

The biggest problem with imported maps is that the river bed is present, but it needs terraforming before the river can be placed.

[isidoro]

Thank you, Dwachs.  I'll give it a try.

Now, all the terraforming and placement is done manually.  If I can manage to do what I want, at least the placement can be automated.  I'll share it here if I get something workable.

[prissi]

Can you use the water fill functions on riverbeds for that?

[isidoro]

Sometimes it's possible to know where the river bedis just with the heightmap, but other times the height coordinate lacks precision and you don't know where the river flows in RL.

If, on the other hand, you refer to use water fill functions from Squirrel to mark where the river is (instead of labels), are there such functions available and, if so, can they be used in tiles that aren't flat?

[isidoro]

Progress has been nice here:

• I've managed to download a pretty nice heightmap with sea depths too and translate to ST nicely
• I've also managed to extract river data from OpenStreetMap without much problem
• The script scenario seems to work and mark the tiles accordingly

But I have a question: once I manage to draw the rivers and cities, can I get rid of the scenario in the .sve file or that isn't possible?

What happens if I choose a .sve with an active scenario as a base .sve file for another?

Reason is that if I can't strip the scenario to get the bare .sve, I could only do all the rivers in one pass, couldn't I?

[Dwachs]

But I have a question: once I manage to draw the rivers and cities, can I get rid of the scenario in the .sve file or that isn't possible?

It is a bit tricky: you should make sure that the scenario does not load properly (rename, make syntax error, etc). Then the savegame will load, but with no scenario. Then you can save again.

What happens if I choose a .sve with an active scenario as a base .sve file for another?

Good question: I think the old scenario will be killed and overwritten with the new one.

[isidoro]

Thank you, Dwachs!

I'll share the scripts I've used if everything works properly.

[isidoro]

I wanted to post this here and it ended in another related thread (it can also go there, by the way):
https://forum.simutrans.com/index.php/topic,18070.msg171853.html#msg171853

First results of marking in a wip map.

[isidoro]

Today, I've tried to introduce data from a whole basin, and I've noticed that some of the labels don't get created and what's more strange, it depends on the execution.  Does anyone know a possible reason for this?  Can the engine get "clogged" if too many objects are created quickly?

And another pair of questions: is init() rerun each time the .sve is loaded?  What would happen if I create a label again on the same tile?

I'll try to figure out the questions myself, but just in case any of you know the answer.

[Dwachs]

Today, I've tried to introduce data from a whole basin, and I've noticed that some of the labels don't get created and what's more strange, it depends on the execution.  Does anyone know a possible reason for this?  Can the engine get "clogged" if too many objects are created quickly?

The only reason I can think of is that the placement is not possible because something on the tile blocks it.

And another pair of questions: is init() rerun each time the .sve is loaded?  What would happen if I create a label again on the same tile?

When starting a scenario the method start() is called. When loading a savegame with active scenario resume_game() is called. I do not understand to what init method you refer

[isidoro]

That's right.  The right name is "start()".

For what you say, it seems more likely that the labels are created well, but for some reason, they aren't displayed properly.  Reason is that they are created in start(), since start() is only called when starting a new scenario and labels appear when reloaded the savegame, it only makes sense that labels are already there, but for some reason, not shown properly.

By the way, after doing some research, if you try to create a label where there's already one, that new label is silently ignored.  Labels are kept in a global array, the index of which is the coordinates of the tile.

The more I use the scripting interface, the more I like it.  It's full of potential.

[isidoro]

Excuse me for posting again in less than 24 hours, but there was some progress I'd like to share.

It isn't very hard to make the rivers from the labels, not easy however.  The worst thing is to have to do earthworks to be able to build the river.  And that implies deleting all the labels that can be affected by those earthworks.  So you get somewhat lost without the very labels that helped you.  Looking at the source code, it doesn't seem to me to be necessary to remove labels to do earthworks.  Could that condition be relaxed?

Attached is an image of the Tagus river built with the method proposed in this thread.

[Isaac Eiland-Hall]

Excuse me for posting again in less than 24 hours,

The double-posting rule has been relaxed, just so you and others know

[Dwachs]

Why not let the script do the terra-forming and river laying?

[Yona-TYT]

I think it's a good idea to use climate editing tools for that, since a river would look very small in comparison to the real one. 

[isidoro]

Why not let the script do the terra-forming and river laying?

Is that possible?  I haven't seen the appropriate methods in the interface...

[Dwachs]

Terraforming is not in the interface yet. For waybuilding, you can look into

https://github.com/Dwachs/simutrans-scenarios/blob/master/ai/sqai/astar.nut

which implements a road builder

[isidoro]

Very interesting!  I didn't check the command_x class.

It will certainly be much more easier here than in the builder you programmed, since the path is mostly explicit (no need of Djisktra or similar).  But there's a problem I have detected, which could make the task of building the rivers very hard, if not impossible.

If you try to build a map from the heightmap I attached here, you'll notice that the map won't be symmetric although the heightmap is.  I guess that it has something to do with the algorithm used to translate gray levels in the heightmap to real heights in ST maps.  In fact, something has have to be done since in real heightmaps a difference in heights of more that two ST levels is possible, while in ST map, it isn't.

All that leads to random offsets in the places where the labels are placed (based on geographical lats and longitudes) and where the valleys of the rivers go.  Those corrections must probably have to be done by hand.

Test heightmap: http://ge.tt/5MFvxMp2

[Yona-TYT]

Very interesting!  I didn't check the command_x class.

I have used it a lot, especially in the scenario tutorial. 

[uci]

If you try to build a map from the heightmap I attached here, you'll notice that the map won't be symmetric although the heightmap is.

I get a symmetric ST map from your heightmap!

[isidoro]

I get something more or less symmetric, but not perfectly symmetric.

The heightmap is 512x512, so the centre should be between pixels 255 and 256 in both dimensions and the top layer should be a square.  None of both things seem to happen to me.  It's a rectangle and slightly shifted.  That is the reason why I think I get more or less plus/minus 1 pixel error in locations of valleys and rivers, depending on orientation and location in the map.

[uci]

The problem is that you have to use a RLE encoded bitmap file (256 colors).
I attached a correct version of your image.

https://simutrans-germany.com/files/upload/gradient2.bmp

[isidoro]

Good point!

Another difference is that my bitmap is 3 bytes per pixel while yours is 256c.

But even when doing it with you map, if you pay close attention, the levels below 0 are all 3 tiles wide and the levels above 0 are two tiles wide if the level is odd and four tiles wide when the level is even.  That doesn't make much sense either and could produce that plus/minus 1 tile error.

Unfortunately, now I have completed the whole Tagus basin and can't restart and import the map with a bitmap like the one you propose. That would mean to redo all the work...

[uci]

Your image does not have a uniform distribution of gray levels. For example, level 131 is missing.

Here is a correct version of your image with equidistant levels
https://simutrans-germany.com/files/upload/gradient3.bmp

[isidoro]

Thanks.  I'll check it.  If that's true, then there's apparently no reason I can see why there's that offset other than rounding errors...