SeeYou incorrect waypoint altitudes

On Sunday, February 2, 2020 at 5:26:56 PM UTC-5, 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

The elevation data built into the map that is within SeeYou is only approximate, as it is presumably based on a "grid elevation model" with limited resolution. The more varied (mountaneous) the local topography, the more inaccurate it would be, since those grid points are farther apart than the actual local slopes. I always enter waypoint elevations "manually", from other sources.

On Sunday, February 2, 2020 at 5:35:27 PM UTC-8, wrote:
On Sunday, February 2, 2020 at 5:26:56 PM UTC-5, 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

The elevation data built into the map that is within SeeYou is only approximate, as it is presumably based on a "grid elevation model" with limited resolution. The more varied (mountaneous) the local topography, the more inaccurate it would be, since those grid points are farther apart than the actual local slopes. I always enter waypoint elevations "manually", from other sources.



Cool thanks, that's basically the answer i thought i would get. Pretty much "enter your elevations manually"

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.

On Sunday, February 2, 2020 at 5:26:08 PM UTC-8, soaringjac wrote:
On Sunday, February 2, 2020 at 1:12:02 PM UTC-8, 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 is the waypoint
"Baden-Powell",Badenell,,3421.517N,11745.883W,2631.6m,1,, ,,,,,

actual altitude is about 2865 meters

There is nothing specific about this waypoint, so it really does not matter. Just click around the map in SeeYou and add some random waypoints and then compare to google earth altitudes

Yep you can't do that. The top of that mountain itself is barely the size of a single resolution grid in the NASA SAR data. We could have gotten straight here earlier...

9407' Google Earth 7.3.2.5776 (Mac) (also the official USGS height of the peak).
8634' SeeYou 10.32 (Windows)
-----
773' difference
-----

And the hight resolution Google earth data shows a higher elevation that SeeYou as expected.

Move off the sides a couple of hundred meters and you are at the elevation shown by SeeYou. A bit more that I might expect but that is damn steep terrain.

You really should be using the exact other turnpoint data that other local pilots are using from the Soaring Turnpoint Exchange, it's easy to remove extra turnpoints if you really have to. You don't want any possibility of confusion about location of a turnpoint if talking to nearby gliders. For other peaks I would always try to use the USGS official peak location and elevation data... glider pilots sometimes have amusing habits of creating their own names for less significant mountain peaks (how many "Black Mountains" do I know?).

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

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.

On Sun, 02 Feb 2020 16:52:59 -0800, Tango Eight wrote:

It's a ridge route. If you've done any flying of that sort, it'll make
sense. If you haven't... look at the the topo and do the thought
experiment.

Very little, and that was on steeper, more defined ridges - the ridge
north of Omarama and on the Pennines under Cross Fell. I take your point
about marking the start of a ridge climb.

https://viewer.nationalmap.gov/basic/?
basemap=b1&category=nbd,ned,nedsrc,histtopo,nhd,na ip,nbdmi,gnis,smallscale,nsd,vectorcmb,ntd,ustopo, woodland&q=&zoom=12&bbox=-82.25360870,36.76584198,-81.94805145,36.91201927&preview=&avail=&refpoly=

FWIW GoogleEarth can give rather good topographic views if you move off a
bit (1km or so) and then zoom right in, almost to the point where it
wants to switch to streetview. Then moving your viewpoint around lets you
easily pick out high points, ridgelines, etc.


--
Martin | martin at
Gregorie | gregorie dot org

I have create and fixed several turnpoint lists. It is is amazing to see when some people quickly add turnpoints they leave the altitude at O MSL!!!
I scan for this first thing when I redo a list. That could really cause someone to hit the dirt thousands of feet earlier than they thought going to a point.
Chris