On Wed, Mar 24, 2010 at 9:30 AM, Erik Hofman wrote:
> I think I forgot about the missing elevation data. So it would still
> need post-processing.
One of the cool things (I think) that the current airport generator tool
does is lay the airport surface over the DEM terrain in a nicely behaved
way.
We can't use the raw terrain elevations directly because there are
tremendous artifacts and noise for each elevation post ... up to 5-10 meters
variation. That may not sound like a lot, but if you use the raw elevation
data to define the airport surface and then put yourself at the end of the
runway and look down the length of it, you see terrible spikes and sawtooth
type patterns that repeat over and over again down the entire runway. It is
totally unacceptable.
However it's important to fit the airport to the underlying terrain so that
the airport surface matches up reasonably well at the boundaries with the
surrounding terrain. You don't want an airport that is sitting on a
pedestal or dug into a deep hole. It needs to blend in naturally with the
surrounding terrain.
The airport elevation defined in the FAA database is for one single spot on
the airport, and for smaller airports and especially for private airstrips,
it can be 10's of meters off.
In addition you have challenging cases like Albuquerque, NM (KABQ.) KABQ
has *significant* elevation changes across different portions of the airport
area. In addition there is a valley that cuts away an area between two
crossing runways and that is also very difficult to deal with.
The solution I came up with that seemed to work the best across a broad
range of challenging airports was to take a 3d polynomial equation and do a
least squares fit to the noisy terrain data. This produces a function that
approximates the underlaying terrain. It's also a smooth function so there
are no hard seams or creases in the airport surface. The trick is to pick
a polynomial with enough degrees of freedom to adequately fit the terrain
surface (to avoid cliffs at the airport edges) but not so many degrees of
freedom that it would respond to the noise in the terrain data and produce
extraneous artifacts.
Judging by the total lack of end user comments in this area, I think we
ended up with a pretty good balance of naturally fitting a nice surface to
the terrain data and blending it into the surrounding terrain.
The system is automated though so it's not always perfect and I'm sure there
are airports that could use some tweaking. One idea that I had (and haven't
acted on) was to allow specifying a set of "fit parameters" for individual
airports where the default parameters didn't do a good job. Another issue
is that when an airport area spans the boundary between two tiles, then
there can be some small mismatches along the edges of the one of the tiles
... the fitting algorithm doesn't do a perfect "crackless" fit against the
adjacent tile hole edges like it can when the airport is completely
contained within a single tile.
Regards,
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
