What are the "standard" weather parameter units for your locale?

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.

1 Like

If you want to read more about SI units here is a starting place:

https://www.nist.gov/pml/special-publication-811

2 Likes

Hello !
I don’t know if someone already say it, but I think kLux is more “readable” than Lux…

1 Like

That would have to be kilolux. I can’t find anything reference where l is the abbreviation for lux so it would be spelled as a whole word.

I believe that @pierre is referring to dividing the numeric values by 1000, because 5 and 6 digit values are awkward…

I agree that is what he is referring to. I was only commenting on the naming of the UOM. I don’t agree that it is awkward. I prefer the full 6 digits.

This is s example of awkward. Since when is it normal to state amp hours over 2 as mAh?

IMG_20180419_180239

2 Likes

Hi David,

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 ).

51%20PM

And here is the NWS Weather Prediction Center 12-hour Fronts map where the isobars are shown in millibars.

10%20PM

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.

37%20PM

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.

and its attached picture . . .

50%20PM

And . . . I think that is just about enough commentary from me on this topic (for now). Sorry for how long-winded I can get.

7 Likes

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.

Hello!

Yes, that was my point. Sorry if I was unclear.

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

2 Likes

You were perfectly clear.

2 Likes

Let us remember that this system is designed for the 99% of consumers that are not us.

Developers are free to write their own interfaces and at this time we should be begging WeatherFlow to concentrate on production firmware.

5 Likes

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

5 Likes

I agree. I have been fighting that battle and in the last few weeks, I have been removing features from my code.

2 Likes

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

4 Likes

@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.

4 Likes

sometimes you need a sense of humour to get to the other-side :slight_smile:

19

4 Likes

Excellent point! Sometimes it is too easy to forget that the typical users might not be us.

2 Likes

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.

2 Likes

… Holding out for that "Medical Pot Brownie"come Sept. 8th here in Ohio. Until then an a few Oilcans of Fosters will have to do…