Wind Direction

[towndock]

The wind direction icons are 180 degrees off. It is understandable - unless you are a sailor you wouldn't know.

A south wind means the wind is coming from the south(pointing south), not blowing in a southerly direction.A northwest wind means the wind is coming from the northwest, not blowing in a northwest direction.

Etc - through all the wind direction icons.

Thank you. These are sweet icons.

[erikflowers]

I am pretty sure another issue said the opposite and I changed then 180 degrees from how they started.

Maybe they just need an alias for each ".blowing-north, .from-the-north".

I don't actually know what the proper usage is.

This one: https://github.com/erikflowers/weather-icons/issues/4

Looking at them again, I have the "south wind" pointing north - the direction of the wind. Are you saying that a sailor would want a "south wind" icon to point south?

[towndock]

Erik,

Thank you so much for the response.

I promise you - north means winds from the north. You were right initially. You shouldn’t have to change to different descriptions - this is what wind descriptions have meant for centuries.

Example:

http://towndock.net/weather/pamlico-sound-marine-weather-forecast

OK - the above is my site. We have done marine weather for over a decade.

Here is a slightly larger company showing the same - Weather Underground (owned by the Weather Channel).

http://www.wunderground.com/weather-forecast/US/NY/New_York.html

If you don’t change them - it’s OK. I can just make my server look for the right ones. But they are 180.

Again, thank you.

Keith

On Nov 2, 2014, at 6:25 PM, Erik Flowers notifications@github.com wrote:

I am pretty sure another issue said the opposite and I changed then 180 degrees from how they started.

Maybe they just need an alias for each ".blowing-north, .from-the-north".

I don't actually know what the proper usage is.

— Reply to this email directly or view it on GitHub https://github.com/erikflowers/weather-icons/issues/41#issuecomment-61429051.

[erikflowers]

Should the arrows point to the center of the circle?

I need to know what the metaphor is. If it's like a boat is the center dot, then the arrow points to the boat, so that the arrow itself is at the South-West position (22:30 oclock) but pointing down and to the right (4:30)?

[towndock]

I don't think so. The arrow appearance really is fine now.

[towndock]

While we are talking wind direction icons - there is one more thing. Some forecasts are beginning to include more specific wind direction info. As in NNE (north-north-east) which is in between north and northeast, or ENE (east-north-east) which is in between northeast and east.

Basically, 16 wind direction icons instead of 8.

[erikflowers]

This sounds like a job for CSS3 rotate transforms then. 1 icon broken into maybe 36 10 degree transforms. Unless people are targeting browsers that can’t do the transforms, feels like having that many icons should be a fix ike wi.wi-wind.wind-90 with 90 being the degree’s away from 0, so 0 would point to the right, and 90 to the top.

The backlog on work on this project is long… I never really expected it to go anywhere =) 

From: towndock notifications@github.com Reply: erikflowers/weather-icons reply@reply.github.com> Date: November 2, 2014 at 3:56:07 PM To: erikflowers/weather-icons weather-icons@noreply.github.com> Cc: Erik Flowers erik@helloerik.com> Subject:  Re: [weather-icons] Wind Direction (#41)

While we are talking wind direction icons - there is one more thing. Some forecasts are beginning to include more specific wind direction info. As in NNE (north-north-east) which is in between north and northeast, or ENE (east-north-east) which is in between northeast and east.

— Reply to this email directly or view it on GitHub.

[towndock]

I understand. I'll look up how to use CSS rotate transform in the meantime. Thank you sincerely for listening to my requests.

[erikflowers]

Oh that’s not a problem, that’s just adding .rotation((@variable)deg); into classes and giving them the names. It’s something that can be done right now in fact without me needing to crack open the font file (which is slow), I could just add it to the Less and update the repo. Or, you could give it a try as well just to see what happens.

From: towndock notifications@github.com Reply: erikflowers/weather-icons reply@reply.github.com> Date: November 2, 2014 at 4:46:36 PM To: erikflowers/weather-icons weather-icons@noreply.github.com> Cc: Erik Flowers erik@helloerik.com> Subject:  Re: [weather-icons] Wind Direction (#41)

I understand. I'll look up how to use CSS rotate transform in the meantime. Thank you sincerely for listening to my requests.

— Reply to this email directly or view it on GitHub.

[erikflowers]

This does it, example:

transform: rotate(234deg);

just need to make it the less mixin. This is a really good idea. So thanks for bringing it up. 

And lucky for me - the circle is actually perfectly centered, so the arrow spins without messing with the circles central point. I would never have actually paid attention to the circle being perfectly centered ;)

From: Erik Flowers erik@helloerik.com Reply: Erik Flowers erik@helloerik.com> Date: November 2, 2014 at 4:50:02 PM To: erikflowers/weather-icons reply@reply.github.com> Subject:  Re: [weather-icons] Wind Direction (#41)

Oh that’s not a problem, that’s just adding .rotation((@variable)deg); into classes and giving them the names. It’s something that can be done right now in fact without me needing to crack open the font file (which is slow), I could just add it to the Less and update the repo. Or, you could give it a try as well just to see what happens.

From: towndock notifications@github.com Reply: erikflowers/weather-icons reply@reply.github.com> Date: November 2, 2014 at 4:46:36 PM To: erikflowers/weather-icons weather-icons@noreply.github.com> Cc: Erik Flowers erik@helloerik.com> Subject:  Re: [weather-icons] Wind Direction (#41)

I understand. I'll look up how to use CSS rotate transform in the meantime. Thank you sincerely for listening to my requests.

— Reply to this email directly or view it on GitHub.

[erikflowers]

This is changed. See the link below for details. It is now using a rotated icon in 15 degree increments, and there is no cardinal direction declared so people can use them however they want (towards the wind or with the wind).

https://github.com/erikflowers/weather-icons/issues/19

[towndock]

Well done - thank you.

On Nov 30, 2014, at 7:38 PM, Erik Flowers notifications@github.com wrote:

This is changed. See the link below for details. It is now using a rotated icon in 15 degree increments, and there is no cardinal direction declared so people can use them however they want (towards the wind or with the wind).

19 https://github.com/erikflowers/weather-icons/issues/19

— Reply to this email directly or view it on GitHub https://github.com/erikflowers/weather-icons/issues/41#issuecomment-65008069.

[deanishe]

Is there any chance of reversing the arrows' direction by default?

Literally every other weather app has the arrow pointing with the wind, not where it's coming from.

As things stand, I have to override all the wind direction classes to get the expected behaviour (i.e. the arrow points where the wind is blowing, not where it's coming from).

It's not a huge deal, but it's something most users are probably going to have to do.

[erikflowers]

The wind icons were all changes to just point in 15 degree increments to get rid of the confusion. There was an argument over how wind icons should point. A northern wind blows south and wound point south. So a down arrow. Many people reported that it felt like that was a representation of "south". So now, a north wind or southern compass is just 

wi-wind-default _180-deg

On July 26, 2015 at 8:41:32 AM PDT, Dean Jackson notifications@github.com wrote:Is there any chance of reversing the arrows' direction by default? Literally every other weather app has the arrow pointing with the wind, not where it's coming from. As things stand, I have to override all the wind direction classes to get the expected behaviour (i.e. the arrow points where the wind is blowing, not where it's coming from). It's not a huge deal, but it's something most users are probably going to have to do. —Reply to this email directly or view it on GitHub.

[deanishe]

I understand what was done and why, but it doesn't reduce confusion in any way.

Whether the source of the wind is specified in degrees or as NNW, SE etc. (and all APIs specify the direction the wind is coming from because that's how it's done) is not the problem.

It's rather that the default is for the arrow to point towards the source of the wind, which is very unusual. I've never seen a single application that does it that way. At least not a professional one.

However the classes are named, I strongly believe it would be much better behaviour for the arrows to point in the opposite direction by default because that's how pretty much everyone does it. At least in the context of weather.

If people are using the icons to show compass directions, then they're set up the right way now. But the font is nominally for weather applications, where every man and his dog does it the other way around.

In short, this lib does it the other way round to everyone else.

[towndock]

Dean, I beg to differ. Erik has it right. A weather wind symbol pointing north - means wind coming from the north. It has for centuries. The symbol emulates a wind indicator. Ever seen one on a boat or house? It points into the wind - that is how it works.

Any recent 180 switch on that in apps is due to programmers knowing about code, but not knowing about wind & weather.

On Jul 26, 2015, at 2:35 PM, Dean Jackson notifications@github.com wrote:

I understand what was done and why, but it doesn't reduce confusion in any way.

Whether the source of the wind is specified in degrees or as NNW, SE etc. (and all APIs specify the direction the wind is coming from because that's how it's done) is not the problem.

It's rather that the default is for the arrow to point towards the source of the wind, which is very unusual. I've never seen a single application that does it that way. At least not a professional one.

However the classes are named, I strongly believe it would be much better behaviour for the arrows to point in the opposite direction by default because that's how pretty much everyone does it. At least in the context of weather.

If people are using the icons to show compass directions, then they're set up the right way now. But the font is nominally for weather applications, where every man and his dog does it the other way around.

— Reply to this email directly or view it on GitHub https://github.com/erikflowers/weather-icons/issues/41#issuecomment-125025845.

[erikflowers]

Are you looking at an old version? Wind names were removed regardless, it is all just 15 degree increments, no names. I did this in response to feedback, people got confused either way. There are closed issues on it. So I'd prefer to leave them without Cardinal direction names and come up with a better idea for 2.0. 

On July 26, 2015 at 11:35:43 AM PDT, Dean Jackson notifications@github.com wrote:I understand what was done and why, but it doesn't reduce confusion in any way. Whether the source of the wind is specified in degrees or as NNW, SE etc. (and all APIs specify the direction the wind is coming from because that's how it's done) is not the problem. It's rather that the default is for the arrow to point towards the source of the wind, which is very unusual. I've never seen a single application that does it that way. At least not a professional one. However the classes are named, I strongly believe it would be much better behaviour for the arrows to point in the opposite direction by default because that's how pretty much everyone does it. At least in the context of weather. If people are using the icons to show compass directions, then they're set up the right way now. But the font is nominally for weather applications, where every man and his dog does it the other way around. —Reply to this email directly or view it on GitHub.

[deanishe]

I'm using the latest version with the numbered classes.

The point I'm trying to make is that, by default, the arrows point in the wrong direction for weather data, and weather is what the font is supposed to be for.

If I pull the wind direction from an API or data files, 90 degrees means the wind is blowing from 90 degrees towards 270 degrees. The icon named 90-deg points in the opposite direction, however.

As things stand, if I'm using weather data with the weather font, I have to either rewrite/remap the CSS classes or reverse the API data because the icons are all pointing in the opposite direction. That strikes me as the wrong behaviour when using icons nominally designed for weather purposes.

I appreciate that confusion will arise either way, but I believe that with a font designed for weather purposes, the correct behaviour would be for the arrow named "90-deg" to correspond to the direction of a 90-deg wind, not point in the opposite direction.

This makes it so much easier to use with weather data.

For v2, I would suggest using weather-data-appropriate defaults (i.e. the opposite of the current behaviour) and add a different set of wi-compass_N-deg classes that behave the way the current icons do.

That would make the icons with class wind behave as expected with wind data and icons with class compass behave like as expected with compass bearings.

Similarly, I'd consider splitting the moon-phase icons into separate dark and light classes, which are the inverse of each other, as they can be misleading depending on whether you're using light-on-dark or dark-on-light text, as noted in issue #72.

Anyway, minor gripes apart, the font is bloody amazing. Thanks very much for a very helpful resource.

[erikflowers]

I see what you mean. These are all good ideas for v2.  V2 is just getting so big I have no idea when I'm going to work it all out. Open source labor of love. 

On July 26, 2015 at 2:32:11 PM PDT, Dean Jackson notifications@github.com wrote:I'm using the latest version with the numbered classes. The point I'm trying to make is that, by default, the arrows point in the wrong direction for weather data, and weather is what the font is supposed to be for. If I pull the wind direction from an API or data files, 90 degrees means the wind is blowing from 90 degrees towards 270 degrees. The icon named 90-deg points in the opposite direction, however. As things stand, if I'm using weather data with the weather font, I have to either rewrite/remap the CSS classes or reverse the API data because the icons are all pointing in the opposite direction. That strikes me as the wrong behaviour when using icons nominally designed for weather purposes. I appreciate that confusion will arise either way, but I believe that with a font designed for weather purposes, the correct behaviour would be for the arrow named "90-deg" to correspond to the direction of a 90-deg wind, not point in the opposite direction. This makes it so much easier to use with weather data. For v2, I would suggest using weather-data-appropriate defaults (i.e. the opposite of the current behaviour) and add a different set of wi-compass_N-deg classes that behave the way the current icons do. That would make the icons with class wind behave as expected with wind data and icons with class compass behave like as expected with compass bearings. Similarly, I'd consider the moon-phase icons into separate dark and light classes, which are the inverse of each other, as they can be misleading depending on whether you're using light-on-dark or dark-on-light text, as noted in #72. Anyway, minor gripes apart, the font is bloody amazing. Thanks very much for a very helpful resource. —Reply to this email directly or view it on GitHub.

[deanishe]

I feel your pain :cry:

I'm faced with a similar problem with my only project of note, but yours is an order of magnitude or two bigger.

I'm going to try to make v2 as pluggable as possible, so I can (hopefully) tell folks to write a plugin to override whatever they don't like (and then I'll ask them to contribute them back to the main repo).

Using CSS transforms for the arrows was a genius idea. Thanks to your clever design, I can make 360 CSS classes — one for every point of the compass — with a couple of dozen lines of Python.

I'm wondering if you could use a bit of scripting to generate a lot of your css/less/sass files.

Maybe you already are, but there's no indication of that in the repo.

[erikflowers]

I didn’t know how to run a repo, project, or web css font before this, so it’s all a mess. The repo you see publicly isn’t the one I build, that’s just the hand-moved files that are “cleaned up” for public use. I need to actually stop having 2 repos and just do it all there. And I need to use what I’ve learned to clean up the whole process. 

The Less is compiled in CodeKit. It needs to have a Sass version now too since Bootstrap 4 will be in Sass. And the way I build the index.html page and cheatsheet (For copy and paste into graphics apps) is all manual and a huge pain. The technical debt on weathericons is steep… 

I don’t have any real programming skill or education, so people have offered to help automate some of the stuff, i.e. taking all the icon classes and outputting the HTML examples page etc - but I have no way to maintain or edit/fix that myself, so it would leave me stuck. 

It’s getting so much use I need to just take a day off work and fix it all. My biggest fear, though, is that I am 99% certain that making a 2.0 branch and then merging it into the master is going to break the bower and cdn.js, going to break the tags, and break anyone who is pulling right from the repo into their projects, since I don’t know how that stuff all interconnects, it was all submitted by other users via pull requests.

Soon, though. I was shocked to see the last real update was January, I had sworn it was more recent.

On July 26, 2015 at 5:24:19 PM, Dean Jackson (notifications@github.com) wrote:

I feel your pain :sad:

I'm faced with a similar problem with my only project of note, but yours is an order of magnitude or two bigger.

I'm going to try to make v2 as pluggable as possible, so I can (hopefully) tell folks to write a plugin to override whatever they don't like (and then I'll ask them to contribute them back to the main repo).

Using CSS transforms for the arrows was a genius idea. Thanks to your clever design, I can make 360 CSS classes — one for every point of the compass — with a couple of dozen lines of Python.

I'm wondering if you could use a bit of scripting to generate a lot of your css/less/sass files.

Maybe you already are, but there's no indication of that in the repo.

— Reply to this email directly or view it on GitHub.

[deanishe]

Honestly, you don't need to worry about that stuff too much. Anyone pulling directly from a repo expects stuff to break occasionally (unless they're pulling from a specific commit), especially if you bump the tag from 1.x to 2.x. You just have to be sure to keep the README and other docs up to date.

Your project has >100 watchers and 2.5k stars. There is a huge number of people out there who will step up to help with any "technical" stuff. If your chosen coder buggers off, there will be another several dozen ready to step up and help you with that stuff.

This is a coders' site. Many of us can write scripts till the cows come home, but couldn't design our way out of a paper bag if our lives depended on it. I guarantee that you will receive any code-related help you need 10x over.

Issues go in both directions. If you want some feedback, open an issue with a question/request. Hella people will see it (because your project is awesome and has a lot of fans).

[erikflowers]

To anyone following this:

I am currently testing a way to generate 360 classes of 1 degree each. They would be named

.point-36-deg {stuff}

this way, no matter who you are, you can decide. Prefer your west arrow to face left as in "blowing to the west from the east"? then it's 270-deg. If you prefer it to face right as in "blowing from the west to the east", 90-deg.

This would be an option. Then whoever wanted to code it could just decide which degree they want the point of the arrow on. It would be semantic "This arrow points to 0 degrees", which is straight up.

I could also add "towards" and "from" as aliases for the 16 cardinal direction variations.

[deanishe]

Once again, I must stress the utility of having a set of classes where the arrows point away from the specified point of the compass. This is how weather data works, and it lets you plug weather data straight into the classes without having to transform every value. When the weather data says windBearing = 270, I want to be able to use a class called 270, not adjust everything by 180.

This is the code (more or less) I used to generate 360 classes. I actually generated SCSS, so I defined a mixin in HEADER and included that in each definition. I've altered it to generate stock CSS.

HEADER = """\
"""

TPL_TRANSFORM = """\
  -webkit-transform: rotate({deg}deg);
  -moz-transform: rotate({deg}deg);
  -ms-transform: rotate({deg}deg);
  -o-transform: rotate({deg}deg);
  transform: rotate({deg}deg);"""

TPL_CLASS = """\
.wi-wind-default.{prefix}{name}-degrees {{
{css}
}}
"""

def arrow_css(offset=0, class_prefix='towards-'):

    output = [HEADER]

    for i in range(0, 361):
        j = (i+offset) % 360
        if j == 0:  # No transform
            css = ''
        else:
            css = TPL_TRANSFORM.format(deg=j)
        output.append(TPL_CLASS.format(prefix=class_prefix, name=i, css=css))

    return('\n'.join(output))

# Arrows pointing *towards* the specified compass point
# i.e. 0-degrees points upwards
print(arrow_css())

# Arrows pointing *away from* the specified compass point
# i.e. 0-degrees points downwards
print(arrow_css(180, 'from-'))

The output looks something like this (classes with 0 transform are empty):

.wi-wind-default.towards-0-degrees {

}

.wi-wind-default.towards-1-degrees {
  -webkit-transform: rotate(1deg);
  -moz-transform: rotate(1deg);
  -ms-transform: rotate(1deg);
  -o-transform: rotate(1deg);
  transform: rotate(1deg);
}

.wi-wind-default.towards-2-degrees {
  -webkit-transform: rotate(2deg);
  -moz-transform: rotate(2deg);
  -ms-transform: rotate(2deg);
  -o-transform: rotate(2deg);
  transform: rotate(2deg);
}

…

.wi-wind-default.from-358-degrees {
  -webkit-transform: rotate(178deg);
  -moz-transform: rotate(178deg);
  -ms-transform: rotate(178deg);
  -o-transform: rotate(178deg);
  transform: rotate(178deg);
}

.wi-wind-default.from-359-degrees {
  -webkit-transform: rotate(179deg);
  -moz-transform: rotate(179deg);
  -ms-transform: rotate(179deg);
  -o-transform: rotate(179deg);
  transform: rotate(179deg);
}

.wi-wind-default.from-360-degrees {
  -webkit-transform: rotate(180deg);
  -moz-transform: rotate(180deg);
  -ms-transform: rotate(180deg);
  -o-transform: rotate(180deg);
  transform: rotate(180deg);
}

[erikflowers]

I've done away with any naming outside of the towards/form and the degree. I have all 360x2 in there, but in the example I am just showing 32, that correspond with N, NNW, NW, WNW etc etc... roughly 22.5 degrees each tick.

Having 1 degree increments ends up being 5000 lines in the CSS file, so I am going to think on that and if it should be maybe cut by 5x, so instead of 360 ticks there would be 72. I don't really know a use case for such fine control over direction, all I have ever seen in weather or meteorology was N, NW, SSW, SE etc etc.

But as you can see, you have the major 16 directions here that go towards, then from.

[deanishe]

I don't really know a use case for such fine control over direction

Like I've been saying: plugging data returned by APIs/read from weather data directly into the CSS classes.

If there are 361 classes (including 0 and 360), I can simply pass the value I get from the weather data straight into a weather-icons CSS class without having to dick around figuring out which is the closest CSS class supported by weather-icons.

I understand from your comments that you're not a master coder yourself, so I imagine you can see the utility in that.

all I have ever seen in weather or meteorology was N, NW, SSW, SE etc etc.

That's because you've been reading the output at the UI level, not the input from the API.

Have a look at the data provided by common weather APIs:

• openweathermap.org
• Yahoo!
• forecast.io
• MET Office (UK)
• wunderground.com
• myweather2.com

Providing wind direction as N, NE, SSW etc. is the exception. Only myweather2.com provides the wind only in that format, and only wunderground.com provides N/NW/SSW etc. in addition to specifying a numerical compass-point direction (all of which mean the wind is coming from that direction, and thus is "pointing" in the opposite direction to where the weather-icons wind icons point by default).

APIs are aimed at programmers, and we prefer numbers to text. So most APIs provide numbers where they make sense. If I have a number, I can convert it to text relatively easily, and in as many languages as I want. If I have text, I often first have to turn it back into a number if I want to, taking a weather-related example, compute some "rain danger" value based on probability of rain and expected intensity.

In this particular case, if there are only text-based directions (N, NE, SSW etc.) or a limited number of numeric CSS classes, every person that wants to use these icons will have to write a bunch of code to convert their weather data to CSS classes that weather-icons contains. They can't just plug the value they get from the weather data straight into the CSS with something like css_class = ".wi-wind-default.from-%d-deg" % weatherData.windDirection.

This is not a particularly onerous burden provided you know what you're doing. For less experience programmers, it's a fairly tricky problem.

Fortunately, your very smart decision to use an icon that can be arbitrarily rotated means it's easy to generate your own CSS classes (as above), which is generally a whole lot easier than trying to massage weather data into one of the existing CSS classes.

The bottom line is, as I see it, by offering a limited number of classes, you're effectively requiring every single person that uses the font to show wind direction to write their own code to convert their weather data to a CSS class understood by weather-icons. But because you made an arrow that can be arbitrarily rotated (yay!), it's a lot simpler to generate your own CSS classes instead and use them as above, so that's what most users will likely end up doing.

So why not save them the trouble by giving them the CSS classes they need out-of-the-box?

If size is a concern, put the compass-direction classes and the wind-direction classes in separate CSS files that can be included as needed.

[erikflowers]

If the API does return it in degrees, then the file of the 720 (or 722?) classes should accommodate it, you can see them here https://github.com/erikflowers/weather-icons/blob/2.0-wip/less/icon-classes/classes-wind-degrees.less

Changing the taxonomy or defaults is easy to change. Right now, it seems like .from-101-deg {.wind-rotate(281deg);} Would work for wind coming from 101 degrees (4 oclock), with the arrow pointing at 281 degrees (10 oclock).

So this would mean people who want to use it as you describe would just use "from" and people who for whatever reason don't like how that makes sense, they use "towards".

And that would be everything. I looked through the APIs and see what you mean. The API value of degrees would just be paired with its "from" equivalent. The Yahoo example API says that the wind direction is 260, so that would have the arrow pointed at 80deg, which is the 180deg opposite.

I leave "towards" in because people have said they like it that way. Maybe "wind" needs to be removed and just have it be a degree-rotate class so it could be used as a compass as well, since technically all it is is 720 mixins for 1 degree rotation.

edit: While I am here - does it need to have 722 classes to include 360 and 0? Right now it goes from 0 to 359. The APIs seem to say no.

[deanishe]

If the API does return it in degrees, then the file of the 720 (or 722?) classes should accommodate it, you can see them here https://github.com/erikflowers/weather-icons/blob/2.0-wip/less/icon-classes/classes-wind-degrees.less

That looks perfect!

So this would mean people who want to use it as you describe would just use "from" and people who for whatever reason don't like how that makes sense, they use "towards".

I can't speak for other people. Some may be using the icons for compass-type stuff and some may not understand that the wind direction you get from weather APIs specifies where the wind is blowing from, not where it's blowing to.

At any rate, offering both is an optimal solution. The way I see it is, if you have both, the only thing anyone can complain about is the naming, which is such a trivial complaint that you can just tell them to bugger off.

Maybe "wind" needs to be removed

Probably a good idea. As noted, "wind" tends to imply "pointing in the opposite direction". from and towards are much clearer. Hard to misunderstand towards-0-deg.

does it need to have 722 classes to include 360 and 0?

Dunno. Maybe not, but it can't hurt, can it? Cover all the bases and all that…

[erikflowers]

I am closing this issue as pretty much everything is address and fixed in 2.0, due out this week.