thegrossman

I've been working on a weather Watch app (Dark Sky: http://blog.forecast.io/dark-sky-for-apple-watch/).

The WatchKit SDK can seem almost frustratingly limited at times, but I think that's for the better: I'd wager that the first crop of 3rd party Apple Watch apps are going to be a lot more rock-solid than the first crop of 3rd party iPhone apps, due mostly to the focus imposed on us developers by the constraints of the SDK.

The API is going to be a big priority for us going forward. We have some new development planned on that front, and AI will be able to help us out tremendously.

There's a toggle on the top right, in the blue bar.

Dark Sky is kind of an expensive app, as apps go: $3.99. Which means we have a small percentage of the market, giving it a very different growth curve from free apps. Our rate of revenue has been slowly increasing since we launched. And since our market share is so low, I don't see us running out of potential customers any time soon.

(And to answer your other question: Forecast.io makes some money, but not much. And we do have an increasingly large revenue stream in our data API)

Heh, the check's already in the bank. What can they do to us now? (Just kidding. I actually ran the post by them and they had no issues at all -- I'm honestly not sure what I would have done if they did have a problem with it).

When we compare it to RTMA, we leave out RTMA from the list of data sources. Likewise, eventually I'd like to do the same with a subset of the ground stations we use.

(The problem with finding completely independent measurements is that we'd want to use them as an input!)

Oops, it should read centikelvin. Fixed! Thanks.

Also: Validation is tricky, since we can't just compare the output to ground station observations, as we incorporate ground station data into the model. Eventually I want to generate alternative versions that randomly exclude specific stations so we can use them for comparison.

"Real-time" is the key. As far as we know, there isn't another real-time global data product that is this high resolution.

And while we actually use MODIS data as an input to our temperature correction model, it is, as you mentioned, land surface temperature, whereas our map represents near-surface air temperature (i.e., what you'd get in a normal weather report).

Thank MapBox. If it were up to me, I'd do something funky like a blackbody-esque color palette and then get yelled at because it'd be hard to read. :-)

The color palette adjusts based on the zoom level in order to improve contrast. Roughly a bazillion people pointed out that it's "broken", so I guess that was a dumb call on my part!

We did, but they didn't work quite as well. But that could absolutely be my lack of experience with how best to normalize and format the input vectors.

In the end, NNs seemed less "fussy", if that makes any sense.

Also, correct me if I'm wrong (and I very well could be), but the most egregious noise -- the giant Bagel Blobs -- aren't insect reflections, but rather night-time temperature inversions. Can dual-pol correlation help identify those?

The color palette of the images in the blog post was adjusted to highlight areas of precipitation at the expense of intensity discrimination. Dark Sky itself uses a wider range, but it's still a similar blue to purple to salmon to yellow color table.

The reason we went with that over the standard green-to-red color table is because I personally find the standard colors to be jarring and more confusing to the casual user because of the increased contrast between intensity bands (at least, it certainly was to me back when I was a casual weather app user!)

The tradeoff is that there isn't as fine an intensity discrimination at lower intensities. In theory I can see how that can be a problem, but I haven't noticed it in practice.

Dual pol wasn't deployed when we first started Dark Sky. Now that it's becoming available, it's definitely going to make our job a lot easier!

Not knowing much about it, though, it'll take some time for us to become comfortable with the data.

Exactly. Those enormous Bagel Blobs tend to occur after the sun goes down (and only in the warmer months. Two months ago, they weren't there).

The image was generated around 10:30 PM EST, so they hadn't had time to propagate further west.

Regarding neural nets, I have to admit that I didn't have much experience with them either before working on Dark Sky. They do, however, seem to be a little more forgiving than other kinds of classifiers (Support Vector Machines, and the like).

Check out the examples for the FANN C library: http://leenissen.dk/fann/wp/

Or in ruby: https://github.com/tangledpath/ruby-fann

Seeing this on HN, I realize I didn't go into a lot of technical detail in the blog post (we still aren't quite sure who our audience is with the Forecast blog). So if anyone has any specific questions, ask away.

We chose it for forecast.io because of the input/output connotation. It is a concise way to imply "data service".

.io also allows us to use a short descriptive domain name. If we went with a .com, we'd be stuck with either something like forecastweatherapp.com, or a made up nonsense domain -- in which case we'd be basing the name of our app on the specific domain we were able to acquire.

The top layer of our backend is node.js running behind nginx. We use redis for storage, along with a bunch of flat files for certain things. Under that is a mostly ruby / mysql layer that manages a bunch of C programs for doing various number crunching tasks.

Oops! That'll be fixed and pushed this afternoon. One of the huge advantages of this being a mobile web app rather than a native app is we don't have to wait more than a week for bug fixes to be approved by Apple!

At forecast.io, we use the GFS and NAM as two of our models (among others). More info on our data sources here: http://forecast.io/raw/

We just built it with a bunch of hand-coded HTML, CSS and JS. No fancy framework or anything.

Yeah yeah. We totally alienated a bunch of non-Americans by not having that in there. We'll add it!

We just pull in a bunch of raw weather data from a bunch of sources. Most of them are free (although the ones that aren't tend to be silly expensive). Check out more here:

http://forecast.io/raw/

Getting smooth animations took an inhuman amount of effort... adding a rotating map would have been a little bit too much for launch. Hopefully we'll get to it in the near future.

Regarding the UK, you're right. I'll add a new view that's moved to the west.

Just the animations are being rendered on the device (to save bandwidth). The forecast data is being computed on the server.

Kickstarter is nothing more than a web hosting company? Pardon?

I recently raised more than $38k from Kickstarter. There is absolutely no doubt in my mind that I wouldn't have been able to raise nearly that amount by throwing up a website and going it alone.

Here are some stats (for this project: http://www.kickstarter.com/projects/jackadam/dark-sky-hyperl...)

1) 32.26% of our funds came from visitors who found our page through the Kickstarter newsletter.

2) In total, 56% of funds came from visitors finding us via other Kickstarter pages (their home page, category sections, etc).

3) 44% were referred to from external sources.

But here's the thing: the external links were primarily due to the publicity we got from Kickstarter's promotional efforts. We got mentioned on Wired, Fast Company, the New York Times, and CNN.com -- not because we reached out to them, but because of the large number of people talking about us after finding us on the Kickstarter site itself.

In the end, Kickstarter enabled us to raise tens of thousands of dollars and in return took a measly 5%.

We definitely want to expand it beyond the US! But dealing with each country's different network of weather radar is a daunting task.

As far as giving away the algorithm: Unfortunately, it isn't a single algorithm that can be packages nice and neatly. So I'm not sure how that would work.

But, we do plan on developing an API that 3rd-parties could use.