thegrossman

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.