On Sunday 06 January 2008 18:32, AnMaster wrote: > Curtis Olson wrote: > > On Jan 5, 2008 8:56 PM, Csaba Halasz <> wrote: > >> Hi! > >> > >> I have changed Tiago's patch somewhat, it now iterates over > >> all the ground layers. > >> Debug output looks like this for KSFO: > >> > >> Found tower ground layer at 124.323ft, material <unnamed> > >> Found tower ground layer at 114.536ft, material <unnamed> > >> Found tower ground layer at 82.3405ft, material <unnamed> > >> Found tower ground layer at 42.9577ft, material <unnamed> > >> Found tower ground layer at 5.36808ft, material pc_tiedown > >> Setting tower viewpoint altitude 112.368 > >> > >> I was hoping to find a layer like "Grass" or "Ground" > >> somewhere, but no. So for now, the code picks the lowest > >> layer, which might not work if the tower is sunk into the > >> ground as other objects frequently are. I tested LHBP and that > >> worked (even had grass material). > >> > >> Also attached is a patch to apt.dat (gunzip, patch, gzip) that > >> updates KSFO and KNID tower viewpoint based on the scenery. > >> I am not sure we can trust the tower position in apt.dat, > >> since the elevation values are frequently obvious nonsense > >> (500 for KSFO and 0 for KNID). > >> > >> Please comment. > > > > Isn't the airport altitude also reported in the same file? > > > > We should be able to set the tower altitude in MSL to apt_alt + > > tower_alt. It seems like extreme overkill to actually query the > > ground elevation. > > > > Regards, > > > > Curt. > > However the airport altitude seldom matches the scenery. While > this is a pitty, what would users notice most: > > * Tower view is calculated from scenery, so it any tower building > placed on the terrain in scenery. * Tower view is calculated from > entry in apt.dat that is likely not the same as the scenery, > tower view may end up above tower, or below tower (or even below > ground) > > Since the elevation values are way off as Jester mentioned, I > think basing it on scenery is best. However the airport altitude > should probably be corrected as well. > > > Regards, > > Arvid Norlander
I think a lot of this problem might be down to the resolution of the underlying SRTM data. Even using > 5 point interpolation, which would be very time consuming to generate, you'd probably only get accurate results half the time and if you extended that to a two-dimensional interpolation it would probably still only bring it down to ~10% accuracy for any intermediate point. To summarise: the curve between any two points can go anywhere, so between the points you're best off not fiddling with it too much and accepting the intermediate errors. Of course, it might be nothing to do with that at all:) LeeE ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
