maps with different projection ?

[Molo_Parko]

^ I'm not sure what is meant by "shapes"? Projections? GProjector scales input size to desired output size. Non-rectangular projections require a much larger target size to maintain actual image dimensions... Your tst.png image as Adams world in a square 2 at 15000 pixel width --> https://www116.zippyshare.com/v/0t0u4DHG/file.html

The elevation issue is still the same as it was in my prior post isn't it? In my view there are four land tiles which inherently indicate elevation: mountain, hill, plains, grassland.

Choices:

Absolute elevation.
Tile elevation at:
0 to 1,000 ft = grassland
1,001 to 2,000 ft = plains
2,001 to 3,000 ft = hills
3,001 and up = mountains
That method would produce a Freeciv map which accurately conveys elevation globally. Mountain ranges would be mountains. Areas of moderate elevation would be hills. The Freeciv map terrain would be more rugged, less pleasant. Game-play would likely be -slower- (less food for growth in all areas of high-elevation, more irrigation obstacles, less trade, better defense against attacks.)

Relative elevation.
The only reason to do relative elevation would be to avoid using actual elevation (to have -fewer- hills and mountains and thus less unpleasant terrain resulting in faster game-play.) Split image into macro and micro areas: macro area is 3x size of micro area. If micro area is 3x3, then macro area is 9x9. Compare elevation of center micro area to surrounding micro areas. If center area elevation is more than 2,000 feet higher than surrounding areas, put a hill or mountain (>2,000=hill, >3,000=mountain) in the middle instead of land cover tile.

ggg ggg ggg
ggg ggg ggg
ggg ggg ggg

ggg ggg ggg
ggg ggg ggg
ggg ggg ggg

ggg ggg ggg
ggg ggg ggg
ggg ggg ggg

^ If center micro area > 2,000 ft higher than all surrounding micro areas then put a hill in the middle and move on to the next macro area.

ggg ggg ggg
ggg ggg ggg
ggg ggg ggg

ggg ggg ggg
ggg ghg ggg
ggg ggg ggg

ggg ggg ggg
ggg ggg ggg
ggg ggg ggg

Optionally, if the tiles surrounding the hill are grassland, consider elevating them to plains. If they are plains with a mountain in the middle, elevate them to hills.



^ Hill surrounded by plains tiles amid grassland to indicate elevation slope.

[meynaf]

^ I'm not sure what is meant by "shapes"?

Any data that can be used to build correct north and south poles, in the freeciv way. An image showing them is ok.

The elevation issue is still the same as it was in my prior post isn't it? In my view there are four land tiles which inherently indicate elevation: mountain, hill, plains, grassland.

Choices:

Absolute elevation.
Tile elevation at:
0 to 1,000 ft = grassland
1,001 to 2,000 ft = plains
2,001 to 3,000 ft = hills
3,001 and up = mountains
That method would produce a Freeciv map which accurately conveys elevation globally. Mountain ranges would be mountains. Areas of hills would have hills. Low areas would have neither, just as it actually is on Earth. The Freeciv map terrain would be more rugged, less pleasant. Game-play would likely be -slower- (less food for growth in all areas of high-elevation, more irrigation obstacles, less trade, better defense against attacks.)

And this would have the same side-effects i mentioned in a previous post, wouldn't it ?
Mountains always surrounded by hills. Hills at lower altitudes removed. Etc.

Relative elevation.
The only reason to do relative elevation would be to avoid using actual elevation (to have -fewer- hills and mountains and thus less unpleasant terrain resulting in faster game-play.) Split image into macro and micro areas: macro area is 3x size of micro area. If micro area is 3x3, then macro area is 9x9. Compare elevation of center micro area to surrounding micro areas. If center area elevation is more than 2,000 feet higher than surrounding areas, put a hill or mountain (>2,000=hill, >3,000=mountain) in the middle instead of land cover tile.

Now large mountain ranges have only their perimeter (tiles next to other types) as mountains, the mountain center is removed...

That said, relative elevation could work for hills and absolute elevation for mountains. It has to be tested.
Having a proper map showing where to expect these would help, though - regardless of how the image looks like. Else how can i check that what i'm doing is correct ?

Optionally, if the tiles surrounding the hill are grassland, consider elevating them to plains. If they are plains with a mountain in the middle, elevate them to hills.

So hills and grassland will never be on adjacent cells, and we return to the "mountains always surrounded by hills" issue.
Btw. i do not regard plains as an elevation tile type. For me a plain is just flat terrain.

[Molo_Parko]

The poles in Freeciv are necessarily wrong / warped due to the rectangular map format. The top part of the map is the north pole*, so the entire width of tiles should be ice despite that it gives the visual appearance of the north pole being equal area as the equator. Same thing at the bottom as south pole. In the Adams 2 map which I edited, I extended the arctic tiles to fill a couple of rows at both poles but left the overstated south pole shape too. I agree that it is mostly a waste of space and ought to be reduced as it is in the "Earth 190x60 v2" scenario. In which case, shape of the actual poles becomes irrelevant since they are going to fill a couple of rows of tiles at top and bottom of map?

* = There are some projections that place north pole at center of map, south pole at all 4 corners, which is interesting but within Freeciv, it makes it possible to travel south from the north pole, completely around the globe and back to the north pole without ever encountering the south pole at all! Maybe north pole at center, south pole split across top and bottom of map would work with WrapX|WrapY ?


Mountains wouldn't necessarily always be surrounded by hills -- coastal mountains next to beaches for instance. Look at the trees at the bottom right of the picture - that's flat land which in absolute rendering could become grassland or forest tiles next to mountain.

If grassland and plains are considered equal elevation then there are only 3 levels of elevation possible - mountain, hill, and all the other land tiles as a group. In which case it wouldn't matter whether grassland vs. plains are next to a hill or mountain. They'd both indicate the same thing - no elevation.

I see the elevation issue as an either/or situation. Either show absolute elevation, or don't. Either way isn't really accurate - if every mountain area is mountain tiles, then no mountain can be forested in Freeciv, for instance -- they would all be shown as barren. Using relative elevation shows fewer elevated tiles/areas than may actually exist, but offers more flexibility for the surrounding land cover. A 3x3 area that is mountainous is either all mountain, or some mountain with other land cover tiles instead of elevation. I don't see any other choices and I don't think that there is any way to make it look realistic as in Earth-like. Freeciv terrain is just too limited for accurate representation. Ideally, terrain tiles should be solely elevation, land cover should be an overlay on the terrain tile, maybe.


^ A forested mountain which is -impossible to show- on a single Freeciv tile (without custom tilesets and/or rulesets.) The tile can be either m for mountain, or f for forest, but it can't be both. It can either show elevation, or land cover, but never both.


^ Elevation map. If the Freeciv map is based solely on elevation rather than land cover, then the areas which are orange, red, brown, or grey/white, should -never- have grassland tiles at all. It's mountains, hills, high-plains, (and some lakes.) Either a tile in an area of high-elevation is shown as elevated, or it can be shown using land-cover but not both. Mixing elevation and land cover tiles is never actually correct, but can indicate things which aren't possible for a single tile - forested mountain areas for instance, as mfmfmf rather than only mmmmm or ffffff. The gray/white mountain-tops in the image may be above the tree line so those pixels should be mountain because there is no forest there (no land cover to show, just barren rock and/or snow and ice.) Mountains in the brown shaded area are likely both mountains and also forested so they could be shown as either mountain (elevation), or forest (land cover) or a mix of the two tile types. None of the three methods are entirely correct. Just pick one! Or do all three versions for 3 scenarios instead of 1 -- all using the same source image but with different interpretations. I'd play all three!

[meynaf]

The poles in Freeciv are necessarily wrong / warped due to the rectangular map format. The top part of the map is the north pole*, so the entire width of tiles should be ice despite that it gives the visual appearance of the north pole being equal area as the equator. Same thing at the bottom as south pole. In the Adams 2 map which I edited, I extended the arctic tiles to fill a couple of rows at both poles but left the overstated south pole shape too. I agree that it is mostly a waste of space and ought to be reduced as it is in the "Earth 190x60 v2" scenario. In which case, shape of the actual poles becomes irrelevant since they are going to fill a couple of rows of tiles at top and bottom of map?

My idea is to show the pole as if made with another projection. It would not extend the whole width and therefore be small enough.
Ideally there would be 70.8% cells that are ocean and currently there are not enough of these. Reducing south pole will help, and north pole being oceanic ice it will still count as ocean.

* = There are some projections that place north pole at center of map, south pole at all 4 corners, which is interesting but within Freeciv, it makes it possible to travel south from the north pole, completely around the globe and back to the north pole without ever encountering the south pole at all! Maybe north pole at center, south pole split across top and bottom of map would work with WrapX|WrapY ?

If either pole is at the center, then the other must fill the whole square around the map - otherwise there is always a direction from which you can return to the one at the center, without reaching the other.
Anyway, WrapY will always have something wrong in that aspect

Mountains wouldn't necessarily always be surrounded by hills -- coastal mountains next to beaches for instance. Look at the trees at the bottom right of the picture - that's flat land which in absolute rendering could become grassland or forest tiles next to mountain.

Apart that this particular case won't show as a mountain at all -- not high enough.

If grassland and plains are considered equal elevation then there are only 3 levels of elevation possible - mountain, hill, and all the other land tiles as a group. In which case it wouldn't matter whether grassland vs. plains are next to a hill or mountain. They'd both indicate the same thing - no elevation.

That doesn't do it. You can have a terrain at 100m altitude and a hill reaching 300m nearby, and another flat terrain at 400m without any hill.
If it is high enough, even flat it becomes a mountain. But hills don't indicate simple absolute elevation.

I see the elevation issue as an either/or situation. Either show absolute elevation, or don't. Either way isn't really accurate - if every mountain area is mountain tiles, then no mountain can be forested in Freeciv, for instance -- they would all be shown as barren. Using relative elevation shows fewer elevated tiles/areas than may actually exist, but offers more flexibility for the surrounding land cover. A 3x3 area that is mountainous is either all mountain, or some mountain with other land cover tiles instead of elevation. I don't see any other choices and I don't think that there is any way to make it look realistic as in Earth-like. Freeciv terrain is just too limited for accurate representation. Ideally, terrain tiles should be solely elevation, land cover should be an overlay on the terrain tile, maybe.

As we can't represent forest on mountain, mountain should have precedence. Otherwise it becomes easy to remove and walk by.

^ A forested mountain which is -impossible to show- on a single Freeciv tile. The tile can be either m for mountain, or f for forest, but it can't be both. It can either show elevation, or land cover, but never both.

How odd, my eyes tell me this image actually shows a hill :p

^ Elevation map. If the Freeciv map is based solely on elevation rather than land cover, then the areas which are orange, red, brown, or grey/white, should -never- have grassland tiles at all. It's mountains, hills, high-plains, (and some lakes.) Either a tile in an area of high-elevation is shown as elevated, or it can be shown using land-cover but not both. Mixing elevation and land cover tiles is never actually correct, but can indicate things which aren't possible for a single tile - forested mountain areas for instance, as mfmfmf rather than only mmmmm or ffffff. The gray/white mountain-tops in the image may be above the tree line so those pixels should be mountain because there is no forest there (no land cover to show, just barren rock and/or snow and ice.) Mountains in the brown shaded area are likely both mountains and also forested so they could be shown as either mountain (elevation), or forest (land cover) or a mix of the two tile types. None of the three methods are entirely correct. Just pick one!

Again, converting high elevation cells to forests makes them easy to remove and climb.

The elevation data i have ranges 0-255 and so i don't know actual altitude.
But i guess that starting from, say, 800m, it starts to be a mountain regardless of land cover.
Hills are not flat. They show relatively abrupt features (at that scale). They are covered by vegetation. They are higher than the surrounding terrain but not by much. This is what i'd like to test.

[Molo_Parko]

The "forested mountain" picture is from the Appalachian mountain range in Kentucky. 5,000 feet max elevation there, I think.

I get what you mean about the poles. "Normal" Freeciv world maps are sort-of an hourglass projection where the small polar area is stretched across the entire map width in a massive distortion of the poles. But limited poles create some odd situations too, for instance traveling due north from Hawaii may never encounter the north pole, just the edge of the map. Within a Freeciv game, North is always the top edge of the map, south is always the bottom edge, regardless of where the poles appear on the map.

That doesn't do it. You can have a terrain at 100m altitude and a hill reaching 300m nearby, and another flat terrain at 400m without any hill.
If it is high enough, even flat it becomes a mountain. But hills don't indicate simple absolute elevation.

If you -intend- mountain tiles to represent absolute elevation > 4,000 feet then every mountain tile indicates that elevation whether the area is actually flat or not. Same for using hills to indicate 3k to 4k elevation. That's absolute elevation as opposed to relative elevation where a mountain only indicates that it is higher than other nearby tile types. If you throw in some forest tiles in place of some mountain tiles, then it's elevation mixed with land cover. Those are the three options. ::shrugs::


Upper-left is elevation only. Upper-middle is land cover only. The others are various mixes of elevation and land cover. Which one best represents the area is a matter or preference -- THEY ARE ALL WRONG IN SOME WAY! I'd pick one of the two on the left side (which both are versions of every-other-tile landcover vs elevation, mostly.)

Again, converting high elevation cells to forests makes them easy to remove and climb.

^ So does road on mountains? I think that it takes a worker 5 turns for road on forest, 6 for road on mountain. Irrigate forest is 5, then road is 2 so 7 total that way - which is actually worse than road on mountain. How about arctic/glacier tiles mixed with high mountains?

Any data that can be used to build correct north and south poles, in the freeciv way. An image showing them is ok.

Yes, probably way too much of it!

Data files are here: https://masie_web.apps.nsidc.org/pub//DATASETS/NOAA/G02135/
^ Data is available in several formats: images, GeoTiff, shapefiles.

Free online shapefile viewer is here if desired (works with NOAA shapefile sets): https://products.aspose.app/gis/viewer/shp
^ Where that site says to "drop or upload your file" it actually wants three files from any of the shapefile sets -- dbf , shp, and sfx -- drop all three on the page and it works. Converts to various image formats.


^ Drag and drop three files from shapefile dataset to the online viewer.


^ North pole sea ice extent March, 2021 from shapefile.

Maximum sea ice extent occurs early March in the arctic, and second half of September in the Antarctic.

The elevation data i have ranges 0-255 and so i don't know actual altitude.

What is the data source?

[meynaf]

I get what you mean about the poles. "Normal" Freeciv world maps are sort-of an hourglass projection where the small polar area is stretched across the entire map width in a massive distortion of the poles. But limited poles create some odd situations too, for instance traveling due north from Hawaii may never encounter the north pole, just the edge of the map. Within a Freeciv game, North is always the top edge of the map, south is always the bottom edge, regardless of where the poles appear on the map.

It does not annoy me to hit the edge of the map, this is something that can happen anyway. Whether there is ice or not is no big deal either -- especially in modern times when ice caps melt...
Regardless of our choices, odd situations will happen. I think this one is quite acceptable. After all, one unit starting from Hawaii and another from Europe both going to north pole will not meet there either.

If you -intend- mountain tiles to represent absolute elevation > 4,000 feet then every mountain tile indicates that elevation whether the area is actually flat or not. Same for using hills to indicate 3k to 4k elevation. That's absolute elevation as opposed to relative elevation where a mountain only indicates that it is higher than other nearby tile types. If you throw in some forest tiles in place of some mountain tiles, then it's elevation mixed with land cover. Those are the three options. ::shrugs::

Mountains are special in that aspect. Altitude changes climate, which in turn changes vegetation, which in turn changes the nature of the ground. It's less soil, more rock.
Hills do not change this - not high enough.

Upper-left is elevation only. Upper-middle is land cover only. The others are various mixes of elevation and land cover. Which one best represents the area is a matter or preference -- THEY ARE ALL WRONG IN SOME WAY! I'd pick one of the two on the left side (which both are versions of every-other-tile landcover vs elevation, mostly.)

They are indeed all wrong, but none of these is what i meant
Take your leftmost one, and replace hills by forests - this what i want to achieve. Less wrong now, isn't it ?

^ So does road on mountains? I think that it takes a worker 5 turns for road on forest, 6 for road on mountain. Irrigate forest is 5, then road is 2 so 7 total that way - which is actually worse than road on mountain.

Ok, you have the point for the "climb" part. But i wrote "to remove and climb". Try removing a mountain with a worker
It is still important that mountains do not lose their defensive value. It's their only advantage.

How about arctic/glacier tiles mixed with high mountains?

Covered with ice or not, a mountain is still a mountain and isn't an arctic area.

^ North pole sea ice extent March, 2021 from shapefile.

This shows "empty" shapes. I need something that can simply be put on top of the normal map.
Like another layer, just showing polar areas.

What is the data source?

gebco_08_rev_elev_21600x10800
I don't remember where i fetched it though, but it can probably be found back among the many links of this thread.

[Molo_Parko]

one unit starting from Hawaii and another from Europe both going to north pole will not meet there either

The problem, as I see it, is that within a Freeciv map, the north pole can be located anywhere - middle of the map, for instance. At which point it is -not- the north pole anymore because in Freeciv, North is always the top edge of the map. Tile coordinates 0,0 and 100,0 are both the north pole within Freeciv regardless of where a polar image appears on the map. So if the pole doesn't extend horizontally across the entire width at the top edge, it's weird.

Hills do not change this - not high enough.

There is no standard height (absolute/elevation or relative) that defines whether a feature is a hill or mountain in the real world, but your map is your world so you set the rules!

Take your leftmost one, and replace hills by forests - this what i want to achieve. Less wrong now, isn't it ?

Language translation issue... do you mean "by" as in "next to" / "adjacent", or "by" as in "with" (replace hills -with- forest / as in convert hills to forest?) Or replace hills next to forest with some other tile... mountain?

Covered with ice or not, a mountain is still a mountain and isn't an arctic area.

That's only inherently true if using solely elevation without land cover. If using solely land cover, it's the opposite. The "a" for arctic tiles remains the same but Freeciv documentation now refers to them as "Glacier" tiles specifically because glaciers do occur outside the Arctic.

This shows "empty" shapes.

The NetCDF files at the site http://masie_web.apps.nsidc.org/pub/DATASETS/NOAA/G02186/ancillary have longitude/latitude coords per cell, at least in the 4km version.

Or cut the north pole image from the 12 MB zipped img file at the bottom of http://services.imagico.de/greenmarble.php The Arctic area was constructed with MODIS sea ice data. Resize the image (or just the top part) to 21600 width and you could read all pixels with white shades to insert at same x,y for an overlay on your image. It's the same projection as your image.


By the way, if you ever want to quickly convert a grayscale data image (elevation for instance) to Freeciv map for testing or play, try the (unix) command-line app jp2a. Example below.


^ Grayscale elevation image.


^ jp2a command-lines and output at two sizes.

jp2a sometimes takes a bit of fiddling with the substitute characters list (pixels from darkest to lightest are converted to the specified characters; the 1 in the chars list would be pure black, 0 would be pure white) on the command-line depending on how distinct the shades are, but it's easy and fast.


Regarding your bathymetric / topographical data... everything I've found so far for GEBCO 2008 and later says the tiff files should contain 2 byte signed data values per pixel, but the only copy I could find of "gebco_08_rev_elev_21600x10800" is an 8 bit (1 byte, unsigned) png at http://github.com/jasmeet0915/S.T.A.R

The GEBCO One Minute Grid is made available in NetCDF format (https://www.unidata.ucar.edu/software/netcdf/) as a one-dimensional array of 2-byte signed integer values of elevation in metres, with negative values for bathymetric depths and positive values for topographic heights.

https://www.gebco.net/data_and_products ... storic.pdf

Try this link: https://eoimages.gsfc.nasa.gov/images/i ... ey_geo.tif
The whole planet is there, but in segments A1,A2 and so on, then B1... C1... and on and on.

Newer datasets are available here too: https://www.gebco.net/data_and_products ... #accessing

[meynaf]

The problem, as I see it, is that within a Freeciv map, the north pole can be located anywhere - middle of the map, for instance. At which point it is -not- the north pole anymore because in Freeciv, North is always the top edge of the map. Tile coordinates 0,0 and 100,0 are both the north pole within Freeciv regardless of where a polar image appears on the map. So if the pole doesn't extend horizontally across the entire width at the top edge, it's weird.

It will always be weird, no matter the choices being made.

There is no standard height (absolute/elevation or relative) that defines whether a feature is a hill or mountain in the real world, but your map is your world so you set the rules!

Sure thing.

Language translation issue... do you mean "by" as in "next to" / "adjacent", or "by" as in "with" (replace hills -with- forest / as in convert hills to forest?) Or replace hills next to forest with some other tile... mountain?

Replace hills with forests. As in convert hills to forests. I just hate english

That's only inherently true if using solely elevation without land cover. If using solely land cover, it's the opposite. The "a" for arctic tiles remains the same but Freeciv documentation now refers to them as "Glacier" tiles specifically because glaciers do occur outside the Arctic.

I find "Glacier" to be misleading. Arctic ice and mountain glaciers are two distinct things.
Ok, you walk on something that's white ; but arctic is relative flat and of a much lower altitude, with more oxygen available (higher air pressure) than a mountain top. You have white bears and no yeti.

The NetCDF files at the site http://masie_web.apps.nsidc.org/pub/DATASETS/NOAA/G02186/ancillary have longitude/latitude coords per cell, at least in the 4km version.

Ok we progress. Next time, file with same projection please ?

Or cut the north pole image from the 12 MB zipped img file at the bottom of http://services.imagico.de/greenmarble.php The Arctic area was constructed with MODIS sea ice data. Resize the image (or just the top part) to 21600 width and you could read all pixels with white shades to insert at same x,y for an overlay on your image. It's the same projection as your image.

Did i say i couldn't handle the huge tiff files ?

By the way, if you ever want to quickly convert a grayscale data image (elevation for instance) to Freeciv map for testing or play, try the (unix) command-line app jp2a. Example below.

(...)
^ Grayscale elevation image.

(...)
^ jp2a command-lines and output at two sizes.

jp2a sometimes takes a bit of fiddling with the substitute characters list (pixels from darkest to lightest are converted to the specified characters; the 1 in the chars list would be pure black, 0 would be pure white) on the command-line depending on how distinct the shades are, but it's easy and fast.

I already have tools that can do that just fine.

Regarding your bathymetric / topographical data... everything I've found so far for GEBCO 2008 and later says the tiff files should contain 2 byte signed data values per pixel, but the only copy I could find of "gebco_08_rev_elev_21600x10800" is an 8 bit (1 byte, unsigned) png at http://github.com/jasmeet0915/S.T.A.R

(...)
https://www.gebco.net/data_and_products ... storic.pdf

Try this link: https://eoimages.gsfc.nasa.gov/images/i ... ey_geo.tif
The whole planet is there, but in segments A1,A2 and so on, then B1... C1... and on and on.

Newer datasets are available here too: https://www.gebco.net/data_and_products ... #accessing

No thanks. I don't need new data, especially not huge tiffs (once again).
But if i could know how this 2-byte signed integer maps to single byte unsigned integer, it would be very good.

[Molo_Parko]

It will always be weird, no matter the choices being made.

^ Not if one doesn't make world maps in Freeciv! And no WrapY. No polar issues that way.

I just hate english

English is a mess, yes. But it's fun! Anyone can make-up ridiculous words, and once others start using them, they can become "official" (appearing in some dictionary)! Sort of like Freeciv scenario worlds.

Ok we progress. Next time, file with same projection please ?

The NetCDF format isn't an image. You could convert your image pixel x,y to longitudes and latitudes, then pull the corresponding depth/elevation values from the NetCDF files, average the area that matches the Freeciv tile coordinates and set the terrain type per tile.

Did i say i couldn't handle the huge tiff files ?

The "GreenMarble" tiff is only 12 MB! Here it is as a 16 MB png : https://www.sendspace.com/file/krsh84

https://www.gebco.net/data_and_products ... #accessing

The web map service is at least a working link to the dataset. Working links seem to be in very short supply for global imaging datasets these days. I wish that they would allow querying an area by coordinate boundaries, then return an averaged value for both land cover and depth/height. If a Freeciv map is at a 1:1,000,000 tile-to-pixel ratio, it would save from having to download 999,997 more bytes than necessary for each Freeciv tile. But no averaged response is available anywhere, apparently. I'm really quite surprised that the mapping community hasn't -already- done this for scaled maps.

But if i could know how this 2-byte signed integer maps to single byte unsigned integer, it would be very good.

A signed 2 byte value uses 1 of 8 bits (from one of two bytes) to indicate negative or positive, leaving only 7 bits for the numeric value of the first byte. Two bytes per pixel increases the range of the possible data value per pixel (like 16 bit grayscale, or 8 bit grayscale with alpha channel for transparency.) Two 8 bit byte numeric values range from 0 to 65,535 (256*256=65,536.) The byte that has the sign (boolean positive/negative) only has 7 bits left for numeric value, so the value of the byte with the sign bit ranges from 0 to 127, while the value of the other byte in the 2-byte pair still ranges from 0 to 255. 128*256=32768 and the "sign bit" indicates either positive or negative, or in this case elevation or depth.

[meynaf]

^ Not if one doesn't make world maps in Freeciv! And no WrapY. No polar issues that way.

I didn't get what you mean here. There are always polar issues, the only choice is which ones you accept.

English is a mess, yes. But it's fun! Anyone can make-up ridiculous words, and once others start using them, they can become "official" (appearing in some dictionary)! Sort of like Freeciv scenario worlds.

I prefer French. We have our nice ways to play with words.

The NetCDF format isn't an image. You could convert your image pixel x,y to longitudes and latitudes, then pull the corresponding depth/elevation values from the NetCDF files, average the area that matches the Freeciv tile coordinates and set the terrain type per tile.

A lot of work, to find out it was not what i wanted ? No thanks. At least, an image shows immediate information so i know if it's suitable or not.

The "GreenMarble" tiff is only 12 MB! Here it is as a 16 MB png : https://www.sendspace.com/file/krsh84

It's just a color map image. What am i supposed to do with that ?

The web map service is at least a working link to the dataset. Working links seem to be in very short supply for global imaging datasets these days. I wish that they would allow querying an area by coordinate boundaries, then return an averaged value for both land cover and depth/height. If a Freeciv map is at a 1:1,000,000 tile-to-pixel ratio, it would save from having to download 999,997 more bytes than necessary for each Freeciv tile. But no averaged response is available anywhere, apparently. I'm really quite surprised that the mapping community hasn't -already- done this for scaled maps.

I have several 200MB data files and more, all that to produce a map file that will be half a MB at best. But who cares about that these days

A signed 2 byte value uses 1 of 8 bits (from one of two bytes) to indicate negative or positive, leaving only 7 bits for the numeric value of the first byte. Two bytes per pixel increases the range of the possible data value per pixel (like 16 bit grayscale, or 8 bit grayscale with alpha channel for transparency.) Two 8 bit byte numeric values range from 0 to 65,535 (256*256=65,536.) The byte that has the sign (boolean positive/negative) only has 7 bits left for numeric value, so the value of the byte with the sign bit ranges from 0 to 127, while the value of the other byte in the 2-byte pair still ranges from 0 to 255. 128*256=32768 and the "sign bit" indicates either positive or negative, or in this case elevation or depth.

Ahem. There is a little problem here.
I didn't want you to explain me how signed 16-bit words work ; actually 2's complement data doesn't even work this way. For your information, there isn't sign+value. Range 32768 to 65535 is actually -32768 to -1 ; 128 to 255 is -128 to -1 for single byte.

What i want is how they could possibly get that single-byte value. THAT is the question. 32000 meters is large enough ; 128 or 256 obviously not. Should we just divide that value by 256 ? Impossible. The 8-bit value is unsigned. I need to know how much one unit represents for this value.