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