[Top] [All Lists]

Re: [TowerTalk] terrain profile algorithm

Subject: Re: [TowerTalk] terrain profile algorithm
From: Ian White GM3SEK <>
Reply-to: Ian White GM3SEK <>
Date: Sat, 16 Jun 2012 18:23:39 +0100
List-post: <">>
Jim Lux wrote:
>On 6/16/12 9:55 AM, Ian White GM3SEK wrote:
>> Jim Lux wrote:
>>> I'm looking for an algorithm for my "generate all profiles for HFTA" app..
>>> I've taken a couple trivial shots at this, but I'm pretty sure someone
>>> out there knows of a "better way".
>>> here's what I want..
>>> I have an array of heights vs distance at fairly close post spacings (on
>>> the order of 10 meters) maybe 1000 points or so, representing the
>>> profile along a particular radial.  What I want to do is "compress" that
>>> into about 100 or so segments that are connected (e.g. HFTA input).
>>> That is, I want to convert that to a series of x,y coordinates connected
>>> by straight lines that "adequately" represents the terrain.
>>> I started with a simple "if the adjacent point is within X meters in
>>> altitude, then collapse the two into one", but that produces profiles
>>> that somehow don't look right (and I can't say much about their HFTA
>>> fidelity).  If the underlying terrain were a ziggurat or mesas with
>>> valleys, it would probably work, but it turns a gentle slope into a
>>> staircase.
>>> This is a classic problem in cartographic generalization, and, as it
>>> happens, this kind of profile is well represented by a fractal, but not
>>> that this helps me much.  I was hoping that someone out there knew of a
>>> clever way to do it.
>>> Preferably in Python, since that's what I've written everything else in,
>>> but I can convert anything.. so if you have one written in COBOL, that's
>>> fine.
>>> _______________________________________________
>> If may be easier than you think, because HFTA already makes a linear
>> extrapolation between data points, regardless of horizontal separation.
>> Faced with 360 sets of computer-generated radial data at 100m intervals
>> going out to 200km, my manual algorithm was:
>> 1. Cut off the data somewhat beyond the visual horizon. You can do this
>> the old-fashioned way by looking at a map, by writing your own routine
>> or by plotting an approximate horizon profile using
>> 2. Wherever there are>=3 points at the same height, remove all but the
>> first and last. Large areas of water are obvious targets [insert other
>> flatlander jokes here].
>> 3. If the number of points is still too large for HFTA, consider
>> removing redundant data anywhere that the slope can be approximated by a
>> straight line between the first and last points. The further away from
>> the antenna, the less any errors will matter, so work inward from the
>> greatest distance.
>> 4. Repeat 2 and 3 until the data set is small enough for HFTA to handle.
>> 5. And then - most important - go outside and LOOK AT WHAT'S REALLY
>> THERE in the immediate foreground of the antenna.
>> Don't hesitate to modify the satellite data wherever you know better.
>> You are much closer to the reality on the ground!  For example, dense
>> areas of trees would have given a good radar reflection from the
>> tree-tops, but at HF the true ground level will be a better
>> approximation.
>Yes.. that's the sort of algorithm, but I'm looking at something automated..
>Step 2 is basically what I have now..
>It's the step 3 part that is tricky to automate.. You want straight line
>segments that approximate a section, but that are continuous with the
>segments on either side.  Before I spent significant time designing and
>coding such an algorithm, I thought I'd ask.

One thing I forgot: falling ground on the far (shadowed) side of distant 
ridges can almost certainly be simplified in quite a brutal way. This 
might be a good first target in step 3.


73 from Ian GM3SEK

TowerTalk mailing list

<Prev in Thread] Current Thread [Next in Thread>