GUI based Photorealistic Condor Scenery Tutorial - draft

Everything related to creation of new sceneries for Condor...

Moderators: Uros, OXO

Post Reply
tberry
Posts: 91
Joined: Thu Aug 09, 2012 4:10 pm

Re: GUI based Photorealistic Condor Scenery Tutorial - draft

Post by tberry » Fri Jan 29, 2016 3:33 am

I did explore it. I tried importing some doqq's but it didn't seem to handle large mosaics without choking. It was then that I reread your post about using vrts and that's what unlocked it for me. I was able to use gdal-retile to automate cutting.

The process of downloading is automated using the usgs bulk downloaded from so it's not as onerous as it sounds.

There's more than one way to get scenery into the right format. It's nice to have options. I think I'm close to figuring out the Landsat input. It actually looks simpler than naip.

mtecles
Posts: 13
Joined: Sun Jan 17, 2016 9:53 pm

Re: GUI based Photorealistic Condor Scenery Tutorial - draft

Post by mtecles » Mon Feb 01, 2016 3:18 pm

Hi, Tom. Some more feedback.

On the spreadsheet (.96), Tile Cutting, it is missing a space at E22 (Reproject Mosaic):
"gdalwarp...-multi-of VRT...", it should be
"gdalwarp...-multi -of VRT..."

At the tutorial from page I can read: "For use with Condor Scenery Spreadsheet .95".

At 1.2.D: 4 or 5 files into zip? (although it seems harmless, I have uploaded to Erth Explorer with 4 [dbf,prj,shp,shx] and 5 files[dbf,prj,shp,shx,qpj] without problem):
"To use these files...a .zip file containing all five ...installed, select the four files,...Macintosh, select all five files,.."
At least for Windows, one must close Qgis to zip the files, for they are in use by Qgis.

I am following the tutorial but with some differences that I don´t know if they will result in something usable.

First, to build mosaic I have Landsat 7 TIFF images, so:
gdalbuildvrt "C:\IpuaTB\VRT\InitialVRT.vrt" C:\IpuaTB\SourceImages\*.tif

Second, from the InitialVRT.vrt information:
Coordinate System is:
PROJCS["WGS 84 / UTM zone 23N",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4326"]]

I am lost here, I don´t know what EPSG to use!
So, in QGIS Raster->Projections->Warp (Reproject) I went through the "Source SRS" list and find out:
Universal Transversal Mercator (UTM)
WGS 84 / UTM zone 23N = EPSG:32623

Then in "Reproject Mosaic" I used (I am not shure what I am doing!):
gdalwarp -overwrite -s_srs EPSG:32623 -t_srs EPSG:4326 -r cubicspline -wm 520 -multi -of VRT "C:\IpuaTB\VRT\InitialVRT.vrt" "C:\IpuaTB\VRT\Reproj.vrt"

Finally, to cut to exact size:
gdal_translate -projwin -45.96776667 -22.36453333 -45.11443333 -23.21786667 -of VRT "C:\IpuaTB\VRT\Reproj.vrt" "C:\IpuaTB\VRT\Clipped.vrt"

I stoped at this point. Just for the record, I have the ghosty scenery (the easy part) that works and where I can fly in Condor.

Thank you,
Mauricio

tberry
Posts: 91
Joined: Thu Aug 09, 2012 4:10 pm

Re: GUI based Photorealistic Condor Scenery Tutorial - draft

Post by tberry » Mon Feb 01, 2016 10:34 pm

Thanks for the edits, Mauricio. I've changed them in the manual and spreadsheet.

Your steps look good and are similiar to the ones I've been experimenting with to get landsat images into QGIS and eventually LE.

Go ahead and try to resize and then cut the tiles and see what happens.

We may have to do some pan sharpening and assigning of bands to red/green/blue but see what you get when you output your run.

User avatar
Jan Oorthuijsen
Posts: 491
Joined: Sat Jul 02, 2005 4:27 pm
Location: Utrecht (Terwijde) - Holland

Re: GUI based Photorealistic Condor Scenery Tutorial - draft

Post by Jan Oorthuijsen » Mon Feb 15, 2016 7:09 pm

Hi.

I try to remake one of my hobby scenery’s 11 x 14

I need some help. If I try to make the scenery 12 x 14 tiles. It looks like the width is wrong.
New center is 5.4113 – 52.0897

Calculated clipping details are;

X 4.13119760 6.69140240
Y 53.58315280 50.59624720

If I am correct it must be X 3.3935 7.4457

In Qgis de grid is not weight enough on the SRTM file’s
What am I doing wrong?

Thanks, Jan
You do not have the required permissions to view the files attached to this post.
Last edited by Jan Oorthuijsen on Mon Feb 15, 2016 10:39 pm, edited 2 times in total.
PH-722
WW
It’s Difficult to Soar Like An Eagle
When You’re surrounded By Turkeys

tberry
Posts: 91
Joined: Thu Aug 09, 2012 4:10 pm

Re: GUI based Photorealistic Condor Scenery Tutorial - draft

Post by tberry » Mon Feb 15, 2016 7:41 pm

It looks right to me. You are speaking about the width, correct (not the weight, but the width)?

Each terragen tile is .2133 degrees across. 12 tiles X .2133 = 2.5596 degrees is the width of your scenery.

4.1331 + 2.5596 = 6.691 <-Matches the calculated clipping details (4.1331, 6.691)

Your calculation is 19 tiles wide: 7.4457-3.3935 = 4.0522 degrees. 4.0522 / .2133 = 19 terragen tiles across.

User avatar
Jan Oorthuijsen
Posts: 491
Joined: Sat Jul 02, 2005 4:27 pm
Location: Utrecht (Terwijde) - Holland

Re: GUI based Photorealistic Condor Scenery Tutorial - draft

Post by Jan Oorthuijsen » Mon Feb 15, 2016 10:27 pm

Sorry for bad language I am an old Dutchman :oops:

This screenshot explain what the problem is.

Grtz, Jan
You do not have the required permissions to view the files attached to this post.
PH-722
WW
It’s Difficult to Soar Like An Eagle
When You’re surrounded By Turkeys

tberry
Posts: 91
Joined: Thu Aug 09, 2012 4:10 pm

Re: GUI based Photorealistic Condor Scenery Tutorial - draft

Post by tberry » Mon Feb 15, 2016 10:48 pm

I input the coordinates you have in your spreadsheet into a new spreadsheet and they match properly. The calculations are correct.

I notice that your scenery starts at 3.3813. It should start at 4.1311, according to the spreadsheet. Is this the edge of the SRTM data? If so, you probably haven't cut the SRTM file to match the soaring scenery as outlined in step 2.2.G. What version of the tutorial are you using?

User avatar
Jan Oorthuijsen
Posts: 491
Joined: Sat Jul 02, 2005 4:27 pm
Location: Utrecht (Terwijde) - Holland

Re: GUI based Photorealistic Condor Scenery Tutorial - draft

Post by Jan Oorthuijsen » Tue Feb 16, 2016 4:23 pm

Hi Tom

I use the tutorial January 2016.

My old scenery 11 Terrage tiles wide covers E3.3813 up to E6.9623
SceneryCenter is N52.0930 – E5.2433

The new scenery is 12 Terragen tiles wide and covers according to the spreadsheet calculations E4.1311976 up to E6.69140240. The latitude distance is correct

As you can see in my previous reply, the distance between two longtitude calibrationpoints of my old scenery is about 0.326 degrees.

Does it have something to do with the latitude? One Terragen tile is 23040 meters and depending on the latitude it covers more or less longtitude degrees per tile.

I am new to Qgis and your tutorial is an opportunity to learn how to use it.
In right lower corner the setting says EPSG:4326. If I am correct that changes the projection to UTM WGS 84, so you don’t see that in de GUI like it happens in 3DEM, am I correct?

I hope I don’t look stupid, I am retired and enjoy to learn this stuff. Am I welcome to ask more questions?

I am using translation app Dutch/English so sometimes I may use a word that make no sense to you.

Grtz Jan
Last edited by Jan Oorthuijsen on Thu Feb 18, 2016 3:53 pm, edited 1 time in total.
PH-722
WW
It’s Difficult to Soar Like An Eagle
When You’re surrounded By Turkeys

tberry
Posts: 91
Joined: Thu Aug 09, 2012 4:10 pm

Re: GUI based Photorealistic Condor Scenery Tutorial - draft

Post by tberry » Tue Feb 16, 2016 10:20 pm

Yes, it is possible that the pixel size is off. What was the pixel size of the SRTM terrain when you checked it in QGIS? If it is significantly different from .0008334 then the number of decimal degrees would be different.

I've worked with latitudes in the 70's and 40's. I know that the further north you get, the greater the distortion of the WGS 84 projection - at least the latitudes. The longitudes remain the same.

My spreadsheet assumes both are the same - not a very good assumption further north.

User avatar
Jan Oorthuijsen
Posts: 491
Joined: Sat Jul 02, 2005 4:27 pm
Location: Utrecht (Terwijde) - Holland

Re: GUI based Photorealistic Condor Scenery Tutorial - draft

Post by Jan Oorthuijsen » Wed Feb 17, 2016 1:51 pm

Pixelsize SRTM is correct.

Made a measurement in google from centerpoint to east and west direction.
You do not have the required permissions to view the files attached to this post.
PH-722
WW
It’s Difficult to Soar Like An Eagle
When You’re surrounded By Turkeys

tberry
Posts: 91
Joined: Thu Aug 09, 2012 4:10 pm

Re: GUI based Photorealistic Condor Scenery Tutorial - draft

Post by tberry » Wed Feb 17, 2016 3:50 pm

Is this the soaring area you want to cover? If so, the spreadsheet is correct.

However, it looks to me like it does not go far enough west past The Hague, which means it is incorrect -probably because of assumptions in the sheet about decimal degrees.

If true, then I need to do some work on the spreadsheet to fix the problem in the X-axis longitude. I suspect I know where the issue is, though may need some time to work it out.
temp.jpg
You do not have the required permissions to view the files attached to this post.

User avatar
Jan Oorthuijsen
Posts: 491
Joined: Sat Jul 02, 2005 4:27 pm
Location: Utrecht (Terwijde) - Holland

Re: GUI based Photorealistic Condor Scenery Tutorial - draft

Post by Jan Oorthuijsen » Thu Feb 18, 2016 3:35 pm

HI Tom.

No that is not the soaring area. In my screenshot I used the scenery corners of my old scenery (11 x 14 terragen tiles).The new one will be 12 x 14.
Your projection is too small for 12 terragen tiles in x direction. It is obvious that de X direction calculation is off.
Another question, in the spreadsheetcalculations the longtitude values of the Upper left and the Lower left are equal and the same for the Upper/lower right, is that correct? The same happens in the Calibrationponts calculation, 15 times the same value repeated.

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?

Grtz. Jan
You do not have the required permissions to view the files attached to this post.
PH-722
WW
It’s Difficult to Soar Like An Eagle
When You’re surrounded By Turkeys

tberry
Posts: 91
Joined: Thu Aug 09, 2012 4:10 pm

Re: GUI based Photorealistic Condor Scenery Tutorial - draft

Post by tberry » Thu Feb 18, 2016 6:06 pm

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:
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

User avatar
Jan Oorthuijsen
Posts: 491
Joined: Sat Jul 02, 2005 4:27 pm
Location: Utrecht (Terwijde) - Holland

Re: GUI based Photorealistic Condor Scenery Tutorial - draft

Post by Jan Oorthuijsen » Fri Feb 19, 2016 2:56 pm

Hi Tom

The calculations are right if you use the value 0.2133. If i am correct this is a valeu only for one specific latitude.

I have done som research. The latitude center of my scenery is about 52N
One longtitude degree according to a list 68420 meter.
One Terragen tile covers then 23040 : 68420 = 0.3367
That is about the value of my scenery in de screenshot above.
The problem is that the latitudes values will be wrong if you use it in your spreadsheet.
After that, there will be still a problem of thousands of meters between top and bottom of the scenery.

HDR File

file_title = ...........
data_format = int16
map_projection = UTM Zone 31N
ellipsoid = WGS84
left_map_x = 526950
lower_map_y = 5612490
right_map_x = 780300
upper_map_y = 5934960
number_of_rows = 3584 : 256 = 14
number_of_columns = 2816 : 256 = 11
elev_m_unit = meters
elev_m_minimum = -218
elev_m_maximum = 610
elev_m_missing_flag = -9999

Grtz Jan
PH-722
WW
It’s Difficult to Soar Like An Eagle
When You’re surrounded By Turkeys

tberry
Posts: 91
Joined: Thu Aug 09, 2012 4:10 pm

Re: GUI based Photorealistic Condor Scenery Tutorial - draft

Post by tberry » Fri Feb 19, 2016 5:07 pm

Yes, I think we both understand the problem. Using the pixel size of .000834 only works for certain locations. Using your value of .3367 degrees per terragen tile, I find a pixel size of .00131. When I substitute that in cell E24, I get .3353 degrees per terragen tile, almost the same as your .3367. Certainly close enough.

The real question is what happens if you use that value? I'm trying to think it through.

The SRTM terrain metadata says the pixel size is .000834 decimal degrees X 256 = .2133 degrees per terragen tile.
But your latitude is actually .00131 X 256 = .3367 decimal degrees per terragen tile

If you change the pixel size in cell E24 to .00131, then the lat/lon calculations for the corners will be correct. Since the SRTM data is cut by lat/lon corner points, it *should* match the scenery correctly, though there will be distortion. But, I don't think that distortion will be significant. The SRTM specification says that each pixel is 30 meters. But, that can't be true as you move closer to the poles. It must get smaller and smaller, perhaps to 20 meters or so. The main concern would be if it got VERY small, near the poles. (But this is probably the reason the data is cut off near the poles.)

I don't think that matters, in your latitude, however. Since each data point is encoded with lat/lon, when you cut it to the appropriate size, it will still match closely to the proper location.

That means the aerial images that are mapped to the terragen tiles have been slightly distorted due to the use of .000834 in the sceneries I've built so far. It would explain how some of the airports I've placed are off by perhaps a few hundred meters from their gps locations. Since the sceneries we've built are further south, it hasn't been a noticeable difference.

I suppose I need to make an adjustment for the UTM zone in the spreadsheet so I can get the terragen tiles the proper size.

If you adjust the pixel size in cell E24 to .00131, the tiles should come out the proper size. Please let me know if they do. The other calculations should also be correct, since nearly everything is based on the pixel size in the spreadsheet.

Thanks for alerting me to this error!

Edit: I've found a simple way to calculate the pixel size. I'll probably look for more a more accurate way, but this gets you quite close:
23040 / (111,111.1 * cos(PI*Latitude/180)) for the horizontal axis.
23040/111,111 for vertical axis

The value 111,111.1 meters corresponds to the number of meters in a degree of latitude.

Post Reply