Automatically setting the correct units for an individual user is tricky. There’s no such thing as a true “standard” when it comes to weather (especially wind speed!). That’s why we let users select the units they want in the Settings of the Smart Weather app.
But we want to be smarter about setting a user’s default units. This won’t affect any existing users, and you can always override these initial settings. But starting today, when a new account is created in the Smart Weather app, the units will now be automatically set according to user’s country and/or language setting.
The default for most of the world is SI units:
temperature: C
pressure: mbar (this will become hPa once we add that unit)
speed: kph
rain: mm
other distances: appropriate SI unit
all others: SI
We’ve also added the two most whacked out exceptions to the default:
US:
temperature: F
pressure: inHg
speed: mph
rain: inches
other distances: appropriate Imperial unit
all others: Imperial
UK:
temperature: C
pressure: mbar
speed: mph
rain: mm
other distances: appropriate Imperial unit
all others: SI
If your part of the world has an exception to the default, please let us know.
This is a complicated topic in the U.S. So I apologize in advance for the length of this post.
The U.S. units you list above work rather well for radio and TV weather broadcasts, but not so well in other circumstances.
Here is the NWS Station Model where temperature is shown in degrees F, pressure is shown as tenths of millibars (dropping the leading “10” or “9”) and wind speed is shown in nautical miles per hour (knots or kts). See this link for the details ( NWS WPC Station Model ).
And, of course, New York State does its Mesonet stations slightly differently where they list wind speed in miles per hour (mph) and pressure in millibars, but, don’t worry, they switch to metric for soil moisture content.
I am presuming that the WF backend stores the data it receives in exactly the same units that are reported in the UDP packets (which seems to be the only sensible way to do that) so the entire “standard units” question is related to how to display the data for the end users.
For that, I refer you back to my post of 28-January-2018 where I suggested allowing a secondary unit display.
I’m totally like this idea especially the wind direction by degrees and the rainfall rate, I hope I can see these feature in the future.
thank you so much for this idea and for the explanation with pictures.
Regarding the symbol of the unit, in MKSA/SI it’s lx: 1 lx = 1 lm.m⁻² so, to be purely SI, it would be lx or better klx, but kLux is commonly accepted.
visually its a good idea , however as the screenshot clearly shows non metric preferences being the dominant factor where it will get complicated but certainly not impossible and is adding the conversion according to the settings for us not in the USA . lets not forget outside the USA its pretty much metric in most cases . then looking ahead languages . its going to get messy good luck to ever develops and designs this template/ app . working on multiple devices to perfection is going to,push your patience to another level and probably loss of hair will occur so grab a can of beer or two put on some wish you were by pink floyd and hopefully it wont seem so challenging…
nothing is impossible just got to look at all the possible scenarios where the weather data is concerned .
sorry fogot to add you need to squeeze in the dewpoint
examples
gust in dutch =windvlaag (5 extra letters )
rainfall in greek == βροχόπτωση
rainfall in turkish == yağış miktarı two words
dewpoint in norwegian == duggpunkt (9 letters)
just some of the examples when dealing with space on smaller devices
voila …gary languages will drive them nuts i promise …
then you will have the one person who will want the most complex of display configurations and all possibilities and then that will just kill your enthusiasm and you will end rolling a bob marley cigarette and think i didnt sign up for this …t and spend rest of the day more spaced out than neil armstrong ever was … have a nice weekend
i thought it was smart a few years ago a user from denmark was good enough to come up with a simple method to allow language switch on the fly , that was the easy part the real problems came when using languages in something primarily designed for the english language. i recently deleted 14 languages in the template thing i design still have 12 and if i had my way it would be english only going forward… no disrespect to any other language i speak turkish fluently but sometimes it just is incredibly hard to find a design balance due to the various word lengths and grammar
@Weather34 is absolutely right that my example shows what some of my personal (in the U.S.) preferences might be and that the rest of the world has a very large number of alternate preferences regarding words and units. My point was just to start the discussion about how to accommodate the various user preferences and to make full use of the space on the display screens.
And, of course, I am blissfully comfortable sitting here as an armchair developer rather than being the person or team that has the very difficult task of actually building the templates / apps. I sure understand how frustrating it will be. But just looking at what has been accomplished so far in this project I am certain that the WeatherFlow team is up to the challenges they will face in completing and upgrading and enhancing this product line.
Some here have lost site that this is a mass consumer product. I certainly look forward to a more professional product. Between the consumer product and an industrial product.
