Data issue with ground elevation about ppg.report

[ooglek]

@aeharding The reason is that NOAA reports the forecasts based on grid points.

While the forecasts are useful, when entering an address or coordinates, NOAA will select the closest grid point and return the forecast for that place.

The problem is when you're in the mountains! I learned this the hard way. KHSP (Ingalls Field Airport) in Hot Springs, VA is the highest altitude airport east of the Mississippi at 3,792.7 feet MSL.

NOAA will return a gridpoint for this airport at 37.89,-79.64, which is 9.9 nautical miles to the ESE, at an elevation of 1,814 feet MSL..

(RyanCarlton.com which uses the same data discloses the Grid point coordinates in the upper right corner of the site.)

My flight from KHSP lasted 6 terrifying and turbulent minutes due to my reading of the forecasted airspeed as flyable but at what was actually an impossible altitude.

There's a few things you could do here.

1. Use Google or another geo API to determine the actual altitude at the actual address/airport requested. Tough to do with just a city name or zip code, but you could put in some accuracy information somewhere in there. Then adjust the closest grid point's altitude accordingly.
2. Fully disclose that the forecast is for a point that is how many miles away and in what cardinal direction. Let people switch between the 4 surrounding grid points from their selected location, so they can do their own averaging.
3. Consider that most weather in the world moves west to east, and maybe there are ways to decide which gridpoint you'll use for a given address.
4. Do your own magical averaging of the 4 grid points surrounding a requested location, weighted by distance from the location.

[aeharding]

@ooglek I've deployed this in release v3.0.0, so I'm closing this issue. Please feel free to open another issue if there's additional tweaks/ideas to make this better!

[aeharding]

That's because it's a Progressive Web App and is available offline, so it's cached on your device.

If you close all tabs of the app (or if installed to homescreen - close the app by swiping up in the application switcher or restart device) it will update.

Most people won't notice and it updates after a few days :)

[ooglek]

Also, HOLY CRAP!!! The Metadata thing is AMAZING! It looks like one of my sites, KHWY, is right on the northern border of the gridpoint. EXCELLENT visualization and super useful!!!

[aeharding]

Hey there @ooglek!

I agree that this problem is worth addressing.

Regarding your points-

1. I've been looking at APIs I could use. One possibility is https://nationalmap.gov/epqs/pqs.php?x=-111.051%20&y=45.685&units=Feet&output=json since it's a government API it's free. I could potentially fall back to Google's API, but I generally try to steer clear of giving large corporations free data. :-)
2. This one makes a ton of sense, and should be easy to do. The grid point switching might be more difficult.
3. This is a good idea, but could make the reports worse in certain edge cases.
4. This would be fun! However it would require a bunch of work, especially because the altitudes provided per point may be completely different and/or completely absent.

So in conclusion, I think I will try to implement an altitude API, and I'll disclose the location point distance & direction.

[aeharding]

@ooglek What do you think about something like this for the forecast point disclosure?

It also links to the point forecast location when tapped.

[aeharding]

@ooglek one more question for you. I've implemented altitude compensation in some code locally. For your location, would you find it helpful to show negative altitudes (AGL)? Or would you think it would be best to hide them?

I was thinking hide them for when in AGL mode, but when you switch to MSL mode (by clicking the altitude header) I'll show everything.

Let me know, and I'll deploy this to beta.ppg.report! I'd REALLY appreciate some testing, preferably over a few months to make sure that this displays data in a useful way and there's no ramifications to processing the data this way. :)

[ooglek]

Altitude API -- great! I think having some disclosure about what "surface" is considered, or state "0 feet AGL" or allow a person to select MSL would be good. Knowing that the location selected and the forecast are also not in the same place I think is important.

"Winds aloft forecast gridpoint is 6.5mi East" -- use the NOAA terminology so someone can google that. Maybe include an informational (i) popup that links to maybe a ppg.report blog post about how NOAA forecasts work and why the forecast might not be exactly right for any specific point.

Hmmm I follow the question on negative AGL altitudes. You seem to have two options -- move to MSL for everything, so there are no negatives, and insert a "SURFACE" horizontal line amid the forecast rows, and anything below is simply grayed out but still visible. The other option is to go negative for AGL. I still think a "---SURFACE---" line could help someone understand more intuitively. Doesn't need to be big and prominent.

I prefer MSL personally, but I also understand the value of AGL. Maybe MSL for everything and put a light gray value beneath with "1,103 ft" as the AGL for the point.

It's tough either way! You do a great job with UI though, so I trust your final judgment.

[aeharding]

Thanks for the feedback! I've recently deployed various tweaks and fixes for this. I decided to do away with the footer of jumbled information and go with a dedicated page. Please see the below screenshot and you can access at https://beta.ppg.report. And let me know what you think.

[ooglek]

Wicked! Thanks!!!

[ooglek]

Strange issue -- if I go to https://ppg.report/ in Google Chrome on IOS, I see v3.0.3
If I use the safari app link I made, or load in Safari, I see v2.1.4
Are you testing? Or is that expected? I'm curious!

[ooglek]

Yep, unloading and reloading the Safari App fixed it. Nice! Didn't realize it cached the full app, but that makes sense. Excellent work, Alexander!