^ Do you mean that the last scenario played lasted four years? That's a long game.
Or that the last time a scenario was used instead of a generated map was four years ago?
I'm working on rivers again / still, although "working" may not be the best term. "Grasping blindly in the darkness of indecision amid too many issues" may be more accurate. River problems are the worst issue I've encountered so far, because there aren't any great solutions -- at least not at 512x256 map size.
River problems are occurring for several reasons:
1] Scale. Two rivers running nearly side-by-side on full-sized Earth may remain distinct. The same two rivers in a Freeciv map at 512x256 tiles, become cross-connected at nearly every tile. It looks likes a mess despite that it's accurately plotted.
2] Rivers have a different system of connection within Freeciv than any other tile or extra. Roads and rail can connect diagonally. Rivers cannot. It ensures that any river which is not a perfectly straight line at the Freeciv map scale, will look "wrong".
3] Real-world rivers twist and turn, creating lots of
curves. Twisting and turning rivers in Freeciv create
angles rather than curves, and each angle depicted adds tiles because the connections must be stair-stepped. (At least on regular square tiles in standard Freeciv.)
4] Resizing a raster image of rivers and converting the image to a Freeciv rivers layer map (without manually cleaning-up the image) makes far more messes due to "
fuzzification" of the image during resize because interpolation and anti-aliasing introduce extra pixels into the image and which make the rivers even less accurate and more messy.
5] Plotting the rivers by longitude and latitude converted to Freeciv x,y coordinates works without resizing any raster image so no extra pixels are included due to resizing, but every diagonal river connection
requires at least one extra tile to be added to connect the river segments. I still prefer using longitude and latitude to plot rivers rather than using image files which are fuzzy unless manually cleaned. Tiles added for diagonal connections are added
intentionally rather than by seemingly random interpolation during resizing.
To convert longitude and latitude to Freeciv map x,y coordinates, I use the following method (assuming that East-West or positive-negative values are from the most common longitude / latitude system in use -- although there are other systems.) I'm using bash shell which doesn't do floating-point math, ergo removing the period from the longitude/latitude (same thing as multiplying the number by one trillion to convert the decimal value to a whole number for bash math.)
First determine the range of degrees represented by each Freeciv tile at the map dimensions.
echo "scale=12 ; 360/512" | bc
=================
.703125000000 <-- each Freeciv tile at 512x256 map size represents this fraction of a degree of longitude and latitude. It's the same value for latitude because the map is at 2:1 ratio, 512 width x 256 height.
Negative lon: Strip the negative sign, strip leading zeros, ensure 12 digits after period (add trailing zeros if needed), remove the period
So longitude -51.595639762723 becomes...
lon=51595639762723
echo $(( (180000000000000 - ${lon}) / 703125000001))
=====
182 is the Freeciv x value of the tile. 180 (180000000000000) is half the range of longitude (total 360). Since the original value was negative, it refers to the left side of the Freeciv map (tiles 0 to 255 in a 512 width map) and doesn't require adding a value to shift it to the right side of the map. Instead, subtracting from 180000000000000 flips the value since longitude begins from 0 at the middle of the map, while Freeciv has zero at the left edge of the map. The subtraction transforms 0 longitude to y value 255 (either way, it is still the center of the map.) It's the same for East / West values, just remove the E or W before converting the value and treat West longitude as negative.
Positive lon: Strip leading zeros, ensure 12 digits after period, remove the period
lon=51595639762723
echo $(( (180000000000000 + ${lon}) / 703125000001 ))
====
329 is the x value of the tile. Positive longitudes should have 180 degrees added to shift them to the right (East) side of the map (x=256 to 512.)
Negative lat: Strip the negative, strip leading zeros, ensure 12 digits after period, remove the period
lat=69053200755493
echo $(( (90000000000000 + ${lat}) / 703125000001 ))
===
226 is the y value of the tile. Negative latitude values should have 90 degrees added to shift them to the lower half of the Freeciv map.
Positive lat: Strip leading zeros, ensure 12 digits after period, remove the period
lat=69053200755493
echo $(( (90000000000000 - ${lat}) / 703125000001 ))
====
29 is the y value of the tile. Positive lat values are already in the upper half of the Freeciv map so they don't require an added value to shift them.
Using that method makes it easy to convert a list of longitude / latitude values to Freeciv x,y tile coordinates. Which is how I plot river tiles on the e03_ map layer (previously the "n" layer in older Freeciv versions.)
^ A small example. That river was plotted to the Freeciv map via longitude and latitude conversion. The black squares in the lower part of the image each represent one Freeciv tile on the river map. The yellow line is the actual course of the river overlaid on the black tile squares. The river x,y coordinates are for 4 tiles. In Freeciv, a fifth tile must be added because rivers don't actually connect diagonally. So the original river is slightly curved downward in the middle, but in Freeciv it appears to have a stub on the lower side because if the tile above the stub were removed the river would not be contiguous. If the map were twice the scale (1024x512 tiles) or more, the Freeciv river would look a bit more like the curve of the yellow line.
The only thing that I can think of that might make it look better, would also require shifting river tiles around to the extent that they are no longer where they actually belong by longitude and latitude.
For example:
Code: Select all
####
#
Could be replotted as:
# ##
###
^ Which may
look more like the original curve of the river, but parts of it would then be in the wrong place!
Here's another example:
^ The black squares represent Freeciv river tiles. The yellow line is the actual river course. There just isn't enough room between the rivers at 512x256 scale in Freeciv, and the actual curved course of the rivers isn't possible in Freeciv because connections between river tiles are one of: up, down, left, right. No curves or diagonals are possible.
By the way, plot all lakes first, then plot rivers. Some rivers plot as segments because of lakes within the river's course. If the lakes are already plotted then the river segments make sense and are connected by the lakes. If the lakes aren't plotted, many rivers have gaps between segments and it looks all wrong. Plotting lakes afterward would fix that too, but having them first prevents needing to create more stair-step connections for diagonals that won't matter once the lakes are plotted.
And speaking of lakes... There are odd little things about datasets. For instance, the original source image I used was "GEBCO Latest 2". It shows Lake Baikal in Russia as bathymetric depth colors indicating shallows.
^ Here are the actual tiles/pixels (the darkest color) as Freeciv's terrain map "shallow ocean" character (space).
^ Here they are again after adding the GProjector lakes overlay. Only two pixels were changed, one from "shallow ocean" to lake, the other from grassland to lake. The lake quite clearly has more area than 2 pixels, yet the lakes overlay doesn't know they are part of the lake.
^ Here it is again after adding the NaturalEarth.com lakes from their rivers and lakes dataset at 50m quality (not the whole lakes dataset which I didn't like as much -- and which also has this same deficiency regarding Lake Baikal.) One more tile was changed from "shallow ocean" to lake, and again there are other tiles which are part of the lake that aren't in either of the two lake datasets! WEIRD!
EDIT 3:
I forgot that I had disabled plotting lake on ocean tiles. After changing that to allow it, the NaturalEarth.com lakes dataset (not rivers and lakes but just lakes) correctly plotted Lake Baikal. But, it wrecked The Great Lakes, and Lake Victoria by increasing the area of the lakes to the point that they are unrecognizable except for location.
^ That's the satellite image view from Apple Maps. How in the world can two lake datasets not include this entire lake? Especially strange that the Natural Earth lakes from their rivers set seem to indicate that the nearby river is more prominent than the lake itself!
Has anybody seen a lake dataset that actually depicts Lake Baikal in its entirety???
EDIT: It looks like the "Dominant Land Cover" set does have Lake Baikal as "water bodies" (not ocean) and I had assumed that it wouldn't add or change lakes to the map so I ignored that category. I'll try it again tomorrow with plotting lake tiles as well and see how it works out.
EDIT 2: Nevermind. The DLC set has polar areas as value 0 to indicate that they aren't included in the land cover set. Waterbodies are value 11 and there is no distinction between ocean (deep or shallow) and lake. So reapplying it doesn't help - it does include Lake Baikal -- but not specifically as lake vs. ocean.
