What elevation tool do you use and how does it compare in accuracy?

I'm trying to do some antenna siting calculations ... and ... for
that ... I need elevation information.

However ... given any set of coordinates ... e.g., Mt Hamilton,
California at coordinates 37.337408,-121.644073 ... I find the following
elevation tools all give DIFFERENT elevations (some are off by more than
a hundred feet!)

1. Google Map API yields 1217.061889648438 meters (3992.985 feet)
http://maps.googleapis.com/maps/api/elevation/json?
locations=37.337408,-121.644073&sensor=false

2. Geoplaner yields 1217.1 meters (3993 feet)
http://www.geoplaner.com

2. Daftlogic yields 1230.988 meters (4038.676 feet)
http://www.daftlogic.com/sandbox-goo...d-altitude.htm

4. Earthtools yields 1210 meters (3969.8 feet)
http://www.earthtools.org

5. Heywhatsthat (SRTM db) yields 1213 meters (3980 feet)
http://www.heywhatsthat.com/profiler-0904.html

Q: Which elevation tool do you use ... & what's the accuracy?

Unless you are dealing with a surveyed peak, I would assume all the
elevation data is derived from USGS NEDs (national elevation dataset).
For the most part, they are only 1/3 arc second. I'm speculating that
some of these programs are reporting data from the NEDs as if they are
section of flat areas on the 1/3 arc second grid, while others are
interpreting the elevation using a weighting scheme.
http://seamless.usgs.gov/

Have you considered running SPLAT! ? It uses 1/3 arc second data. It can
predict line of sight. Generally I find I do better than the SPLAT!
prediction, so if SPLAT! says no, the answer is maybe, but if SPLAT!
says yes, you have line of sight. The program has hooks for predicting
signal strength, models knife edge diffraction, etc.
http://www.qsl.net/kd2bd/splat.html

Similar software is
http://www.cplus.org/rmw/english1.html

For pure line of sight, there is GRASS. However GRASS has a very steep
learning curve.
http://grass.osgeo.org/

What takes maybe 5 minutes on SPAT can take 2 days on GRASS. I don't
know if the results are that much better.

For the bay area, I suspect SPLAT! is fine. I think it's shortcomings
are in areas where there is really rugged terrain that probably isn't
modeled well.

On Sat, 03 Mar 2012 00:10:32 -0800, miso wrote:
Have you considered running SPLAT!

I just installed the Splat (Surface Path Length And Terrain) RF analysis
application (version 1.3.0-1) from the default Ubuntu Software Center.
- http://joysofprogramming.com/install-splat-ubuntu/
- $ sudo apt-get install splat (dpkg -s splat)

It's apparently a command-line tool which needs me to download the
database so it may take a while to figure out.

Googling for a "splat!" tutorial, I find it's also a photoshop hack so
it's actually hard to figure out how to use it on the fly.

Q: Do you have a working example or two for how to use it from the
command line?

On Sat, 03 Mar 2012 15:59:39 +0000, alpha male wrote:



splat | less



http://www.kgiwireless.com/Documents...icSiteList.asp

http://www.americantower.com/sitelocator/default.aspx

On 3/3/2012 7:59 AM, alpha male wrote:
On Sat, 03 Mar 2012 00:10:32 -0800, miso wrote:
Have you considered running SPLAT!

I just installed the Splat (Surface Path Length And Terrain) RF analysis
application (version 1.3.0-1) from the default Ubuntu Software Center.
- http://joysofprogramming.com/install-splat-ubuntu/
- $ sudo apt-get install splat (dpkg -s splat)

It's apparently a command-line tool which needs me to download the
database so it may take a while to figure out.

Googling for a "splat!" tutorial, I find it's also a photoshop hack so
it's actually hard to figure out how to use it on the fly.

Q: Do you have a working example or two for how to use it from the
command line?

Quote:

$ splat --help *** ERROR: No transmitter site(s) specified! $ splat --==[ SPLAT! v1.3.0 Available Options... ]==-- -t txsite(s).qth (max of 4 with -c, max of 30 with -L) -r rxsite.qth -c plot coverage of TX(s) with an RX antenna at X feet/meters AGL -L plot path loss map of TX based on an RX at X feet/meters AGL -s filename(s) of city/site file(s) to import (5 max) -b filename(s) of cartographic boundary file(s) to import (5 max) -p filename of terrain profile graph to plot -e filename of terrain elevation graph to plot -h filename of terrain height graph to plot -H filename of normalized terrain height graph to plot -l filename of path loss graph to plot -o filename of topographic map to generate (.ppm) -u filename of user-defined terrain file to import -d sdf file directory path (overrides path in ~/.splat_path file) -m earth radius multiplier -n do not plot LOS paths in .ppm maps -N do not produce unnecessary site or obstruction reports -f frequency for Fresnel zone calculation (MHz) -R modify default range for -c or -L (miles/kilometers) -db threshold beyond which contours will not be displayed -nf do not plot Fresnel zones in height plots -fz Fresnel zone clearance percentage (default = 60) -gc ground clutter height (feet/meters) -ngs display greyscale topography as white in .ppm files -erp override ERP in .lrp file (Watts) -ano name of alphanumeric output file -ani name of alphanumeric input file -udt name of user defined terrain input file -kml generate Google Earth (.kml) compatible output -geo generate an Xastir .geo georeference file (with .ppm output) -dbm plot signal power level contours rather than field strength -gpsav preserve gnuplot temporary working files after SPLAT! execution -metric employ metric rather than imperial units for all user I/O If that flew by too fast, consider piping the output through 'less': splat | less Type 'man splat', or see the documentation for more details. This compilation of SPLAT! supports analysis over a region of 8 square degrees of terrain.

SPLAT! isn't a photoshop hack, but you can use gimp (or I suppose
photoshop) to hack with the png files it creates. I take the png files
and chop them up so they are acceptable to google earth, then make an
overlay out of them. Splat can do it, but unless things have changed, it
makes a kml file that can be too large for GE to accept. GE wants tiled
imagery. I haven't run it in maybe 18 months, so I can't really say much
without setting it up again.

I saw a GPS mentioned. I never found GPS elevation to be too accurate. I
have a barometer in my GPS. I never used it, so I can't vouch for it's
accuracy. But you can enter in the pressure from the airport, or
calibrate it to a known reference (known altitude for a position).

One idea would be to check the USGS monuments and find the closest
reference.
http://www.ngs.noaa.gov/cgi-bin/datasheet.prl

Note that sometimes these markers are on private property. Other times
they are in the middle of the street! it pays to look at the reference
on google earth before trying to use it. My Garmin gps60cs was good to
4ft, basically one lsb.

You could get a nearby reference, call the barometer, then quickly move
to your spot before the pressure changes. Or you might get lucky and
find there is a marker there already.

Topo maps have lines of constant altitude, usually on 20ft contours. You
could interpolate from the map.

If you really need accurate data, just pay for a survey. I would guess
something that simple is under a grand. I've paid for land surveys and
they are a few grand, but the altitude at one point is pretty simple.
Potentially the civil engineering firm might have topo data on file that
is not available to the general public. For instance, I paid for a
satellite topo to be done on some property. The civil engineering firm
has it on file and I'm sure it gets peeked at by other people.

On Sat, 3 Mar 2012 04:02:49 +0000 (UTC), alpha male
wrote:

What elevation tool do you use and how does it compare in accuracy?

I'm trying to do some antenna siting calculations ... and ... for
that ... I need elevation information.

However ... given any set of coordinates ... e.g., Mt Hamilton,
California at coordinates 37.337408,-121.644073 ... I find the following
elevation tools all give DIFFERENT elevations (some are off by more than
a hundred feet!)

1. Google Map API yields 1217.061889648438 meters (3992.985 feet)
http://maps.googleapis.com/maps/api/elevation/json?
locations=37.337408,-121.644073&sensor=false

2. Geoplaner yields 1217.1 meters (3993 feet)
http://www.geoplaner.com

2. Daftlogic yields 1230.988 meters (4038.676 feet)
http://www.daftlogic.com/sandbox-goo...d-altitude.htm

4. Earthtools yields 1210 meters (3969.8 feet)
http://www.earthtools.org

5. Heywhatsthat (SRTM db) yields 1213 meters (3980 feet)
http://www.heywhatsthat.com/profiler-0904.html

Q: Which elevation tool do you use ... & what's the accuracy?

Youre asking wrong questions.
First define a surface with height ZERO as a reference.
There are about 100 different definitions alone for that.
Distance from Earth center, median sea level at Novosibirsk,
or a San Francisco? Water isn't level, it follows gravitation.
And so on.

w.

On Sat, 03 Mar 2012 09:13:45 +0100, Helmut Wabnig [email protected] ---
-.dotat wrote:

Youre asking wrong questions.
First define a surface with height ZERO as a reference.
There are about 100 different definitions alone for that.
Distance from Earth center, median sea level at Novosibirsk,
or a San Francisco? Water isn't level, it follows gravitation.
And so on.

w.

If in the US, I would assume that the LAT/LONG uses either WGS84,
NAD27, or NAD83 datums. That reduces the number of available options.

Unfortunately, the USGS is still hanging onto NAD27, while most
mapping programs and displays are on WGS84.
http://www.maptools.com/UsingUTM/mapdatum.html
In the People's Republic of Santa Cruz, the error is about 20 meters
east-west, and about 1 meter north-south. I forgot which way. The
problem becomes really bad when trying to locate a mountain top.
20-200 meters of horizontal error can easily move a position from the
peak, to somewhere on the slope, resulting in large altitude errors.

SRTM and SRTM2 are another oddity. They were created from the space
shuttle, using a radar altimeter. Depending on the whether it's
looking at buildings or trees, there's no really good way to determine
of the indicated altitude is the top of a 100ft redwood tree, the top
of a 10 meter high building, or at ground level.

So, my list of rhetorical questions a
1. What is the OP trying to accomplish? If for an FCC license HAAT
calculation, almost any reasonable guess will suffice.
http://transition.fcc.gov/mb/audio/bickel/haat_calculator.html
If for doing Radio-Mobile coverage contours, you'll need to use the
built in mapping tool to find the peak or exact location on the
mountain top. The choice of application depends on what one is
attempting to accomplish.
2. What level of accuracy is really required? The original position
of 37.337408N -121.644073W is specified to 1 millionth of a degree, or
about 0.09 meters.
http://www.csgnetwork.com/degreelenllavcalc.html
It would be interesting to know where this highly accurate number came
from. Better GPS receivers, without DGPS, can do 3 meters accuracy.
3. What datum are you using? I suggest WGS84. If the lookup tool
offers a choice of datums, pick one and stay with it.
4. Are you interested in ground level, building rooftop level, or
tree top level?

--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831-336-2558
# http://802.11junk.com
# http://www.LearnByDestroying.com AE6KS

On Sat, 03 Mar 2012 19:43:47 -0800, Jeff Liebermann wrote:
What is the OP trying to accomplish?

The neighbors and are discussing setting up a neighborhood mesh network
and we need to ascertain, beforehand, where to place masts and which
direction to point them in our mountainous neighborhood (Skyline & Summit
area).

If for an FCC license HAAT calculation, almost any reasonable guess
will suffice.

For us, probably any reasonable answer would suffice - but why not pick
the most accurate for starters is what we're thinking.

What level of accuracy is really required?
The original position of 37.337408N -121.644073W is specified
to 1 millionth of a degree, or about 0.09 meters.

A few feet would probably work just fine for the neighborhood. We each
have acres of land, but the terrain is so rough that only a few spots for
antennas would be useful. That's why we want to choose them ahead of time.

It would be interesting to know where this highly accurate
number came from.

We didn't want to put our actual location on the net, so, we picked an
arbitrary set of numbers from one of the elevation calculators just as an
example. But we're in the roughly 37,-122 range.

What datum are you using? I suggest WGS84.

WGS84.

We have some numbers in NAD83 from the various WISP providers but they
drive us crazy since we have to imperfectly convert them to WGS84 to keep
our numbers consistent.

Are you interested in ground level, building rooftop level,
or tree top level?

All three because we want to site a dozen or more antennas which need to
have clear line of sight over rooftops and trees by at least the first
Fresnel zone.

On Mon, 5 Mar 2012 15:09:40 +0000 (UTC), alpha male
wrote:

On Sat, 03 Mar 2012 19:43:47 -0800, Jeff Liebermann wrote:
What is the OP trying to accomplish?

The neighbors and are discussing setting up a neighborhood mesh network
and we need to ascertain, beforehand, where to place masts and which
direction to point them in our mountainous neighborhood (Skyline & Summit
area).

Ok. Go thee unto:
http://www.cplus.org/rmw/english1.html
Follow the destructions at:
http://www.cplus.org/rmw/download/download.php?S=1
For maps, download the SRTM3 maps for your area from:
http://rmw.recordist.com
Do not bother with DEM, SRTM1, or other maps. Do NOT unzip the maps.
My directory shows about 600MBytes of SRTM3 data for everything for
the SF Bay and Monterey Bay areas. You can set Radio-Mobile to
automatically download a map if needed, but it's easier to just
download the maps ahead of time.

Follow a simple example such as:
http://www.cplus.org/rmw/afirst.html
to get started. There are also numerous tutorials on the web.
Note that the program uses the concept of "networks" which will be key
to modeling a mesh. Locate your nodes, use realistic values, and
build a model. This part is a PITA and requires considerable time and
effort. Draw the (optical) coverage areas for each node, and the line
of sight:
http://joelgranados.wordpress.com/2011/11/05/wireless-link-calculations-radio-mobile/

You're going to have a big problem in the Santa Cruz Mountains call
trees. These are cellulose and water obstructions that may or may not
appear at the correct altitude on the elevation profiles. 2.4GHz will
NOT penetrate foliage, especially when wet. You'll need to manually
adjust your path profiles for the tree line. If the trees are inside
the Fresnel zone, you'll have losses.

If you have problems, ask here, or preferably the Yahoo Radio-Mobile
group at:
http://groups.yahoo.com/group/Radio_Mobile_Deluxe/

I have a really bad attitude about mesh networks. Bug me if you want
to hear the full rant. For a sample, see the dismal performance of an
early mesh network (MIT Roofnet - Meraki).
http://pdos.csail.mit.edu/roofnet/doku.php?id=interesting
"Surprisingly, the performance over a two hop route is
less than 1/2 that of one hop routes, implying routes
tend to interfere with themselves."
Also:
http://sha.ddih.org/2011/11/26/why-wireless-mesh-networks-wont-save-us-from-censorship/
covers the main problems. Do you really want a phone call at 2AM from
a neighbor asking if the network is down?

--
Jeff Liebermann
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

On 3/5/2012 8:26 AM, Jeff Liebermann wrote:
On Mon, 5 Mar 2012 15:09:40 +0000 (UTC), alpha male
wrote:

On Sat, 03 Mar 2012 19:43:47 -0800, Jeff Liebermann wrote:
What is the OP trying to accomplish?

The neighbors and are discussing setting up a neighborhood mesh network
and we need to ascertain, beforehand, where to place masts and which
direction to point them in our mountainous neighborhood (Skyline& Summit
area).

Ok. Go thee unto:
http://www.cplus.org/rmw/english1.html
Follow the destructions at:
http://www.cplus.org/rmw/download/download.php?S=1
For maps, download the SRTM3 maps for your area from:
http://rmw.recordist.com
Do not bother with DEM, SRTM1, or other maps. Do NOT unzip the maps.
My directory shows about 600MBytes of SRTM3 data for everything for
the SF Bay and Monterey Bay areas. You can set Radio-Mobile to
automatically download a map if needed, but it's easier to just
download the maps ahead of time.

Follow a simple example such as:
http://www.cplus.org/rmw/afirst.html
to get started. There are also numerous tutorials on the web.
Note that the program uses the concept of "networks" which will be key
to modeling a mesh. Locate your nodes, use realistic values, and
build a model. This part is a PITA and requires considerable time and
effort. Draw the (optical) coverage areas for each node, and the line
of sight:
http://joelgranados.wordpress.com/2011/11/05/wireless-link-calculations-radio-mobile/

You're going to have a big problem in the Santa Cruz Mountains call
trees. These are cellulose and water obstructions that may or may not
appear at the correct altitude on the elevation profiles. 2.4GHz will
NOT penetrate foliage, especially when wet. You'll need to manually
adjust your path profiles for the tree line. If the trees are inside
the Fresnel zone, you'll have losses.

If you have problems, ask here, or preferably the Yahoo Radio-Mobile
group at:
http://groups.yahoo.com/group/Radio_Mobile_Deluxe/

I have a really bad attitude about mesh networks. Bug me if you want
to hear the full rant. For a sample, see the dismal performance of an
early mesh network (MIT Roofnet - Meraki).
http://pdos.csail.mit.edu/roofnet/doku.php?id=interesting
"Surprisingly, the performance over a two hop route is
less than 1/2 that of one hop routes, implying routes
tend to interfere with themselves."
Also:
http://sha.ddih.org/2011/11/26/why-wireless-mesh-networks-wont-save-us-from-censorship/
covers the main problems. Do you really want a phone call at 2AM from
a neighbor asking if the network is down?


I've used Radio Mobile and SPLAT!. I never got a warm and fuzzy with
Radio Mobile. Of course, it is a bit more complicated to use SPLAT!.

One obvious advantage to SPLAT! is it can analyze very large areas. Not
all that useful in the case of this wifi setup, but very useful in sigint.