LocFinderCrossSections

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

Generic Mapping Tools as seen in action
Apache's GD Module Official | Documentation

Resources Available

LocFinder

Coordinates for all nodes

Linux

We can install whatever we need.

MapServer

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

Contour data

Defined in the mapfile (tc.map) as:

LAYER
  NAME "contours"
  STATUS ON
  TYPE LINE
  TILEINDEX "3d_tile_lines_polyline"
  TILEITEM LOCATION
  LABELITEM "MSLINK_0"
  MAXSCALE 60000
  PROJECTION
    "init=epsg:28355"
  END
  CLASS
    NAME Contours
    COLOR 240 210 180
    LABEL
        TYPE TRUETYPE
        ANTIALIAS TRUE
        FONT arial
        COLOR 0 0 0
#       BACKGROUNDCOLOR 255 255 230
        COLOR 165 143 120
        SIZE 8
        MINSIZE 4
        MAXSIZE 8
        ANGLE AUTO
        POSITION CC
        #MINFEATURESIZE 100
        MINFEATURESIZE AUTO
        BUFFER 10
    END
  END
END

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:

LOCATION (X,Y) pairs	MSLINK_0 Elevation
(-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.

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

Create a process to 'draw' the line between two points, and find it's intersection with the contour lines. If it doesn't work well at 'finding' the contour lines, perhaps increment GPS coordinates in the direction, and then get the height at that point.
Collate this data and fill the gaps between contour readings with an appropriate rise or fall.
Whip out image creation/plotting tools and make the graph. (GD?)

To refine the points above:

What kind of data is in the geographic data we have?
Is it possible to "Get" the elevation of any particular point given it's latitude and longitude?
Or do we need to calculate it by "finding" the nearest contour lines and interpolating?

This seems to be at the crux of our problem:

Given vectorised contour lines, how do we find the elevation of a point that isn't sitting right on a contour line?
How can we work out the distance to the nearest contour lines?
How is a contour line described in our geographic data? A series of geographic points? Does MapServer then draw a line between these points?

Dan Rethinks:

The straight line through Node A and Node B is a two-dimensional vector. We need a routine that will find all intersections of that 2D-vector and every 2D-contour line between Node A and Node B. We then create a list or "array" of the latitude, longitude and height of each of those intersections. Once we have this array of 3D-coordinate points it would be easy enough to plug them into a graphing application (such as the Apache GD module) and create a 2D graph. No interpolation required! The graphing application will join the dots for us. Pretty much what gummAY said.

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.

points[0.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 Mon, 26 Jul 2021 12:49:29 +0000

[EditText] [Spelling] [Current] [Raw] [Code] [Diff] [Subscribe] [VersionHistory] [Revert] [Delete] [RecentChanges]

Node Statistics
building	132
gathering	192
interested	514
operational	235
testing	214