News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

Bug: Ship canal not buildable above certain altitudes?

Started by AP, August 30, 2017, 04:43:40 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

AP

In my latest game, the Ship Canal refuses to build above contour -3 (sea level being -8), even though there are large rivers at much higher altitudes. Is this deliberate behaviour? It will happily build on the lower terrain.

This is on flat open countryside with a solvent company.

Rollmaterial

The behaviour is intended to simulate canals needing a source of water. Thus the higher the altitude, the smaller the canal can be.

AP

In which case,  it doesn't work, and should be scrapped.  It's too crude a method if it doesn't analyse the map. And building a better method of restriction is probably quite hard.

My map has numerous large rivers nearby at higher altitudes,  which ships can already use,  and which I quite reasonably want to join together and build branches and shipyards on. And this prevents me from doing so.

I also have an enormous high altitude inland sea I want to connect to the actual sea.

Lack of water not an issue in either case.

River width is, as has been noted elsewhere, simply derived from rivers joining together, not length or altitude.  So if 4 mountain streams join near the top of a mountain,  you get an epic width river all the way down the mountain.

jamespetts

This is indeed intentional as Rollmaterial points out: see this video for details.

It is realistic that larger canals cannot easily be built at higher altitudes because of the difficulty in getting water to those altitudes: larger canals were not in fact built at higher altitudes. This is one of the reasons that Cornwall, a hilly part of the country, had so many very small tub-boat canals. It is necessary to have a mechanism in the game that provides a realistic incentive to build the smaller canals.

It does not fundamentally undermine this basic reason that there are some circumstances in which specific river generation settings combined with the specific permutations of the random number generator occasionally produce large rivers at high altitudes. In any event, it is somewhat doubtful in reality that it would be realistically possible to harness such high altitude rivers as a reliable source of water for a large canal. If there is something that needs remedying, it is the prevalence of large rivers at higher altitudes, not the prohibition of canals at such altitudes, but it is unlikely that spending much time on such a feature will be worthwhile in the short term as having large rivers at higher altitudes occasionally does not of itself seriously unbalance the game and changing this would take a lot of time that could more profitably be deployed on more pressing features.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

AP

Not sure this is the right answer, this breaks water transportation at present.

The middle third of my map is an enormous inland lake, fed by multiple rivers the size of the Thames. And the excuse is "lack of water"...?!  It'd be like saying you couldn't build the Caledonian Canal, plenty of altitude gain on that, look at the locks at Banavie.

It's an arbitrary restriction. How is it coded, as a %  of map terrain range? Why not link it to the highest tiles of medium river instead?

Worth also being mindful that what is considered "high"  altitude should probably be as defined in the Climate settings at map creation e.g. as Mountains. Which this definitely wasn't. Now we have doubleslopes it's easy to get through quite a lot of contours but that doesn't mean you are actually in the alps.


I think it's the construction costs and maintenance that should encouraguh e different sized canals,  tbh. Land being expensive

DrSuperGood

The only reason larger canals did not exist at high altitudes is due to there generally being less running water at high altitudes, not that the altitude itself was limiting. Limiting by altitude results in the problem AP is describing, where there is an enormous high altitude lake due to geography but one cannot build cannals from it.

I would suggest making the maximum canal altitude a configurable map setting so it can be tailored on a per map basis to be realistic to the geography of that map. In the future maybe some water model could be created that limits canals to run from inland lakes or other water sources and their size is restricted by the flow potential of that source.

jamespetts

Thank you both for your feedback.

The way in which the maximum canal height is coded is using the max_altitude setting in each canal's .dat file. This defines a number of tiles above sea level beyond which the canal cannot be built.

The most straightforward solution, until there is somebody with the time and experience to build a full water/terrain model as Dr. Supergood suggests, is likely to be to apply a maximum altitude restriction to rivers and lakes, too (so that joining rivers do not create larger rivers if the larger river would be above the maximum altitude for that type and that lakes do not form above a certain altitude). As large rivers and lakes are less common at high altitudes in reality, then, absent a fully detailed water/terrain model, this would seem to be the most sensible way of resolving the anomaly described.

I should note that this is not currently a high priority issue in light of the other features/issues currently in progress.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

AP

Quote from: jamespetts on August 31, 2017, 10:30:48 PM
The way in which the maximum canal height is coded is using the max_altitude setting in each canal's .dat file. This defines a number of tiles above sea level beyond which the canal cannot be built.

The most straightforward solution, until there is somebody with the time and experience to build a full water/terrain model as Dr. Supergood suggests, is likely to be to apply a maximum altitude restriction to rivers and lakes, too (so that joining rivers do not create larger rivers if the larger river would be above the maximum altitude for that type and that lakes do not form above a certain altitude). As large rivers and lakes are less common at high altitudes in reality, then, absent a fully detailed water/terrain model, this would seem to be the most sensible way of resolving the anomaly described.

Without knowing how the code works at all - could you not simply make the canal builder check for an adjacent water tile of equal-or-greater width, when building?  That would ensure all canals start from an adequate source of water.

You could augment that with a second check that the water tile should be at equal-or-greater height as well, if you wished (perhaps only doing this prior to the date pumping stations become available*).

This would also give players an incentive not to create 'desert' maps, and avoid restricting the map generator which could have adverse effects.

*1793 for the Kennet & Avon canal, but there may be earlier examples.

If we were being really graphically swish, I suppose we could have canals build "dry" until the water tile is connected, rather than refuse to build at all, but even to me that sounds like a lot of work!

jamespetts

Thank you for the suggestion and apologies for the delay in relying: I have recently returned from holiday.

The idea is an interesting one, but a difficulty is that there is no representation of width as such in the code. Instead, there are abstract way constraints of one of two types: either permissive or prohibitive. Permissive constraints permit vehicles that have a matching constraint to travel upon them (ways without a matching constraint cannot be traversed by the vehicle). Prohibitive constraints prohibit all but vehicles with matching constraints from travelling upon them (vehicles without a matching constraint cannot traverse the way).

For waterways, we have quite a large set of constraints. Waterways generally have a single permissive "waterway" constraint, which allows boats that are not capable of travelling on the open ocean to travel on them. Waterways (be they rivers or canals) also have a series of prohibitive constraints:

(1) tub boat canal;
(2) narrowboat canal;
(3) barge canal; and
(4) ship canal.

All of the boats with the "tub boat canal" constraints are also coded with "narrowboat canal", "barge canal" and "ship canal" constraints; all of the boats with "narrowboat canal" are also coded with "barge canal" and "ship canal" constraints, and all of the boats with "barge canal" are also coded with "ship canal" constraints. This establishes in practice a hierarchy of canal/river sizes, so that smaller boats can travel on larger canals/rivers, but not vice versa.

However, this hierarchy is implemented entirely at pakset level and cannot unpicked on the fly (at least, not without some fantastically complex and probably very unreliable code, as the game would have to infer the hierarchy of ways by comparing the constraints of different vehicles). All that the code sees is a series of constraints. It would not be too hard to allow a canal to be built next to a river with an identical matching set of constraints, but the code would not know that "ship canal" ranks higher than "barge canal", and, whilst the boats have multiple constraints, the rivers/canals have only one constraint. Thus, a small canal could not be built next to a large river, which would be arbitrary and less comprehensible to players than the current system.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

AP

Hi James

I've been doing some more reading on canals recently, and realised the waterway width thing is a complete red herring. You just need to check for any adjacent water tile* when building.

Canals are basically static bodies of water, they don't flow like rivers, and are constructed to hold water well. They lose a negligable amount to evaporation.  Once built and filled (which can take as long as required), their water consumption is only really defined by whether there are any locks. Locks are installed in series, so the number of locks is irrelevant, the water loss is the same whether there is 1 lock on a canal or 100. 

The only thing that influences the volume of water loss from the locks on the canal, is how often the lock gates are opened and closed. And clearly that's not something we're ever going to calculate or simulate. 

But basically, so long as you can get some water from somewhere to the canal summit, the canal will work. The smallest spring can fill the largest ship canal, given enough time.  You just use a summit reservoir to make up the disparity in supply and demand. And ultimately have a transit limit through your locks which I suggest we ignore.

*So we should just make canal tiles check for any adjacent water tile of equal or greater altitude when building, job done. Surely that is an easy code fix?

We could introduce a non-navigable "feeder aquaduct" waytype and bridge if you wanted to encourage proper hydraulic engineering.

jamespetts

May I ask what the source for that is? I recall reading that tub boat canals were chosen in Cornwall specifically because of the difficulty in getting enough water for a larger canal to higher altitudes.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

AP

I've been reading a variety of websites and such. Much of it is simple physics. Lock gates leak slightly but lock volume is known and far greater. Evaporation from a given surface area is known.  Lock volume is lost at a rate directly related to the number of boats traversing the canal.

The important thing is that "higher altitudes" is subjective. Ultimately if you want to take a canal above the local water table, yes there will be issues.  But that is inherently a matter of understanding local geography - finding the highest suitable watercourse and going no higher. And that depends on the map in question.

See https://en.wikipedia.org/wiki/Summit-level_canal

The wikipedia article on the Canal Du Midi is interesting because it had exactly that problem. Lots of people thought it a good idea but it took ages before someone with the right knowledge was able to find a route that allowed a water source to the summit.
https://en.wikipedia.org/wiki/Canal_du_Midi#Study_of_the_project

I think giving players the same puzzle could be entertaining.

jamespetts

Thank you - I will have to study that carefully when I have time.

However, changing this system would create a serious problem: the existing tutorial video about waterways expressly states that canals need a source of water and that smaller canals can be built at higher altitudes than larger canals. Changing this would be a huge amount of work. Deleting it would involve destroying a huge amount of work already undertaken, much of which would still be useful. Retaining it would involve confusing players with outdated and misleading information.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

AP

That's a nuisance, yes. Possibly it may be worth keeping tutorials in written form only, going forward, until more playtesting has been done? 

jamespetts

The trouble is that there is no end to how much more play testing can be done (meaning that there will never be any video tutorials if one were to adopt that view), and people find the video tutorials extremely helpful.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

AP

I think allowing the tutorial videos existance to dicate or restrict the form of the game, risks following a rather regressive form of logic, which will not be to the benefit of the game's development.

If it's been decided that videos are required early -before the game is finished, tested, or balanced- then it must surely also have been accepted that those videos will have to be amended to suit any subsequent developments?

I very much doubt it was expected the game would be "perfect" first time. ;)

jamespetts

It is not so much the case that something in a video tutorial will never change come what may; but rather that the fact that it is in a tutorial greatly increases the cost of changing it, which must be weighed carefully when considering: (1) how that cost balances against the benefits of any such change (which would need to be considered with great care and in great detail); and (2) the relative priority of any such change compared with any other work that needs to be done, of which there is currently a huge queue of things that are fundamental to balance, which, in turn, is fundamental to Simutrans-Extended being a fully formed game.

The amount of work necessary even to assess whether this change is worthwhile is so great that it is a long way down the queue compared to a very long list of other important tasks.

The more people who contribute to the development of Simutrans-Extended, the faster that the queue can be processed (and the more time that I will have to make videos), so the imperative as always is increasing the number of active developers (for which my current strategy is to get the game to balance as soon as possible in order to attract more players, a fraction of whom in turn may well become developers).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

I just would like to point out that some barge canals in the demo game are above the allowed altitude. They work, but cannot be upgraded, rebuilt, etc...

zook2

It might be off-topic, but some canals were built without waterproofing and lost vast amounts of water. For example:

https://en.wikipedia.org/wiki/Aral_Sea#Irrigation_canals
"The construction of irrigation canals began on a large scale in the 1940s.[clarification needed] Many of the canals were poorly built, allowing water to leak or evaporate. From the Qaraqum Canal, the largest in Central Asia, perhaps 30 to 75% of the water went to waste.[citation needed] Today,[when?] only 12% of Uzbekistan's irrigation canal length is waterproofed. Of the 47,750 km of interfarm irrigation channels in the basin, only 28% have anti-infiltration linings. Only 77% of farm intakes have flow gauges, and of the 268,500 km of onfarm channels, only 21% have anti-infiltration linings, which retain on average 15% more water than unlined channels."

I don't know whether canals in Cornwall in the 18th century were built to a higher standard than canals in Usbekistan in the 20th.

merry

I have to say that the arbitrary canal height restriction is really quite crazy, and really doesn't fit into Extended's aim to be 'realistic'.
As it stands, it it were true, many important UK canals woudl probably not have been built, let along the others round the world built in central continental areas.
I doubt the Huddersfield narrow, nor the Leeds & Liverpool, nor the Llangllen, ot name a few in the UK, would have been possible for starters. And certainly, it makes the early game very difficult to play unless the terrain is near flat, as water is the only way to move bulk economically, or anything over long distances, at that point in the timeline.

Have to say, to assertion at one point in the discussion that that a video tutorial being rendered inaccurate by a change makes the change undesirable, it seems a whole level of daft beyond...OK, you get the idea. A case of the tail wagging the dog.
Anyway, video tutorials are really quite annoying. Sequential-access data? IN a random access world? Much as video is good eye-candy, give me a text & illustration information I can hop through & search as needed any day.

prissi

The is also the Rhine-Danube channel, which is built for large ships and goes to 406 m altitude (175 m) and 75 m down:
https://en.wikipedia.org/wiki/Rhine%E2%80%93Main%E2%80%93Danube_Canal

The Erie canal also goes up 175 m. Of course there is even the Erie-lake.

Since there is a maximum lake height parameter (at least in standard) a revision may be needed. Otherwise when building a new canal tile, one must start at a navigable river. That would also enforce a automatically sensible restriction.

jamespetts

I think that the answer to this issue is likely to lie in adding variations on the existing canal types that are concrete lined. Already, the large ship canal type has had its maximum altitude removed, as this represents a type that was concrete lined from the start.

Early canals were not concrete lined, and they had to be at or below the altitude of a water source of sufficient volume to keep them replenished as they would otherwise dry up. Later concrete lined canals did not do this.

If anyone has any data on the introduction dates of concrete lined canals, that would be helpful.

Incidentally, I am moving this to the pakset section, as this is a discussion about how to configure a pakset feature, rather than any issue with the code.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

merry

Well, that's not entirely true on two counts: Earlier large ship canals were not concrete lined (Manchester ship canal is probably an example), but certainly in the UK, most narrow canals were waterproof-lined AFAIK (generally using puddle clay, a surprisinglyy effective method). Otherwise the network woud not have been viable to build.
Large scale use of concrete in canals post-dates the majority of UK canal construction, and I'm not convinced that it even lines the biggest ship canals today except in some locations - see the Suez Canal incident last year; it's just a channel in the sand, that could be dredged & excavated without risk to the lining!

The literature I have read generally suggests that water loss (at least from UK canals) is primarily due to lock usage,  and that the amount of water required for operation of a summit level is quite limited, but still some water is required. E.g. the Canal & River Trust restricts use of lock flights down from the summit level (e.g. Bosley & Marple flights on Macclesfield/Peak Forest canals) in drier periods, or when water supply is limited e.g. due to reservoir problems (e.g. Toddbrook reservoir's near collapse in 2020 being last year's issue on the Peak Forest/Macclesfiled top level). Leakage has really only been a concern if maintenance is poor (earthworks & lock gates being the main issues), or there is damage.

All that is required for a canal to be viable is a consistent, but non-large source of water at or above the summit level. Once filled, the source has to support the lock usage, and at least in the UK this seems to be met by feeds from moor and mountain streams, certainly small watercourses have been generally sufficient - the Matlock canal was for instance  initially largely fed by water flowing out of mineworkings, until deeper workings diverted the flow and a pump station had to be built (you can imagine the commercial disputes about that as well...).
What does all this mean for Simutrans?
Well, at present the canal system is fairly useless except on flat-ish maps. You'd never build the Rochdale, Huddersfield, or Liverpool & Leeds canals on a UK simutrans map with representative altitudes. Yet these were a mainstay of transpennine trade before railways. 
So there is a real need in early maps for the canal system to allow building of routes through higher ground, provided a small source of water is avaialble to the summit level. The max-altitude system is really a horrible bodge that's way too oversimplistic for the aims of Extended, if we're to have canals as a viable inland transport system in the early inductrial revolution.
What would probably work is to require presence of a watercourse at the same or greater height & within 1-2 tiles tile of some point of the summit level - i.e. to commence building from such a point. Once a level is so suplied, all lower levels of canal are automatically watered. This suggests a flag in a canal tile set upon construction to say 'is watered directly', perhaps another to say 'is watered indirectly' (via other canal), and code to manage that when construction occurs (so if you break the water source, the canal might dewater all the way down to where it gains other water - oops!). 
And yes, this isn't perhaps a priority for coders right now. Although I suspect the actual code would be relatively straightforward, it still takes time. The only encouragement I can offer is that it would make early (pre-rail) maps in non-flat terrain a lot more playable, particularly in the early industrial revolution.

Octavius

I'm no specialist on British canals, as I'm not British, but I'm Dutch, so I'm supposed to know something about canals.

Lining a canal to prevent water from leaking away into the ground is useful when the supply of water is limited and the groundwater level is below the level of the canal. This makes it very useful on contour canals: canals following lines of constant elevation. A lot of British canals are like that. These canals run parallel to a slope and water from such canals has a tendency to leak out of the canal on one side and down the slope to some river below. For canals running directly adjacent to some river this isn't so much of an issue: water may leak out of the canal into the groundwater and then into the river, but after the next lock it can be fed back into the canal. Lining isn't really required there. Lining may also be useful for chemical reasons. A canal directly connected to the sea has somewhat brackish water, which you don't want to mix with groundwater used to irrigate farmland, and some canals double as wastewater drains.

The Suez Canal needs no lining. It has an open connection to the sea (on both ends), so there's never shortage of water. Water doesn't leak into the groundwater much, because the canal is at sea level so there's nowhere for the water to run down to. Salt getting into the environment is no issue, as it's a desert and not fit for plant life anyway. The Suez Canal runs trough two old salt lakes, more saline than the Red Sea, that used to be part of the Golf of Suez in Moses' time and for a while were very effective at blocking species living on one end of the canal from migrating to the other end, but as the canal was widened and deepened, flow increased relative to evaporation, causing the salinity to drop and now some Red Sea fish are present as invasive species in the Eastern Mediterranean.

I live about 500 metres from a somewhat large-ish canal. It's of CEMT-class Vb. CEMT classes are used for waterway sizes on the European continent. The Manchester Ship Canal would be just below class VIb, most other British canals are below class I. I don't know if the canal was lined when constructed in the 1920s (I don't think so), but when the canal was widened in the 1980s, it was lined with a sheet of textile (polymer fibre) buried just below ground. This is not because there's shortage of water, but to prevent the surrounding residential area from turning into a swamp. The canal is slightly above level ground west of the canal. To save time in locks, the canal is kept at the same level as one of the rivers it connects to and in coastal areas, the rivers are above the surrounding land. Despite this lining, when in 2007 the water level in the canal was increased a few decimetres to allow heavier ships, a park along the canal was turned into a swamp and the bikepath I often use came about one centimetre under water. This is not the flattest part of the country.

Basically, what you ask for is a proper hydrological model. A river can be used as a source of water and provide water to a canal or network of canals, provided the canal never goes up. If it does go up, you need some sort of canal that has pumps at the locks, or one needs a separate pump building that can be put near the lock. Interestingly, this requirement is similar to that of tunnel drainage. There you must always have a way down to an exit, or you need pumps, making the tunnel more expensive. This was mentioned in another thread. Pump buildings to fill high canals or drain low tunnels, maybe a way to solve both problems at once? And a lack of pump buildings that can be built below ground would limit sub-sea tunnels.

jamespetts

I should note that lined canals were introduced some time ago into the pakset.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.