Hacker News Reader

Comment by steven777400 | Hacker News Reader

This isn't a general-audience type of project, but I think we have some pilots on HN so they might be interested. In general, I haven't made a personal tech project (outside of work) in years. So I finally got motivated by scratching my own itch, which is really all that is intended here.

Ever since aviationweather.gov redid their website to be much more feature-full, I've found it very difficult to use on my very slow Android 2 phone with a tiny screen. So I decided what I really wanted was a geo-located METAR/TAF display. "Just the facts", so to speak.

I also added color-coding so that I can easily pick out the bad conditions from the rest of the data.

I wouldn't ever expect this to have a wide audience since every pilot I know also has a late-model iPhone with a variety of aviation apps. But it serves a need for me, and more importantly, it got me back into hobbyist development (at least for a little while).

View on HN

Nice. The color coding seems a bit off (BTW, LOVE the color coding on winds! I fly a tailwheel, so the winds are of great significance to me).

e.g. KGAI 181535Z 29014G20KT 240V310 10SM CLR 18/08 A2974 RMK AO1

shows red, highlighting "0 10SM"

Same for KDAA 181458Z AUTO 31015G24KT 290V360 10SM CLR 20/08 A2970 RMK AO2 SLP060 T02030076 51012

KRSP 181504Z AUTO 32007KT 290V360 10SM BKN026 OVC033 12/07 RMK AO2 $

Well done. I can see this working well for aviation enthusiasts (i.e. X-Plane folks) who like to use real world data. However, METAR/TAF are not the friendliest of formats. Have you considered including a METAR/TAF decoder?

The data that I get from the web service does include a breakdown of the specific conditions (not a human readable translation, but enough to generate one). So far I haven't implemented that since I can read METARs myself. I'd want to be careful not to consume too much screen real estate. Something to think about for sure.

actually, it's really useful just as just a METAR. Prefer it. quick, simple, solves exactly 1 problem well.

For sure. If you're getting your weather data via METAR/TAF, you should be able to read it :). And one can always resort to this (even though it won't decode everything). http://heras-gilsanz.com/manuel/METAR-Decoder.html

Addendum: I did put the "about x minutes/hours" old thing on the data because of all the parts, the Zulu time is the one I consistently do have trouble with. :)

Love it, thanks.

And: showing an "as of" time somewhere, expressed in Zulu, would be helpful.

It's in the METAR and the TAF.

  KPDK 172053Z

17th day 2053 Zulu

Right, per METAR/TAF, but not in terms of when the data was last pulled.

Unless it's all realtime.

The as-of time is in the METAR. It's the block immediately following the station identifier, e.g. 172054Z means the 17th of the month at 20:54 Zulu. That's the time of observation.

You're right that the TAF doesn't indicate the time the forecast was published (although usually it's assumed to be the first hour of the forecast).

If you meant instead, as-of meaning "when the data was loaded", that's true... Not shown. I have the METAR ages turn red when they hit an hour (normally they are issued every hour) as a "clue" to the user to refresh. But certainly I could be more explicit.

> If you meant instead, as-of meaning "when the data was loaded", that's true... Not shown. I have the METAR ages turn red when they hit an hour (normally they are issued every hour) as a "clue" to the user to refresh. But certainly I could be more explicit.

Correct, that's what I'm talking about.

Reply on news.ycombinator.com