[SOLVED] Forest Map implemented, but no trees will grow.

[buteo]

Hello All,

here's another newbie question:

With a view to the climate emergency, I am trying to put some forests into my test scenery (with a size of just 1 tile).

• I have created forest maps,
  (8192 x 8192 px^2, 24bit BMP (i.e. no alpha channel), green colour for forest areas, black otherwise;
• from which the landscape Editor then creates 16 BMP (2048x2048 px^2 files for patches;
  see attached example, converted to JPEG and reduced to size 256x256 px^2).
• There is one such set of 16 files (b0000.bmp etc.) for deciduous,
• and one (s0000.bmp etc.) for coniferous forests.
• The forest areas are seen correctly in the Landscape Editor as expected*).
• These 32 BMP files are then all exported to a set of 16 *.for files (256 kB each),
  which combine deciduous and coniferous areas, I think..
• I also have re-built the forest hash.

All of this looks as it should be.
But in the simulation, no trees are visible at all, neither deciduous nor coniferous.
Am I missing anything with the procedure as described above?

Thanks for any tips in which direction to investigate further.

Cheers.

*) Side issue / bonus question:
In the Landscape Editor, one has to zoom in rather close before the forest maps turn up; afterwards one can however zoom out again, and they stay visible.
No problem, but this zoom in/out procedure has apparently to be repeated individually for each single patch (e.g. 64 times for a 2x2 tiles scenery) before the complete forest map for all tile(s) can be seen.
Is this known behaviour, or am I doing something wrong?

s0103_256.jpg

[EDB]

The resolution is wrong.

[buteo]

Thanks for the reply!

The resolution is wrong.

But which resolution would be the right one?
I tried to change it to 96 dpi but that did not help. "Resolution" is always a tricky variable, as it is a "directive" to the output device rather than a property of the picture in itself (its size will always be e.g. 8192x8192 px^2, no matter what the resolution is).
E.g. I have a forest map BMP for which one graphics program reports (correctly, in my opinion) no resolution at all, whereas another program reports "2473 dpi" (see below where that value is coming from).

Perhaps I should supply some more background on what I have been trying to do.
The problem is however not with Condor, but rather with QGIS (v. 3.8 "Zanzibar"), which I perhaps do not use properly (or which may indeed have a bug).

For the ground textures, I wanted to use a raster layer coming from the web, e.g. an OSM map, or a satellite/aerial photo, loaded via the "QuickMapServices" plugin of QGIS.
These "web layers" have no "intrinsic" extent but are (in theory) unlimited, as map/photo tiles will be loaded "on the fly", according to the location at which you are looking.
But I have found no way to clip such a "web layer" to the extent of a Condor tile with the usual tools (Raster > Extraction > Clip Raster by mask layer or by extent)
The gdalwarp command in this case always returns an error "FAILURE: No target filename specified" (but which I think is specified).
I suspect this is because the GDAL command as generated by QGIS contains an URL type string (from the URL of the "web layer") which probably messes up the parsing. (I also wonder if this might be a genuine QGIS/GDAL bug or flaw in dealing with such "web layers".)

The only way I could find to (pseudo-)clip such a "web layer" to the extent of the Condor tile is via Project > Import/Export > Export Map To Image,
where the extent can then come from another layer (e.g. a mask defining the Condor tile extent).
The resulting image
a) needs to be 8192x8192 px^2 (for 1 tile in Condor), and
b) has to have a resolution so high as to result in a quality "good enough" (looking detailed enough) as ground texture in Condor.

The only way I could find to achieve this was to vary the "resolution" input of the QGIS export dialog until it results in an image size of 8192 x 8192 px^2. The exact numbers also depend on the scale at which the map is currently viewed. A typical value I had to use was 2473 dpi for a 1-tile scenery (8192x8192).

Now for the photoreal or OSM map ground textures this procedure eventually worked, and they look good in Condor.
Thus I applied the same procedure to the forest map image, using the same resolution (2473 dpi) as for the ground texture.
Apparently this does however not work, but hence the question which resolution do forest maps require?

Alternatively, is there a way after all to directly clip (in the usual way) a raster layer supplied from the web?

[OXO]

Page 32 of the manual..

2048 x 2048 pixels

[buteo]

Thanks for the pointer, but 2048x2048 is the size I actually have.
See above in the original post:

• from which the landscape Editor then creates 16 BMP (2048x2048 px^2) files for patches;
  see attached example, converted to JPEG and reduced to size 256x256 px^2).

The "converted to JPEG and reduced to size 256x256" refers only (and perhaps somewhat misleadingly) to the example BMP as attached to that post.
The original forest map BMPs are all 2048x2048x24 (i.e. RGB, no alpha), and the resulting *.for files all have a size of 256 kB which also seems correct.
I must thus be overlooking something else, but probably equally fundamental or simple...

[Andy1248]

The Landscape Editor does not create 2048x2048 bmp's. It needs a 2048x2048 sized b0000.bmp and 2048x2048 s0000.bmp images as an input.

[buteo]

That did the trick, many thanks!

I misunderstood the manual: " V2, however, increases size of the forest map tile to 2048 x 2048 pixels."
I thought this refers to the output forest maps after subdivision by the Landscape Editor, and I did not realise that while ground texture input tiles are 8192x8192, the original (before subdivision) input forest tiles, for the same area, have to be 2048x2048.

The Landscape Editor does not create 2048x2048 bmp's

Actually, it does, as reported: if you (mistakenly) feed it a 8192x8192 forest map (like I did), it will happily and without complaining subdivide it into sixteen b*.bmp and sixteen s*.bmp files, each with size 2048x2048 -- which is why I didn't see my mistake. Those BMPs can even be converted to *.for but will then not work in Condor...

But now the trees are growing. (green smile!)
Thanks again to all for the help!

[OXO]

RTFM

[buteo]

Yes I know, and in fact I did.

But this was a case of UTFM* ...
(I'm not saying if my fault or the M's...)



* not a new GIS projection grid but "Understand The Fine Manual"...