On Sunday, February 2, 2020 at 7:54:57 PM UTC-8, Tango Eight wrote:
On Sunday, February 2, 2020 at 9:11:49 PM UTC-5, Darryl Ramm wrote:
On Sunday, February 2, 2020 at 2:26:56 PM UTC-8, Tango Eight wrote:
On Sunday, February 2, 2020 at 4:12:02 PM UTC-5, Darryl Ramm wrote:
Post the actual waypoint data here... it’s just ASCII text. Then we have a chance of seeing what is going on.

Here you go. I created this waypoint about 3 minutes ago. Use whatever tool you like to correlate lat/long/elevation. Actual elevation closer to 1220m....

"Brumley Mountain",,,3650.274N,08206.228W,1091.5m,1,,,,,,

T8

Hi Evan. I was not really asking you for a waypoint. We already discussed this, I hope we both understand why mountainous terrain elevations are likely to not be accurate/disagree like this. I was asking the OP for the waypoints *he* is having problems with. (I see we have a waypoint now, I'll look at that next).

If they are not near vertical discontinuities, or deep vegetation, then differences might be expected. Otherwise maybe it's somethingÂ*corruptedÂ*in his SeeYou, or some bad data in that area, or... and if so something Naviter support should see.

But for those playing along at home. ThatÂ*Brumley Mountain waypoint as already pointed out is hanging off a fairly steep side of the mountain I it should not be a surprise that SeeYou and Google Earth or pick any other (random tools) produce different data. You have to think about where the data comes from and what it is showing.

For the USA I believe Google Maps and Google Earth uses USGS DEMS high resolution LIDAR data sets, with few m lateral resolution. SeeYou used to use the ~global 30m (or 60m?) lateral resolution NASA Shuttle C-band Synthetic Aperture Radar datasets with global coverage, and I suspect they still do, I'd be surprised if Naviter added DEMS data for the USA. (Who wants to buy Andrej beer at the SSA convention to try to get DEMS support for the USA?)

I expect resolution effects here of scale 30m/60m laterally can significantly affect reported altitudes. And when working in SeeYou on Windows you also want to be careful because some of the charts do not resolve sharp features well and it might be possible to place stuff a bit off. But the other critical question is likely vegetation. Do you want to count elevation of the ground surface or of the top of forrest vegetation? What do the software programs and their data sources mean by elevation? The answer there is probably "uh?" :-) The LIDAR data is affected by vegetation more than the C-band data but they try to factor out vegetation, by that may not alway be accurate. (Folks actually measure forrest heights from the difference of LIDAR and C-Band SAR). So where this is critical you better be clear what you mean, and find a way to validate you have an accurate elevation..

For thatÂ*Â*Brumley Mountain waypoint

3,887'Â* Â*Google EarthÂ*7.3.2.5776 (Mac):
3,581'Â* SeeYou (Windows) 10.32Â* Â* Â* Â* Â* :
-----
306' difference
-----

It takes displacing the google Earth waypoint about 180m laterally "down hill" to reach that reported SeeYou elevation. That's not unreasonable given the 30/60 meter resolution, and possible vegetation effects would mean less displacement is needed.

If I drop a way point more up on that flat top of the hill at N36°50.220' W082°05.696'. Google Earth and See You agree more.

3994'Â* Â*Google EarthÂ*7.3.2.5776 (Mac)
3855'Â* Â*SeeYou (Windows) 10.32
-----
139' difference.Â*
-----

I am going to guess a good part of that of that is vegetation effect.Â*

The counter example is to pick locations that have no vegetation and are roughly flat at few x 30m/60m scale and compare them. The easy pick there is airport runways. When I compare the runway intersection at Patrick AFB, FL I get 6 or so feetÂ*+/- few feet. OK that's sea level, so going higher, the runway intersection at Cedar City Airport, UT is 5,999Â*+/- a few feet in either tool. Pretty amazing precision. (Ah memories of irritating a Cedar City tower controller one day and him making me push my DG-303 all the to the end of Runway 8, in the stinking heat. Grrr).

Anyhow precision altitude alway needs to be hand curated, it's great when that is well done. Like when boulder outcrops or mountain top forestry fire lookouts are within feet of the shown elevation on the altimeter. Landing locations are usually relatively easy.

Excuses, excuses! This worked much better at about version 4. That was my point. The elevation data served by the SeeYou cloud is relative crap. Very coarse. Probably a good decision on Naviter's part. "Hey, we can save a ton of money on bandwidth, only a couple of ridge soaring pilots will ever notice.
If they do complain, we can probably rely on their buddies to tell them they are being too demanding" :-).

best,
Evan

I gather your team lost :-)

It was not that long ago that the 30m NASA shuttle C-band SAR data looked frigging amazing. We are so spoilt.

And like I said Andrej is probably open to a beer or few.... I won't be at the SSA convention but he will and I can't be the only glider pilot who likes beer and SeeYou.