deck.gl

A satellite data for social research.

). 2. By default, many of the deck.gl layers don't use 64-bit floats, they use 32-bit floats for lat/lng degrees, which supports many use cases for resolution and speed. In a WGS84 projection, with a base/meridian of (0°,0°), a point in northeast Russia represented by two IEEE754 32-bit floats (say: 70°N, 179°E) will be within roughly a meter of its original value (as per https://upload.wikimedia.org/wikipedia/commons/3/3f/IEEE754.... and as per the earth circumference is ~40M meters, 1° is at most at the equator ~ 40M/360 meters ~ 100 km, and a rounding error of 10^-5 on a float that's 10^2 means you'll be off by around a meter). The deck.gl layers allow you to provide your zero point, and you get 100x the resolution at 1 compared to 100 in the exponent+fraction format for floats (so pre-render your Δlat, Δlng in 64-bit float computations with standard 80-bit precision somewhere besides WebGL). If you have more than a 100 km x 100 km square for which you need sub-centimeter precision, computed at render-time, 32-bit floats aren't for you. Which brings me to speed: WebGL doesn't have 64-bit floats, or 64-bit ints, natively. You'll have to fudge the math in software in a shader, instead of the native add instructions on the GPU, and that is far slower. If you do need higher precision with only 32-bit integers, you can cluster your points around many different base/meridian points instead of the single (0,0), and take advantage of increased float precision on smaller numbers. Or use 64-bit floating computations with the standard 80-bit precision in Javascript, outside of GPU shaders, and compute millions of floats in Javascript typed arrays to send into deck.gl shaders.