looks broken here if i rotate it until it redraws which is a shame... i do find this interesting coming from a native rendering background. the idea of convert

looks broken here if i rotate it until it redraws which is a shame... 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