ASCII Art Weather | Hacker News Reader

ASCII Art Weather

wttr.in

336 pointshjc89103 comments

What's impressed me about this is how much faster it is than Web pages or Android apps.

Really: just transmit the data necessary to convey your information. Your app is in the way.

wttr.in on Android using Termux is actually pretty awesome.

Try looking at the source of the page. There's no way in hell anyone would call that "just" the data necessary to convey the information.

The site is also unusable on mobile, because ASCII art unlike proper semantic HTML is not easily rescalable by the browser. And it's inaccessible by users relying on screen readers, ironically because of all the ASCII cruft.

The inaccessible comment is somewhat ironic. If the display of the ASCII craft is in a terminal at least I have some control over the font size and, in particular, the background colour.

Sorry, I meant cruft - autocorrect didn't recognize the word and corrected it to 'craft'.

And the same control extends to users on the Web at the very least. Userstyles/scripts and extensions can modify websites, giving users the ultimate control over website content.

My point was in response to the grandparent's statement that most modern apps get in the way of the user - those exact same things are also crucial to, for instance support screen readers and mobile users.

> in particular, the background colour

I use this on my computers at work. Its wego and the ONE frustrating thing is you can't change the colors so that they work well with a light background.

On iOS the page scales as expected. The only visual glitch with columns not matching up is something I'm getting on non-zoomed desktop as well. Presumably this is from specific source text of as-of-yet unexpected lengths not being handled properly during calculation of the maximum columns.

The accessibility issue would be resolved by using workarounds typical of screen-reader solutions: ARIA markup, tricks like Bootstrap's .sr-only class, etc. At the end of the day, neither images nor ASCII art are going to be accessible, so if you implement the required accessibility functionality, theoretically there is no difference between them. I do shudder to imagine just how ugly the source would look (hide every character of the nonsensical ascii from screen reader, and replace it with proper text representation).

On Android the browser renders the page at full width, making the icon and text unreadablely small. You can zoom in, but that shouldn't be necessary in the first place if the site was responsive.

Bootstrap's screens reader only classes are somewhat of a hack, and does the opposite of what you're suggesting anyway (aria-hidden is the proper way to go, but as you said that will mean adding a ridiculous amount of markup to the page), while images support screen readers natively via the alt attribute - no messy markup needed.

>The site is also unusable on mobile

Not everyone wants their webpages to be seen on mobile, this one works perfectly in lynx. Does your website work in lynx?

I would go out on a limb and say yes. Any website designed with screen reader accessibility in mind would work with Lynx, which is a more capable browser than screen readers.

That's not really true: JAWS, the most popular screenreader, works with IE and Firefox.

You can have a single-page javascript app be totally accessible. You could also have an ASCII art app that renders perfectly in lynx be totally inaccessible to a screen reader.

FYI: It scaled perfectly fine on my Android/Galaxy S5 so while it's scalable, I can't comment on how "easily scalable" it is nor if screen readers would have a problem.

I would think screen readers would have no impact. Text is pretty much text (utf8, etc...) and the scaling is handled by your font choice not your text choice.

^^shrug^^

ASCII art is not scalable when you mix it with text like on this site since scaling the art will also make the text unreadably small.

Screen readers depends on the semantics as defined in HTML to recognize what to read. In this case when you use text to define the 'layout' of the page, screen readers loses the ability to differentiate between content and presentation. This is also one of the reasons why using tables for layout is a bad idea.

>The site is also unusable on mobile, because ASCII art unlike proper semantic HTML is not easily rescalable by the browser. And it's inaccessible by users relying on screen readers, ironically because of all the ASCII cruft.

As web developers, we're used to "everyone" being the audience, but that's not the case here. As a stylized visual representation of the weather, it's fine. I dig it.

Making sure something is accessible to screen readers is generally an important thing (and could be worked on here) but I give this project a pass because the visual design is the whole point of the exercise.

And while I viewed this on mobile (and was fine for me with zooming), that clearly isn't the audience. Again, it could be improved if the author felt like it, but even if "fixed" (perhaps having morning, noon, evening, night being stacked vertically on mobile) I don't think this would be hardly anybody's goto weather reference on mobile. It's meant for us desktop users who are lovers of the terminal aesthetic.

Oh, I agree that this is really cool in terms of aesthetics.

I'm pointing out that the grandparent's comment about this being minimalistic, and comparing it to real weather apps as being absurd. If you're building a toy project aimed solely at programmers on desktop, there's a lot of things you don't have to care about. Some of those things are exactly the 'bloat' the grandparent has been complaining about.

Fair 'nuff! Thanks for the clarification. (The other stuff isn't the only source of bloat--for example, weather sites as a category feel (on average)...um...spammy (can't think of a better word) to me when it comes to quantity and presentation of ads and "suggested content"--but I get ya.)

The point wasn't necessarily this specific implementation. But the general concept of lightweight text web responses. Without several MB of JS, CSS, graphics aassets, etc.

Could you not wrap it all in a div and do something like:

    #ascii-art {
        font-size: 2vw;
        overflow: hidden;
        white-space: nowrap; }

As noted, you can fetch the page via curl. Takes just over a second total.

Contrast ~6 - 60 for a typical web page these days (and yes, Firefox appears to be part of the problem, but I'm willing to trade a lot of speed for utility).

> just transmit the data necessary to convey your information

What is that cruft at the bottom of the page?

Also, I would prefer this as a CLI application, not as a webpage. Further it should have flags that make its output more friendly to further processing (e.g. grep).

Otherwise, nicely done.

try curl(1)

> Also, I would prefer this as a CLI application, not as a webpage.

    curl http://wttr.in/london

Looks nice :)

Using curl removes the HTML tags? Nice feature (though a little obscure).

I think what they're doing is using the user agent header like the accept header, which makes sense for that specific idea, as the browser version is actually just kind of imitating a console. It currently doesn't work because they ran out of queries on their backend service, but I think they were not stripping html, but delivering a terminal text version with color escape characters.

It's actually a web frontend for a CLI application:

https://github.com/schachmat/wego

It could be argued that you don't need an ascii icon for "sunny", etc.

Just one codepoint would do! Basic weather symbols like SUN (U+2600) and RAIN (U+2614) have been in Unicode since 1993. More detailed 'emoji' have been added in recent years.

[1] https://en.wikipedia.org/wiki/Miscellaneous_Symbols

[2] i.e. http://emojipedia.org/fog/ etc

the CLI application[1] that this is based on has an "emoji" frontend[2] that does just that

1: https://github.com/schachmat/wego

2: http://cl.ly/1w3b45242k3R

Ok, but then it's not ASCII art; it would be Unicode art.

Ok why not get Lynx on your Android device?

the rule of of diminishing return applies.. at some point, the usability shortcoming of ascii interface out weights the payload penalty

I've installed w3m (through termux, which is both a terminal environment and apt-based installer).

I don't use it much but there are times when it's faster and cleaner than any other alternative. It often actually is superior to GUI presentation, except for the annoying tendency of text to run into the gutter.

I've been kicking around an idea for a FYWD browser. That might stand for Fine Young Western Dinosaurs or Fuck Your Web Design. It would offer a standard format, non-JS, uniformly presented readable Web page. Not intended for apps, but a sane set of presentation defaults for a given site.

Site-offered CSS would be ignored (or at best strongly deprecated). Straight-bog HTML 1 / HTML5 sites should render best. User could opt for specific stylesheets (e.g., night mode, large/small font), provided _locally_.

It'd be aimed at reading.

Something like Reader Mode on Safari or Firefox, but enabled by default.

(I use the latter, often intercept loading pages to hand-type in "about:reader?url=" before they fully load.)

Some other bits in mind as well, sort of mulling over the concept for now.

This codepen shows what a few basic rules can provide. Doesn't take much to make that work across a wide range of display sizes. http://codepen.io/dredmorbius/pen/KpMqqB

Oh cool, this is using my ansi -> html conversion script!

http://www.pixelbeat.org/scripts/ansi2html.sh

           \/\/\/\/
         /         \
        /           \
       /             \
   /\_/     0    0    \_/\
  |                       |
   \/ \      |_|      / \/
       \             /
        \  \-----/  / ---------- Brilliant!
         \         /
          \_______/
            |   |

This is awesome!

But now I get:

> Sorry, we are runnig out of queries to the weather service at the moment. Here is the weather report for the default city just to show you, how it works. We will get new queries as soon as possible.

Can't you cache the data for an hour to prevent this from happening? Heck, just show me something even if it's fake as I love how the thing looks :)

It works in the Terminal, too!

curl http://wttr.in/london

But not as native ANSI though? Unless it's doing some clever useragent detection? (I'm on Windows without curl/wget).

Dunno, tried it on OS X and it's colorful and looks good.

Yes, it does return ANSI when you curl/wget the address.

"This is a web frontend for a console weather application wego, using it as a backend."

https://news.ycombinator.com/item?id=9545180

Setting up wego on a raspbian were a bit painful (go in aptitude is 1.3 while wego requires 1.5), the easiest way that works out of the box is simply running curl wttr.in/Localtion ;)

And the moon: http://wttr.in/Moon

The moon phase visualization takes arbitrary dates too: http://wttr.in/Moon@2016-Mar-23

For the forecast, it also appears you can append "?m" to the URL for metric units or "?u" for USCS units to override the default it uses based on your presumed location.

I was looking for that; surprised I didn't see it in the github page/docs anywhere. It's weird looking at London Weather with Imperial units.

We were unable to find your location, so we have brought you to Oymyakon, one of the coldest permanently inhabited locales on the planet.

>Freezing fog

Don't want to know more about this place.

Any idea how to specify a location, I tried the site on a few different browsers and some are correct and others are not. I suppose some browsers are blocking its means for determining the location.

edit Looks like the issue is caused by some browsers/settings that hide the public ip prevent it from finding location.. would be nice to specify, i like the page.

Enter your Zip code after the URL (if you're in the U.S.) --

http://wttr.in/65201

It also supports UK postcodes[1], Canadian postal codes[2], and lat/long coordinates[3]

1: http://wttr.in/cb1

2: http://wttr.in/l1v

3: http://wttr.in/52.1988,0.0850

Nice! :) alias weather="wget -O - http://wttr.in/london -q"

Slight tweak watch --color "wget -O - http://wttr.in/Palmerston_North -q" Not that its going to need to update that much, its just, well it makes me feel like it's more accurate that way.

You might want to use wego[1] directly if you're interested in weather reports in your terminal, if the dependencies aren't an issue.

[1] https://github.com/schachmat/wego

Using 'watch' 'curl' (refresh every minute)

watch --color -n60 'curl -q http://wttr.in/london'

The weather data appears horribly inaccurate. I'm traveling in Vietnam (Hanoi) today and we're seeing temperatures between 25 and 31 deg C, but the site says we're roasting at 34 - 48 deg C.

I checked Bangkok where I will go tomorrow, and the site claims we will hit 45 deg C which is ridiculous.

I don't think it's an interval. The second temperature seem to be the "Feels Like" temperature from worldweatheronline.com. I'm getting 52°C in Singapore which is ~15°C over the all time record.

wttr.in/Cambridge looks completely wrong. Says Cambridge, UK at the top, but -2°C and heavy snow? Really?

EDIT: looks like it's using http://www.worldweatheronline.com/cambridge-weather/scottish... rather than the one in East Anglia

There is no way at all to handle duplicate location names. Another nice example is wttr.in/denhaag which uses the South African city of "Den Haag", which is so small even Google Maps searches for it end up with the South African embassy in the Dutch city of that name.

... which is in a country so small, google maps searches end up with the town in Michigan of that name ;)

Use a postcode instead: http://wttr.in/cb1

Or lat/long: http://wttr.in/52.1988,0.0850

It's pretty cool, but it doesn't quite line up for me. Unicode characters (but ... "ASCII"?) are the prime culprit, but something also going on with the 'delimitting' header lines too - they're way off.

Agree it doesn't render well in Chrome for example. In elinks and firefox under Linux it looks fine for me though.

Works fine for me in Chromium, Firefox/Iceweasel and curl..

Broken for me as well.

Looks like certain assumptions about max length of weather numbers causes unnecessary additional padding resulting in misaligned borders.

http://imgur.com/vyupGUN

I think that's a problem with the font, actually - it's supposed to be monospace, but the diagonal arrows (e.g. ↗) are about 1.5 times the width. I have the same problem.

(Or maybe not "the" font, but fonts in general - perhaps it's trying to use one font, which doesn't have these arrows, so it falls back to a different one?)

Funny thing is, it aligns properly in the terminal (cygwin here)

http://imgur.com/LicBeh3

Yeah, because it's not showing the diagonal arrows.

If you have a font that supports proper monospaced unicode, it works: http://cl.ly/2f410i1k270D

Thanks for confirming. Can you share the font/fontname you are using? I would like to install it on my PC as well...

Update: Looks like they fixed it now. I just re-visited the site after posting this comment and see that there are new monospace arrows rendering in a properly aligned manner.

Nice! I like the aggregation into time blocks people tend to care about.

What's the definition of the probability of precip you're using? And how are you aggregating it? I ask because definitions can vary a lot and aggregation may not be straightforward.

Another thing to consider is how you interpret/convey wind direction. Usually weather data sources provide the direction the wind is coming from. And people seem split on if the arrow should point to the origin or direction, depending on their background. It's a shame there aren't more characters like ⎋ (with the arrow going the other direction) to better represent origin/direction.

Related, "Forecast Font" takes an interesting approach to this, using a webfont: http://forecastfont.iconvau.lt/

Because it uses css to overlay elements, the woff font itself can be just the required pieces, rather than all the combinations. The woff font is 4.6kb. Not as tiny as ascii art, but still pretty small.

I much prefer weather via finger using graph.no:

https://news.ycombinator.com/item?id=11106354

https://0p.no/2014/12/13/graph_no___weather_forecast_via_fin...

And the command:

    finger london@graph.no

Which produces this:

                  -= Meteogram for united_kingdom/england/london =-                
    'C                                                                   Rain (mm) 
    17                                                                   
    16      ^^^   ------^^^^^^                                           
    15   ^^^   ---            ^^^                                        
    14^^^                        ^^^                                     
    13                              ^^^                                  
    12                                 ^^^                               
    11                                    =========            ===   ^^^ 
    10                                             ============   ===    
     9                                            '  |                   2 mm 
     8                                      |  |  |  |  |  |  |  |  |    1 mm 
      _11_12_13_14_15_16_17_18 19 20 21 22 23 00 01 02 03 04 05 06_07_08 Hour
    
       SE SE  S  S  S  S  S  S  S  S  S  S SE  S  S  S  S  E SE SE  S SW Wind dir.
        1  2  5  4  4  4  5  4  4  4  3  3  3  2  3  2  1  0  1  2  1  3 Wind(mps)
   
   Legend left axis:   - Sunny   ^ Scattered   = Clouded   =V= Thunder   # Fog
   Legend right axis:  | Rain    ! Sleet       * Snow

So it's 16'c with a light cloud cover until 1pm, clear until 4pm after which it gets a little cloudy again, some rain between 11pm and 7am, which is very light and heaviest around 2am.

That is the equivalent of this:

https://www.yr.no/place/United_Kingdom/England/London/hour_b...

Which has, for me, proven to be the most accurate and informative weather forecast.

And if you just want to use the latest meteogram image:

https://www.yr.no/place/United_Kingdom/England/London/avanse...

Also: Weather available via HTTPS! I dislike how the vast majority of apps on mobile devices use location for reporting local weather but do so over HTTP and leak location data. BBC, I'm looking at you.

If you're on Android there's a great widget that makes using any other weather app pretty redundant for most cases:

https://play.google.com/store/apps/details?id=widget.weather...

For me yr.no is almost always correct at least for the next few hours. It can be off a bit if you go a day ahead but it's updated regularly so just check often to get a picture of how the weather will be. I live in Sweden but have tried it extensively in Germany too with similar results.

Brilliant!

Try:

    curl -sk https://wttr.in/sfo

If you use plain http, you don't even need the flags.

To visualize weather in the terminal you can also use:

$> a=$(curl -Ls "bit.ly/1OuRPDJ"); curl --data "$a" "tty.zone?cols=${COLUMNS}"

(via https://github.com/yaronn/wopr)

Nice, looks nice in w3m an lynx too (I wonder if it's possible to enable colors though). I have new alias:

   alias weather="w3m -dump wttr.in/budapest"

Edit: I just found in the comments that it works with plain curl too with color. Nice.

Really good! Now I can see the weather on the command line in addition to a calendar and a clock.

I think It'd be better to show the weather of yesterday instead of showing the weather of the day after tomorrow so that I can compare the sensory temperature.

I don't know why looking at this makes me so happy, but it does.

Made a small bash function for it. You can give the city as an argument and otherwise defaults to the env var $WEATHER_CITY and if that's not set, won't provide any city to the site which will result in the site guessing your location.

weather() {

    if [ "$1" ] ; then
        city=$1
    else
        city=$WEATHER_CITY
    fi

    curl http://wttr.in/$city

}

As a quick aside, you can set default variables in bash with ${var-default}, so your function can be condensed to:

  weather()
  {
    curl http://wttr.in/${1-$WEATHER_CITY}
  }

Why does it forecast sunshine at night?

Neat idea! The social buttons on the bottom kinda ruin the aesthetic, though (at least for me).

I was thinking the same thing. If those were made in ASCII as well it would've been delightful.

I like it :-) But I agree, social buttons should be removed or at least moved to page like /about.

I wish it showed dewpoint. Almost all these weather apps never show dewpoint (or it's hidden away), but instead almost always show the relative humidity percentage which is useless and just takes up space.

It even looks good when I turn off CSS, just lose color, and presentation of the badges at the bottom. Looks really nice in the terminal (urxvt/linux).

For PowerShell: (Invoke-WebRequest wttr.in/Brussels).AllElements | ?{$_.tagname -eq "pre"} | Select-Object -ExpandProperty outerText

Or a bit shorter:

    ((iwr wttr.in/Brussels).AllElements | ? tagname -eq pre).outerText

We could also wrap it into a function:

    function Get-Weather($Location){((iwr wttr.in/$Location).AllElements | ? tagname -eq pre).outerText}

Or you could just set/unset all the right headers and get the ASCII art directly (as `curl wttr.in/{location}` does)

Although you'll need to interpret or strip the color codes.

There is a hack to make PowerShell print vt100 colours http://www.nivot.org/blog/post/2016/02/04/Windows-10-TH2-%28...

Doesn’t work for me, but works for others it seems.

Nice it supports coordinates as well: http://wttr.in/52.1,4.22

Sadly, the weather on the North Pole is undefined...

> http://wttr.in/89.99,0.00 >> ERROR

Well, 85.90,0.00 works... must be a weather-station somewhere near... Greenland or Jan Mayen.

(Meta)

Perhaps the link should point to the base URL, apparently it detects your location if available (didn't work for me because I have it disabled).

Looks like it was submitted 2 days ago https://news.ycombinator.com/item?id=11477365 , so maybe it was done to avoid the dupe detection.

No comments on that submission - so doesn't really matter :)

I like their fallback though :P

> We were unable to find your location, so we have brought you to Oymyakon, one of the coldest permanently inhabited locales on the planet.

I'm in Oxford, Ohio. Thinks I'm in Oxford, England.

(Not criticizing, just amused.)

It says "ERROR".

cool! wind direction causes column alignment issues a bit in chrome.

in safari etc as well. I think its if theres a lot of double digit winds: http://wttr.in/rst

I thought this will be something based on METAR codes...

What is the source for the weather data?

can't find a way to change fahrenheit to celsius

append ?u=metric to the URL

Plain, cool.

Reply on news.ycombinator.com