A visualization of global weather conditions, forecast by supercomputers
earth.nullschool.net
earth.nullschool.net
Yes I heard what I just said.
Also, by the Borsak-Ulam Theorem ( http://en.wikipedia.org/wiki/Borsuk%E2%80%93Ulam_theorem ), there are two points on the Earth directly opposite one another that have the same wind speed.
It's great that we've advanced from needing VTK to being able to do a visualization like this as a live movie, translating GRIB files to JSON.
If you turn the globe upside down, the controls for rotating it are backwards.
Some way to pan/zoom without pausing the visualization would be nice, but probably very difficult without moving to webgl-based rendering.
Maybe I'll port it over to C++ if I find some time.
e.g. I'm looking at
http://earth.nullschool.net/#current/wind/isobaric/1000hPa/orthographic=-11.40,53.26,489
The only thing I can get to change is the lon, lat, zoom at the end. Are there more things I can change?i do find this interesting coming from a native rendering background. the idea of converting data from one, fairly inefficient format (FORTRAN friendly from the look) to a spectacularly less efficient format still is a bit mind boggling without appreciation for the web stack (JSON is not for run-time in my world - its for 'tools' or 'compile' time).
the rendering is also quite underwhelming on a desktop PC - especially that it cuts out whilst rotating. there is some obvious stuff here that can be cached on inspection of the comments on github...
for instance, since there is a lot of data processing already, how about 'unprojecting' the data to remove the extra interpolation overhead from having to apply a transform and its inverse? Just because they have chosen to project their data onto a sphere doesn't mean you have to follow suit... its probably a useful format for meteorologists or cartographers but its not suited for rendering at all.
of course doing that will have similar results to a low pass filter unless you use a much higher density grid than the source (since you want a regular grid in your result and have irregular data points) - but visually that is very acceptable as a compromise.
the obvious guess suggestion is webgl and a 3d canvas, and dropping any fancy svg or other elements if they need to be visually sycned up with precision and rendering all of it yourself in a single consistent way. in the browser world its often a bad idea to rely on the implementation of anything if you need guarantees of quality - there is a lot of variation and a lot of bugs that have persisted for years on end...
i'd also suggest partitioning the data once its in 3d - a kd-tree or regular octree is quite easy to implement and understand and perfectly suited for this imo
http://earth.nullschool.net/about.html
EDIT: If you click on 'Earth' it brings up a menu with time controls.
The creator should really acknowledge their work...
I think I'm missing something. Are you overlaying a drawing canvas over the globe and handling your own custom projection then? Is it not possible to dynamically draw to a webgl texture and let the gpu take care of projection?
I do understand why you'd have to restart on zoom. Overall its an excellent project you have here.
WebGL would be fun to learn, but AFAIK not supported by mobile browsers yet.
How difficult it is to set this up for a custom local site that produces surface wind forecasts in GRIB2? Would it work for a small grid like this http://www.norcalsoaring.org/BLIP/BYRON/index.html ?
http://www.wsi.com/products-media.htm
With their tools for meteorologists you can layer up all the data layers from the GRIB, radar, observations, pollen etc. as well as the forecast data to 'see' and explore the weather in quite astounding ways. Think of what you have here but in lots more resolution with untold extra layers of data - it is a fun way to understand the world that we should all be seeing and doing by now instead of just getting a screenful of dumb icons.
It seems that the likes of WSI are quite happy to serve the market for dumb icons rather than make their deluxe weather tools available to all on an app. Imagine if everyone could be an amateur forecaster and submit useful observation data from their phone to get fed back into the 'model'.
The meteorologists are keeping the best tools from us thinking we would not be interested, your site encourages me to think otherwise.
Why does weather behave different over oceans when compared to land?
There are also strong heat / surface moisture gradients on land (think edges of forests, cities, coasts), which play a big role in convection.
By comparison, the ocean is an infinite plane so the dynamics are much more dependent on large scale forcings like the Earth's rotation and there is less local variability.
I think this is a data issue, not a weather issue.
The data they are using over oceans comes from microwave scatterometers, which use radar to measure disturbances of the ocean surface caused by near-surface winds. Basically, the power of the radar return is affected by the interaction of the radar waves with the irregularities in the water surface (https://earth.esa.int/applications/data_util/SARDOCS/spacebo...). To get a wind speed and direction from the radar power, you have to hit the surface from several different angles and perform an inversion.
There are several ocean winds space missions that do this continuously from ~90-minute Earth orbits. For reference, one is QuikSCAT -- http://science.nasa.gov/missions/quikscat/
There is no analogous sensor that works over land. Hence, the data over land is not nearly as uniform, dense, and regularly observed.
All that said, this particular visualization seems to have a calibration issue, because the land winds seem to be off in magnitude. I'm not enough of an expert to know if this is a problem with their data merging, sensor selection, stratification (e.g., winds at land surface may be lower than at sea surface, but up 50m they may be comparable), or something else.
You can get other surprising things from remote sensing over oceans, including salinity, temperature, and incredibly precise elevation.
The land data is scarce in e.g. the Sahara, but the density over western Europe is pretty high. The land based data is continuous as well, and not affected by cloud cover.
Another issue with in situ sensors is calibration and uniformity. Unless they were installed by a central authority, they are likely to all be different. This makes analysis harder.