[TowerTalk] terrain profile algorithm
jimlux at earthlink.net
Sat Jun 16 10:14:29 PDT 2012
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
>> 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
> 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 www.heywhatsthat.com
> 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
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.
More information about the TowerTalk