I'm having trouble pinpointing the error. It is possible that the spreadsheet is wrong, but I have not found that to be the case for several sceneries that have been built using it. Here's how the spreadsheet works:
- Everything is based on the SRTM data. Since each pixel is 90 meters in SRTM data and there are 256 pixels per terragen tile, then each terragen tile is 256 X 90 = 23040 meters.
- When clipping scenery, the top left/top right lon. are the same, the bottom left/bottom right lon. are the same, the top left/bottom left lat. and the top right/bottom right lat. are the same. Although it appears square on a 2D map, it is not. In your case, it is further across the bottom than it is across the top -even though the latitudes are the SAME at the bottom and top of the left and right sides. This means there is some distortion in the Condor map because of the WGS 84 projection. That distortion is greater the closer you get to the poles. However, the Condor map is relatively small and it will probably not be apparent when flying the scenery. This is probably why the NASA SRTM data only extends to 60 degrees north and 56 degrees south. At the poles, each pixel could not possibly be 90 meters.
- The spreadsheet uses the information provided in the SRTM file to calculate how wide the scenery is. This is the PIXEL SIZE, which is the number of decimal degrees per pixel. I checked an SRTM tile for your soaring area in QGIS (Raster->Miscellaneous->Information) and found the pixel size to be .00083333, which I see in cell E24 in your screenshot of the spreadsheet. This means that each pixel (which is 90 meters) in the SRTM data is equivalent to .0008334 decimal degrees. The spreadsheet then multiplies 256 X .000833 = .2133, which I see in cell K16 of your spreadsheet. This is the number of decimal degrees across that each terragen tile is for your soaring area.
- To find the full width of the scenery in decimal degrees, the spreadsheet then multiplies .2133 (degrees per terragen tile) X 12 (the number of terragen tiles you entered in cell E12 of the spreadsheet) = 2.560, which is the total number of decimal degrees across that your scenery is in the X axis. You should find this in cell E30 of the spreadsheet. You can cross check this calculation by multiplying the pixel size (.000833) times the total SRTM pixels (12 terragen tiles X 256 pixels per SRTM tile = 3072 SRTM pixels). Multiply 3072 SRTM pixels X .000833 decimal degrees per pixel = 2.56 decimal degrees in width for your scenery. If the spreadsheet is miscalculating the width of the scenery, it is because the SRTM pixel size is wrong, which is unlikely.
- A further check using the 2.560 decimal degrees of the scenery is to check to see if the number of columns for the scenery can be divided by 256 evenly. 2.56 (width of your scenery in decimal degrees) / .000833 (pixel size in degrees = 3073 columns. 3073 /256 = 12 terragen tiles. That is correct.
3. I don't know the precise details of how Condor works, but it *appears* to me that Condor knows almost nothing about lat/lon. Instead, it uses a very simple matrix of pixels in the X and Y axis. In your case, the X axis is 98,304 scenery pixels (at 8192 resolution per terragen tile, which is set in cell E17) and the Y axis is 114688 pixels. When you calibrate the landscape, the file references the scenery pixel location and with the corresponding lat/lon. I believe Condor then interpolates your glider's position on the matrix using this data.
For example, if you are in the LOWER RIGHT corner of the scenery map, you are at X = 0, Y = 0 of that matrix (Condor's origin is the lower right of the map). The calibration file would read: 0, 0, 50.596, 6.691. This maps the lower right pixels of the scenery to the calculated lower right lat/lon of your terrain. The spreadsheet maps every 256 pixels across and vertically to the corner point of each terragen tile in the calibration points file. I think that Condor interpolates between these points to display the proper pixels and decide how fast you move across that pixel matrix. The lat/lon is calculated by interpolating the pixel position between calibration points.
That means that while the distortion of the WGS projection will be in the scenery, the lat/lon will be correct.
After reviewing these calculations, I still think the spreadsheet is correct. It has been used to build several sceneries, one of which was as far North as 45 degrees. This leads me to ask - are you sure that your previous scenery was correct?
You also asked a question about the tutorial process:"In 3DEM I drew a square on de SRTM files that cover roughly the scenery you want to make. After that you have to transform to UTM WGS84.
Is this automatically done when you import the clipped SRTM file in to 3DEM as in 2.3B in your tutorial?"
Yes, this has already been done if you followed the tutorial.
If you still have the files from drawing that square, take a look in the .hdr file. You will see the rows and columns figure. Do the following:
1. Divide the number of rows by 256. You should get an even number that is the number of terragen tiles.
2. Multiply the number of columns X .0008333 (pixel size for an SRTM tile) to find the number of decimal degrees across for your scenery. Divide that number by the number of terragen tiles you found in 1, above, and you should get .2133 decimal degrees - the distance across of each terragen tile.
If those are right, the spreadsheet is right.