home 
wiki
wiki
Spelling: LocFinderCrossSections
It would be nice to be able to generate topographic cross sectional
representations showing the elevation (and FresnelZone [1]) between
any two nodes. This will help users determine if LineOfSight [2]
exists between themselves and another person's node.
Here's an AsciiArt [3] representation of what we might expect:
---------------------------- | NodeGHO [4] | | NodeAJJ [5] __A_ | |
_A_ _ __/ _/| |__/ _/ _/ | | _/ | | | ----------------------------
-------------------------
SUGGESTED TOOLS
* Generic Mapping Tools [6] as seen in action [7]
* Apache's GD Module Official [8] | Documentation [9]
-------------------------
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 [10] 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 [11] 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 [12]. 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 [13] 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 [14] 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 [15]
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 ;
Allocate the image size.
= gdImageCreate(pxaccross, pxtall)
Make the background colour (First colour GD sees is background --
what do we want?)
background = gdImageColourAllocate(, red, green, blue)
define a colour for the link line, try green
green = gdImageColourAllocate(, 0, 255, 0)
Now, the link line itself is drawn, using px values
gdImageLine(, 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
Then,">we 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 [16].y = y0;
points1 [17].x = x1;
points1 [18].y = y1;
points2 [19].x = x2;
points2 [20].y = y2;
and so on
We want it black, so define black
black = gdImageColorAllocate(im, 0, 0, 0);
then paint it black
gdImageFilledPolygon(, points, #, black);
Now, throw the file into a png
gdImagePng(, );
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 Peter Melb_AP [21]
Links:
------
[1] http://melbournewireless.org.au/?FresnelZone
[2] http://melbournewireless.org.au/?LineOfSight
[3] http://melbournewireless.org.au/?AsciiArt
[4] http://melbournewireless.org.au/?NodeGHO
[5] http://melbournewireless.org.au/?NodeAJJ
[6] http://gmt.soest.hawaii.edu/
[7] http://gmt.soest.hawaii.edu/gmt/examples/ex14/gmt_example_14.html
[8] http://www.boutell.com/gd/
[9]
http://aspn.activestate.com/ASPN/CodeDoc/Apache-GDGraph/Apache/GD/Graph.html
[10] http://melbournewireless.org.au/?MapServer
[11] http://melbournewireless.org.au/?MapServer
[12] http://melbournewireless.org.au/?LocFinder
[13] http://melbournewireless.org.au/?MapServer
[14] http://melbournewireless.org.au/?MapServer
[15] http://melbournewireless.org.au/?gummAY
[16] http://melbournewireless.org.au/?0
[17] http://melbournewireless.org.au/?1
[18] http://melbournewireless.org.au/?1
[19] http://melbournewireless.org.au/?2
[20] http://melbournewireless.org.au/?2
[21] http://melbournewireless.org.au/?Melb_AP
[EditText] [Spelling] [Current] [Raw] [Code] [Diff] [Subscribe] [VersionHistory] [Revert] [Delete] [RecentChanges]