wttr.in
wttr.in copied to clipboard
feature requests for aviators and sailors
Thanks for the great tool! Fondly appreciate.
A "nice to have" would be, when ICAO codes of airports would be entered, the METAR code would be placed additionally, like @metar on twitter.
Further for sailors additional sailing related information details would be helpful. (e.g. beaufort scale value, water temperature.)
Beaufort scale is already on our todo list (#231). We have support for IATA codes; we could add support of ICAO too (in two words, what is the difference, advantage or disadvantage between them?).
METAR sounds interesting. How would a response from the wttr.in service look like in this case?
Let's say it is METAR for format.
$ curl wttr.in/Amsterdam?format=METAR
???
How looks the output?
Oh, nice, sorry I missed #231 .
IATA is for ground and ICAO for "airborne" users ;) ICAO has a great logic in letter codes, which makes a lot of sense (regions > subnational regions > cities). e.g. VTBS: V for South-East Asia Region, T for Thailand, B for Bangkok, S for Suvranabhumi.
METAR and TAF are weather codes that are easily readable, e.g. "VTBS 282100Z VRB02KT 9999 FEW020 28/24 Q1009 NOSIG" which decrypts into VTBS ICAO code 281200Z 28th day of the month, 12:00 zulu time (UTC) VRB02KT winds variable 2 knots 9999 visibility 9999 meter (max) FEW020 few clouds on 2000 feet 28/24 temperature 28 degrees celcius, dewpoint 24 degrees celcius Q1009 air pressure 1009 hPa NOSIG no significant change
METAR is current weather on the specified time, whereas TAF is the forecast.
IMHO, ideally the command could look like
$ curl wttr.in/VTBS?format=METAR
or
$ curl wttr.in/VTBS?format=TAF
Thank you
Thank you for clarification; it is a little bit better now :)
I think we need to split the issue into two (or three):
- ICAO support
- METAR/TAF support
ICAO
wttr.in already has some initial support of ICAO, I've just taken some random ICAO codes, and all of them seem to resolve correctly:
curl wttr.in/URKK
curl wttr.in/UWWW
curl wttr.in/VABM
curl wttr.in/UKLL
curl wttr.in/VTBS
Maybe we need some additional, more reliable support, to be sure that all ICAO codes are guaranteed to resolve correctly,
- maybe we need some name format/prefix for ICAO, to specify explicitly that is ICAO for some disambiguite cases
Maybe wttr.in/ICAO:VTBS
?
Or 4-Letters-Uppercase is always ICAO?
METAR
I think, we definitely need to add METAR support, the question is:
- Should we provide the same data as wttr.in provides (use the primary source for METAR too);
- Provide some publicly available METAR data, say https://www.aviationweather.gov/metar
- Make it configurable
What do you think?
Also, because METAR is international and shouldn't be translated into different languages anyway, we could use it as part of the domain name (as we do know for the languages):
curl metar.wttr.in/VTBS
Could a simple conversion be a solution? Something like this (I'm not confident enough that there's no mistakes, so that's why I didnt dare to do a pull request):
if query.get('use_ms_for_wind', False):
unit = 'm/s'
wind = u'%s%.1f%s' % (wind_direction, float(data['windspeedKmph'])/3.6, unit)
elif query.get('use_knots', False):
unit = 'knots'
wind = u'%s%.1f%s' % (wind_direction, float(data['windspeedKmph'])/1.852, unit)
elif query.get('use_imperial', False):
unit = 'mph'
wind = u'%s%s%s' % (wind_direction, data['windspeedMiles'], unit)
else:
unit = 'km/h'
wind = u'%s%s%s' % (wind_direction, data['windspeedKmph'], unit)
return wind
@heesters Yes, I think it could be a good solution; maybe not for this issue but for other related issues (we have a lot of them): #7, #343 etc
@juli let's discribe our feature request here in details, or create a new issue if this is a bad one
Part of the feature is understanding what info sailors need and the second part of the feature is compressing that info in blocks of 140 chars. METAR sounds like a good start. From GPS coordinates as input it would return weather forecast for an area including wind for the following days with 1-3 hours time resolution. First diffence with the format described above that I see is that instead of ICAO codes the area shuold be expressed relative to the position of the user requesting it.
@juli Also, a coupld of other things that we discussed: I'll put it here to share with other & not forget about it:
- SMTP support
- Text output format