Terrain height at GPS coordinate

[Guest jprintz]

Hi all. I was wondering how I'd go about extracting the terrain height at a GPS coordinate I specify. From a search of the forums, I know that as of FS2002 there was no way to do this, but I also know that people have done terrain following radars since then, and I don't see how that could be done without somehow knowing the outlay of the terrain in front of you. What is the secret here? (This is for my Hornet Heads Up Display. I've fixed things and added some very cool features - energy caret, HUD steering (an HSI-like display tacked onto the velocity vector), etc... and I'm also adding a "Mark" feature that lets you put your plane's current coordinates into a GPS waypoint, and I then display a "target" diamond in the HUD at that point. It's no problem getting and storing the terrain altitude just underneath your plane, but I'd like to expand it to include waypoints not marked in this way. Possible? Any help appreciated!

[pve 0]

Hi You can use from the GPS Fs9gps_WaypointNdbElevation/WaypointVorElevation/WaypointAirportElevation with NearestVor,Ndb,Intersection,Airport etc.

[mgh 89]

According to the SDK there is no height associated with a waypoint so it isn't possible to extract what's not there. Waypoints can be associated with an airport so you could take the airport height as a proxy. But, again according to the SDK, there is no link from the waypoint to the airport, so you'd have to search all airports for any associated waypoints.I suspect that you're going to have to find some general way to extract the height at given coordinates. A terrain specialist might be able to help - I can't:(

[Guest Ron Freimuth]

>According to the SDK there is no height associated with a>waypoint so it isn't possible to extract what's not there. Actually, there is. However, it probably isn't available as a variable. The GPS, and a GPS A:Var give the Vertical Speed to next WP. So, FS9 knows a height for each WP. I assume winds aloft are taken into account in the 'Time to WP', thus GS, not TAS applies. Knowing distance, GS, and required VS, it's easy to figure the height of the next WP. However, I found the climb rate was constant, so that VS to WP was too low as I first climbed out, too high as I neared the first WP at FL 290 (90 nm from TO). That was with a FP generated by the 'find path' menu. I should have manually added a WP closer to the departure airport. The mid WP's will be at the ASL (not Flight Level!) one selects for the FP. If one generates a "GPS Direct" FP, all the vertical speeds will be negative. Assuming the destination airport is no higher than the airport one took off from. When I set up an approach procedure with the FS9 GPS, it selects fixed points, etc. near the airport. For the kind of approach and runway I select. Those points appear to be at appropriate altitudes relative to the airport and I've used them when landing my Concorde to see VS required. Ron

[Guest Ron Freimuth]

>Hi all. I was wondering how I'd go about extracting the>terrain height at a GPS coordinate I specify. From a search of>the forums, I know that as of FS2002 there was no way to do>this, but I also know that people have done terrain following>radars since then, and I don't see how that could be done>without somehow knowing the outlay of the terrain in front of>you. What is the secret here? Other than for WP's, there is no known way to find the Ground Elevation of the terrain other than directly below the AC. Certainly it must be somewhere in the terrain data. Knowing just the current height AGL won't keep one from crashing into a mountain side ahead of you. However, if the terrain doesn't have excessively high slopes, one can estimate the AC trajectory to fly to stay near the same AGL height by differentiating the current 'Height Above Ground' once or twice and using those derivatives as part of a VS command. When one doesn't know what's ahead setting VS proportional to the slope of the ground under the AC is the best one can do. This has to do with 'Taylor Series', etc. Which take all the derivatives at one point in a function to give the values for all the other points. It only works for 'smooth functions'. However, the lethargic FS autopilot won't follow VS commands very well. Further, most all FS jets are way overdamped, so they are also slow to respond to control inputs, and/or respond unrealistically. I know custom 'PID' controllers done in XML will do much better. And, your message reminded me of something I can play with: Control AGL, 'Terrain Following'. >(This is for my Hornet Heads Up Display. I've fixed things and>added some very cool features - energy caret, .. Neat. If you want 'energy height', it's easy to calculate also. I display kinetic and potential energy normalized to AC mass in my Test gauge, also 'Energy Height'. Mainly useful for fighters (I suppose also for gliders). Ron

[mgh 89]

Neither the XML or BGL files associate a height with a waypoint.I agree that there is a GPS WP VERTICAL SPEED variable. There are also GPS WP NEXT ALT and GPS WP PREV ALT. However there is also a GPS WP PREV VALID which means "Is previous waypoint valid (i.e. current waypoint is not the first waypoint)".This suggests to me that these variables only be valid if the waypoints are part of a GPS route, maybe a flight plan?. In that case, I'd have expected the ALTs to be those relating to the route, not to ground level. The approach legs in Flight Simulator generally model the ARINC standards and have appropriate altitudes associated with them.

[Guest JeanLuc_]

Hi Ron,"Other than for WP's, there is no known way to find the Ground Elevation of the terrain other than directly below the AC. Certainly it must be somewhere in the terrain data."Actually there is one way I know of:http://www.reality-xp.com/products/ST3400/index.htmHope this helps!

[Varmint007 2]

I'm famillair with what you're trying to do, since I have that feature in my Hornet.You can get the waypoint "altitude" with A:GPS WP NEXT ALT, but that won't tell you the ASL value at that point, only the height of the waypoint AGL.To place a pointer on the ground use lambda for the vertical component.asin((elev2 - elev1) / distance) and scale to your HUD FOV.It won't always show the correct height because of the altitude problem, but you can correct it based on the the "RADIO HEIGHT", or radar altitude as you get closer. Start with barometric altitude assumed to be 0 at the waypoint and slowly average that down with radar altitude as the waypoint approaches. By the time you're on top of the waypoint you should be using pure AGL as the reference points for elev1/elev2 above.The horizontal component is obviously just the heading difference.Rotate the entire thing by bank angle (easiest), OR integrate bank angle into the horizontal and vertical components so that you can limit the ground pointer to the HUD FOV. If you use a element you'll have no control over the HUD limits as rotation will move the pointer beyond the limits regardless of any min/max placed on . I hope I'm making sense:)To integrate bank into X,Y (XML, radians):X:X BANK cos * Y BANK sin * - rddg somevalue MIN somevalue MAXY:X BANK sin * Y BANK cos * + rddg somevalue MIN somevalue MAXNow you can apply X/Y limits to the so that your ground pointer can be "HUD limited" and not have to worry about exceeding them.--Jon

[mgh 89]

Is the waypoint "altitude" above ground level? The SDK doesn't make it clear, at least not to me. Also I was taught that altitude defined as measured above mean sea level but that height is measured above ground level. This suggests that GPS WP NEXT ALT is measured from sea level not from ground level.

[Varmint007 2]

No, you're right, the WP alt is ASL not AGL, but in terms of placing a pointer over the ground at the waypoint, you'd ideally want AGL, which isn't available. What I was saying was AGL as measured by Radio Height can be used as the waypoint is approached to eliminate any errors in pressure differential.--Jon

[Guest Ron Freimuth]

>No, you're right, the WP alt is ASL not AGL, but in terms of>placing a pointer over the ground at the waypoint, you'd>ideally want AGL, which isn't available. What I was saying was>AGL as measured by Radio Height can be used as the waypoint is>approached to eliminate any errors in pressure differential.>--Jon Looks like "(A:Plane Alt Above Ground,ft)" is just a synonym for "(A:Radio Height,ft)". The former is more direct. Both showed 10 feet sitting on the runway. Which, I assume is the 'CoG' reference of the flight model. The LG struts were set to 9.8 ft in that AC. One might want to account for the lowest scrape point of an AC and subtract that from the above height. Especially during landing. I think AFSD does. I think "(A:Plane Altitude,ft)" is ASL. Then, there is "(A:Indicated Altitude,ft)", which is what the Altimeter reads. There is another A:Var for Ground Altitude. Of course, it only shows the altitude right under the AC. I experimented with a "PID" controller which controls AC rate of climb. 250 kts below FL 10 (10000 ft PA) increasing above. I also changed to AGL as I approached the ground, the idea being to drop CAS during an approach. However, that isn't good if the terrain is hilly. I'll see how well I can control AC height above ground, rather than IAS, using ideas I've exerimented with. That Reality-xp gauge looks nice, but only gives visual commands to the pilot. Apparently they found some way to get terrain heigth over the area near the AC. It also looks to the sides. Ron

[Guest jprintz]

Howdy all, and thanks for the responses. I was kinda expecting that it wouldn't be as easy as it should be. (If the right variables were available, I mean). I suppose I'm content to just let it work as it does. The difference is small enough over most "near sea level" terrain that it's probably not worth worrying about too much. It would ne nice if Microsoft gave us a way to do this in the next version. (Along with moving carriers! ;-) Jon: thank you for the advice. Where were you last week though!?! ;-)Heheh, nah, actually, I arrived at the same conclusions after plenty of tinkering and messing around myself. I actually find a lot of great circle and trig stuff not as bad as some of the other things that SHOULD be simple.... I think you were the one who e-mailed me awhile back about having HUD steering tacked onto the vector?? I did get that working, and it's a great feature! See the screen, attached, of a "manual" approach to the carrier, me rolling onto final. It's nice. You just set one of the NAV OBS's to the carrier BRC, and bingo, a great horizontal reference right there - you know EXACTLY when you're crossing the stern, at the abeam position, etc.... True "Heads Up" flight, with no need for an HSI oncreen even. My point is, it SHOULD have been easy, but it took 3 shifts and 2 rotates on the same to make it behave! XML just does not always work like I think it logically should.... ;-)

[Varmint007 2]

Hey that looks great, and very familliar:)I see something that doesn't look quite right in your steering arrow, though. Each "dot" should respresent 4 degrees of courseline error, so when you're perfectly on course, the arrow should be aligned with the velocity vector. If you were 8 degrees right of course (full deflection), the arrow would be aligned with the second dot and both dots would be on the left of the velocity vector. Also, the dots completely go away when the error is less than +-1.25 degrees.In your pic, it looks like the arrow is aligned with the 4 degree error dot, and it should be almost directly over the velocity vector (with no dots visible) since it looks like you're lined up correctly.--Jon

[Guest phlerp]

It seems like you have some knowledge of the symbology of the F-18 HUD. I'd like to get intouch with you. I'm making the program for the real HUD of this (http://www.novelair.com/forum) AJ37 Viggen-project and I'd like to make a similar program for the F-18 HUD (and other HUDs if I can get the proper documentation)

[Guest jprintz]

Hey Jon! Actually, I have the same values as you for the HUD course line steering symbology. (Someone was kind enough to send me the F/A-18 NATOPS.) In real life though, the pilots set the course to be indicated to BRC (the carrier's heading), NOT runway heading. (See this video: http://www.youtube.com/watch.php?v=dKkqxjf...iation%20Flight. It's a T-45 HUD, but VERY similar symbology to the Hornet's. All Hornet video I've seen shows the same thing.) Doing it this way, while in that slow constant turn from base to final you get an EXACT indication of when you're crossing the stern of the ship. Very useful to let you know if you're gonna be short or overshoot. So the arrow is centered when directly behind the carrier (regardless of heading, like in an HSI), and not when lined up with the carrier "runway." That all sounded weird when I wrote it, but hopefully it'll make sense.Now, the one thing I did do is widen the steering dots to 5 degree intervals from 4. I felt this made it more useful in FS, as that is what people are generally more used to, and it would match most HSI gauges people have.... So, from my screenshot, I have HUD steering linked to NAV 2 in this instance (it can be linked to Nav1, Nav2, or GPS), at course 220. Bearing to the carrier is 215 (+/- .5), and the arrow is right where it should be, near the inside dot.Isn't this a great hobby? ;-) All of this gauge work has really rejuvinated my interest in the actual sim FLYING! Scott