home  wiki


It would be nice to be able to generate topographic cross sectional representations showing the elevation (and FresnelZone) between any two nodes. This will help users determine if LineOfSight exists between themselves and another person's node.

Here's an AsciiArt representation of what we might expect:
|                  NodeGHO |
| NodeAJJ           __A_   |
|   _A_   _      __/    \_/|
|__/   \_/ \   _/          |
|           \_/            |
|                          |

Suggested Tools

Resources Available


Coordinates for all nodes


We can install whatever we need. :D


This is a bit of a no-brainer... :P

Contour data

Defined in the mapfile (tc.map) as:
  NAME "contours"
  TILEINDEX "3d_tile_lines_polyline"
  MAXSCALE 60000
    NAME Contours
    COLOR 240 210 180
        FONT arial
        COLOR 0 0 0
#       BACKGROUNDCOLOR 255 255 230
        COLOR 165 143 120
        SIZE 8
        MINSIZE 4
        MAXSIZE 8
        ANGLE AUTO
        BUFFER 10

In MapServer speak, the data is sets of coordinate pairs for each point along a contour line, not necessarily joined at each end. The actual elevation is stored as ancillary information. Shown in a simple example:
(X,Y) pairs
(-137.21,43.34), (-137.21,43.37), (-137.22,43.35) 40
(-137.21,43.35), (-137.23,43.40), (-137.24,43.36) 50

Proposed Solution

...help us out if you have some time - hit EditText and add your contributions. :D

At the risk of sounding very silly, an elaborate oversimplification:

To refine the points above:
This seems to be at the crux of our problem:

Dan Rethinks: :)

At this point it's difficult to go any further with this for those of us who don't have direct access to the topo data that's used in LocFinder. We don't know the format of the data. And we can't play with it to get an idea of how it all works together. I am considering installing MapServer locally and playing with it, Generic Mapping Tools and PHP - but it's all academic if I don't have any real data to play with.

Seconded, some live data would be nice to play with -- but apparantly it sizes up into the multiple gigabytes, so which section do we want? (and indeed is it separable) I've just downloaded MapServer and intend on having a play shortly. --gummAY 23/6
What about height above ground? -- not everyone's antenna is just sitting on the ground in their backyard. New field to deal with in the node information there. Can mapserver deal with this? Even go as far as mast reccommendations for interested nodes ... who knows?! -gummAY 01/07

Re antenna elevation , we'd need another field in the node's entry like nodedb does. Should be pretty easy to add but it's also usefull to tweek with if the
elevation data is a little off. Peter (melb_ap) 02/07

I'll add the field to the database, but a default value would be useful. What sounds reasonable to most people? Somewhere between 5 and 10 metres sounds OK to me.

Yep sounds good 10mtrs is prob a good number , single story house is about 4mtrs ish to the top of the roof add a 6mtr mast which isn't unreasonable.
Say under the area section in the node entry - an entry such as
'Antenna Height (Mtrs)' ?
Another entry there later cound be a calculated field of ground elevation
from their co-ordinates. But there's more important tasks for now and
this can be shown in the los plot when we get that worked out.
Peter (melb_ap) 03/07

Working with GD, for image creation

I've been reading up on it, and working backwards from the final product in an effort to determine what we require, where. A work in progress. -- gummAY

What do we need to do with GD to make pretty images?

include the library, a php module in our case, probably done in php.ini

declare the image

gdImagePtr <name>;

Allocate the image size.

<name> = gdImageCreate(pxaccross, pxtall)

Make the background colour (First colour GD sees is background -- what do we want?)

background = gdImageColourAllocate(<name>, red, green, blue)

define a colour for the link line, try green

green = gdImageColourAllocate(<name>, 0, 255, 0)

Now, the link line itself is drawn, using px values

gdImageLine(<name>, x1, y1, x2, y2, green);

This is where we want our input.

x1 and x2, the horizontal values probably won't change, they'll be stuck a few pixels in from the border, and there they'll stay.

y1 & 2 are our elevation data, calculated down into pixels.

Next, we want to draw a filled in polygon, for our elevation diagram....

First, define how many points in the polygon -- we need to find this out beforehand. There will always be at least three. Bottom left, MIddle and Bottom Right

gdPoint pointswe declare the points

Y is agian the elevation data, translated into pixels, xn is the point at which the elevation changes. We can either find this out, or sample at predefined (small) intervals.

.x = x0;
points0.y = y0;
points1.x = x1;
points1.y = y1;
points2.x = x2;
points2.y = y2;

and so on

We want it black, so define black

black = gdImageColorAllocate(im, 0, 0, 0);

then paint it black

gdImageFilledPolygon(<name>, points, #, black);

Now, throw the file into a png

gdImagePng(<name>, <output pointer>);

From this brief foray into GD, we can acertain what we need to put into the image manipulation tools at hand. That is;

Elevation data, translated into pixels -- actually, can we use the real data in the image, how high is the image and how high is the highest altitude?

Starting again, elevation data, for the nodes themselves -- plus mast/antenna height. Hmmm, can we generate this and throw it in a database field to save us one job ... is it worth it?

OK. Elevation data for the nodes, and we have to make a choice for the elevation diagram between the points. Do we a) Use a predefined interval of sampling or b) try to find out the points at which the elevation changes (in our data). A scale also needs to be developed between pixels in the image and metres on the ground. This is, however, dynamic due to differing distances between nodes.

Ok i've been thinking of a practical way to move further toward application -
what about this option. The topo data i've found so far is in a grid earth
wide (say 5 sec intervals) If we just use a separate database for the topo
data all we have to convert is the gps co-ordinates, and we dont have to
worry about the random aspect of contour lines.
The moral of this is , dont try to re-invent the wheel.
If we use this method, i see the needs being,
1 . Hi res topo data , about $300 from lands.gov from what i've heard.

2. Some code to convert the co-ords to the topo data format , or the reverse.
  (shouldn't be to hard)

3. The code to interpret this data into a topo map in the vertical plain.

The bonus of having this data , is once you have a vertical plain map worked out
, whats to stop you going the next step & creating multiple plots at say every 10 deg from point A and ending up with a 360 Degree 3D color contour map from that point. Then the possibility of coverage mapping follows on.

Food for thought; Peter Melb_AP

Version 18 (current) modified Tue, 03 Jul 2007 23:12:05 +1000 by gummAY
[EditText] [Spelling] [Current] [Raw] [Code] [Diff] [Subscribe] [VersionHistory] [Revert] [Delete] [RecentChanges]
> home> about> events> files> members> maps> wiki board   > home   > categories   > search   > changes   > formatting   > extras> site map


 Remember me.

> forgotten password?
> register?
currently 0 users online
Node Statistics