[Top] [All Lists]

Re: [TowerTalk] terrain profile algorithm

Subject: Re: [TowerTalk] terrain profile algorithm
From: Jim Lux <>
Date: Sat, 16 Jun 2012 10:14:29 -0700
List-post: <">>
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.


TowerTalk mailing list

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