Ground Altitude at Lat/Long via simconnect ?

[Guest b21]

I've come across a hint that this question may have been asked before, but no clue as to whether it's been answered:************************** QUESTION ******************************** Via simconnect is there a call that would return ground altitude at a given lat/long?*******************************************************************Alternatively (better) at an offset relative to the lat/long of the user aircraft (I know given the former I could calculate the latter)?I would imagine there are many applications of this feature but my idea is to sample a number of points around the user aircraft (e.g. a total of 16 points within 2km). With appropriate averaging I could estimate the *slope* of the underlying terrain and with the height of the aircraft above the ground plus ambient wind I could calculate the effect of ridge lift (or sink, or turbulence) on the aircraft.The method seems simple and efficient to me, to the extent that a module could do it without even needing a user interface.ThanksB21EDIT ** it seems you could do this by creating an AI object, planting it on the ground at the required lat/long, and then reading its altitude, i.e. SimConnect_AICreateSimulatedObject(...) with the lat/long as desired plus SIMCONNECT_DATA_INITPOSITION/OnGround=1and then read the altitude of that object withSimConnect_RequestDataOnSimObject(...)and then move it around withSimConnect_SetDataOnSimObject(...)but that all seems a bit inefficient...

[Guest ziporama]

I read this and the first thing off the top of my head is one crazy idea.I'm sure there is the obvious way, but since I don't know it, here's what I would look into:1) create 4 "dummy" objects in FSX (you would have to create a transparent cube in GMAX or 3DStudio, place compiled object in the simobject library. Each will be invisible in the world.2) Create and position the 4 dummy objects in the FSX world using the AI positioning tools, referencing the location of your aircraft as the center3) Read the above ground altitude for each object.4) do your computation.Perhaps I just solved my terrain following radar dilemma :)Hope this helps,Etienne

[taguilo 33]

This is an interesting subject.Maybe for a radar terrain, or more precisely a weather radar returning terrain echo, instead of using 4 objects a set of 64 objects could be placed within a 128 km radius. Their altitude could be classified from 0 to 255, exactly the same as clouds' state array.So whenever the radar is tilted down and terrain is captured, you can simulate its echo the same as the clouds' echo is simulated. Should be worth a try...Tom

[Guest b21]

An update:I have been programming exactly this technique using simconnect, placing a 'food_pallet' (which looks like a purple igloo) at various points ahead of the user aircraft. Having a visual image easy to recognise helps a lot as you can see where the probe is taking place. It would be easy to replace the model later.From initial testing, the technique *does* work, i.e. you can create an AI object "Food_pallet" with an initial position ahead of the user position with OnGround=1, and then read back the "GROUND ELEVATION" from it.I actually have a chain of requests that sample the ground at six points starting below the user aircraft, by creating the "Food_pallet" and moving it approx 500m at a time out in a straight line.From the aircraft it looks like a purple beacon pulsing out from the aircraft as you progress.I *really* could do with more experienced simconnect programmers making a comment, as this is my first simconnect app and I reckon half the problems I've had are ones many of you have seen before.Some current issues are:1) My technique is currently to create *one* AI probe, which I move around during a single sweep of the terrain. For my six-samples-per-sweep I should also test the technique using *six* AI probes instead. I just don't know if it's more efficient to create an AI object or move it.2) The AI crap is getting in the way, i.e. I would like as dumb an object as possible. As it is FSX tries to be clever when I create the object, by 'dropping' it in an animation onto the landscape.3) At the moment my design is a 'chain' of move and data requests for a given sweep. I.e. I move the probe to position 1, request its ground elevation, and when that asynchronously returns then I move the probe to position 2 and request the ground elevation again etc. So there's a fair amount of IP exchanges per sweep. Maybe if I had six probes I could move them all and request all their ground elevations simultaneously - I would then have *six* asynchronous RequestData requests returning together and would need to keep track of when I've got them all.4) I'm not convinced the timing between the 'move' and the request ground elevation is dependable. I.e. it could be possible the AI object has not rested on the ground before the elevation request happens - I'm not sure yet.But overall the technique hasn't affected my framerates, and it *is* returning a sweep of ground elevations that looks kosher, so I think something is doable.*ANY* comments or help appreciated.B21B21

[Guest b21]

I've changed the code to create six AI objects and request their ground elevations simulataneously, and then handle the six asynchronous data requests. This works at least as well as one object sweeping around and makes the code simpler, and I can't detect any impact on framerates at all.This screenshot shows how the probes look using food_pallet (purple igloo) ai object. When it's working I can choose the right placement of the probes (they're much too close now) and a better visual image:http://carrier.csi.cam.ac.uk/forsterlewis/...ages/probes.jpg**HELP!!**If anyone can help/comment I'd be grateful. At least one significant problem remains: when I move the aircraft and trigger a new sweep, each probe moves to the correct new location relative to the user aircraft, i.e. each snaps instantly to the correct lat/long, but the if the ground elevation has changed from the probe's last position it can be seen to drift downwards from it's previous height down to the new ground surface like a parachutist, taking a few seconds, and even casting a shadow as it descends. The first readout of ground elevation is WRONG, i.e. too high. You don't get a good reading until the second data request, even though the probe still hasn't landed on the ground. The animation is really quite slow.Any ideas/comments ?B21

[Guest b21]

hmm on further thought, this may be to do with the fact that I 'move' the simobject (probe) and immediately request data (lat,long,ground elevation) on the simobject. Is there a way to get confirmation that the 'set data' request is fully executed? It doesn't seem to trigger a message into the dispatchproc. I don't want to introduce an arbitrary delay.B21

[Guest JeanLuc_]

Interesting thinking out of the box! I have a question about this technique you are using: does it affect any TCAS like application spwaning these AI objects? i.e. do they show up along with valid aircraft targets?

[Guest b21]

re TCAS the answer has to be "no", as the 'create' call is explicitly for these "Misc" scenery objects rather than aircraft. It would be possible to do the same technique using AI aircraft, but this would be much much less efficient because of all the AI that FSX would be trying to do and presumably those aircraft would turn up in the other systems.As far as I can tell, this technique is now working. The only tweak I have to explore to to address the issue that you don't seem to be able to 'move' the object and then in the next line in your code request it's ground elevation. It seems you have to return control to FSX, then get control back in your simconnect code when ground elevation can be read immediately. The fact that the igloo 'parachutes' are still descending from their previous height doesn't actually matter. This issue can be illustrated that the correct ground elevation is returned in the *second* request if you have the result of the first trigger the second.B21

[Guest b21]

All working very well now ... I can set the probes each on a bearing and distance from the user aircraft, and return the ground elevation at each of the probe points.The response time is very quick (milliseconds) and I have not detected any impact on frame rates (mine are capped at 25).The basic technique is:1) create an AI object for each of your probe points. The 'Food_pallet' in the Misc AI Object folder works well and is easy to see for testing. The 'Barrel' seems to have become invisible in SP2 but otherwise works just as well. The initial location of the AI probes doesn't matter.2) Set up an array with bearing and distance from the user aircraft for each of the AI probes - this is static for the program and defines the 'pattern' of probes relative to the user position.3) REQUEST user aircraft data : latitude, longitude once-per-second (I get ground elevation for the user aircraft also for an extra data point)4) When request (3) returns, Calculate the lat/long needed for each AI probe using the aircraft current lat/long and direction with the offsets for each probe from the array in (2) and set OnGround=1. Set data for the new lat/longs on each of the AI probes and REQUEST the user position again but with a different request id than (3).5) When request (4) returns, ignore the user data and REQUEST the ground elevation of every probe, with a different request id for each request.6) As all the requests from (5) return, keep track of how many probes have returned ground elevation and when you have them all, PROCESS the complete set of ground elevations (e.g. update your gauge).With the once-per-second request in (3), the program steps (4)-(6) should run once-per-second.Important note re step (4): the more obvious step would be to REQUEST the ground elevation of every probe immediately here, effectively skipping step (5). *But* this does not return the correct ground elevation, as if the probe is not yet fully moved. The additional 'redundant' request for the user position gives FSX the processing control back to do the actual probe moves.There are quite a few options in using this data. In my case the direction of the probe is INTO THE AMBIENT WIND, as I'm using it to automatically generate ridge lift. A more common use would probably be to point the probes in the direction of flight. I'm assuming this is a fairly short-range technique due to the FSX 'reality bubble'.B21

[Guest ziporama]

Thinking out of the box is good :)

[Guest b21]

OK the thinking out of the box is done, and the technique of moving objects around and requesting their ground elevation is documented here:http://carrier.csi.cam.ac.uk/forsterlewis/.../dev/sim_probe/The ground sampling part is mostly the first half, as the paper goes on to discuss the computation of topographic (ridge) lift from those ground elevation samples.At the end of the report are links to C++ source (and the executable) that samples the ground elevation at five points around the aircraft. The source file includes some general routines that compute the lat/long of a point at an arbitrary distance and bearing from the user aircraft.B21

[Guest in_04]

Hi,sounds very good.If you need beta testers for the product you could count on me.

[Guest in_04]

Hi B21,do you have the generation of ridge lift programmed too?I read your interesting article and see that you nearly have altogether for a ridge lift utility.If you ready for test of this utility, you could contact me for testing.I also read the other sites of your(?) web presentation and found you a glider pilot(?).Maybe you're interested in a modified ThermalDescriptions.XML file made by me which is much more challenging than the default one.I added it and if you get time you could give some comments if this one is more "real" than the original one.http://forums.avsim.net/user_files/182685.txt