heshan0131
commented
4 years ago This a very well thought feature request. Thanks in advance. To handle vector datasets. We have 2 feature that is along the line.
-
For a dataset contain static lat lng we can use an arrow layer https://github.com/keplergl/kepler.gl/wiki/Kepler.gl-2019-Roadmap#add-arrow-layer--rfc--
-
For a dataset that needs dynamic particle animations. We can integrate a version of the wind map. This will obviously require a lot of work in terms of interpolation, But that's the direction we want to move into. kepler already offers certain level of aggregation in hex, grid and trip layer. The wind layer will require work, but supported by kepler's architecture
goldford
jweisbaum
Is your feature request related to a problem? Please describe. Kepler currently features a range of techniques for visualising data (e.g. arcs, lines, heatmaps etc.), however none of these are ideally suited to rendering vector data (i.e. datasets with a magnitude and direction component). For the purposes of this discussion, vector data refers to directional data and not to datasets comprised of points, lines and polygons.
One of the best platforms I've come across for visualising this type of data (windy.com) uses WebGL to render animated particles, giving the user a clear indication of magnitude and direction at any given time step. I frequently work with ocean current and wind datasets, and being able to display them as an animated particle layer in Kepler would be amazingly powerful.
Alternatively, the ability to render simple quiver representations could be a practical interim solution when working with these types of datasets.
Describe the solution you'd like Particle animations Ideally, the ability for Kepler to render particle animations for vector (i.e. magnitude and direction) datasets would be preferred. Given a layer dataset featuring a set of irregular points with latitudes and longitudes, each point would also feature a column value for magnitude and direction respectively. Kepler would then calculate the convex hull of the dataset, and not render anything outside the bounds of the hull. For data within the hull, Kepler would use a computationally efficient nearest neighbour interpolation to determine the magnitude and direction across the entire data extent. If a nearest neighbour interpolation is too computationally demanding, it could be a requirement for the dataset to be a regular 2D grid of point data and a more efficient bilinear interpolation strategy could be used instead (this is the approach used by windy.com and earthwind).
Particle density across the dataset extent would vary depending on the users map zoom level (as with windy.com and earthwind, perhaps also being enhanced by a customisable unitless 'density amplification' factor specified by the user, ranging between 0 to 1 to reduce the density, and 1 to an arbitrary upper ceiling (10?) to increase the density on the map. Other parameters to customise the particle color (white by default, as with windy.com and earthwind), drop rate, opacity and speed factor could be useful as well (see the article in Additional context for further reference on what these variables are). Additionally, being able to switch between different styles of particle animations would be hugely advantageous (see examples below). When a user would have interactive tooltips enabled, clicking on a location within the extent of the vector dataset would display the interpolated magnitude and direction of the vector layer at that point (as with windy.com).
Examples showing two different particle animation styles (waves and wind respectively) from windy.com. Note that these examples refer solely to the overlaying particles in varying shades of white, not the background color gradients.
Quiver Although a quiver solution won't provide the same level of clarity as particle animations, it is likely to require less development as this approach utilises the same data model approach currently adopted by Kepler (i.e. it relies solely of data values at defined points and no additional interpolation is required). As with the particle approach, the dataset would need to be a series of irregularly spaced points featuring a latitude, longitude, magnitude and direction. Kepler.gl would then render a series of directional arrows at each point, showing the direction indicated by the arrow head and magnitude by the length of arrow. Both the size of the arrow head, width of the arrow line and arrow colour could be specified by the user, and as with the particles, a unitless 'amplification factor' could serve to modify the scale of the arrows at each point accordingly.
At lower zoom levels, it's highly likely that quiver arrows from nearby cells would overlap one another, making it challenging to clearly read the map at these scales. Two approaches could be taken to counter this. The first is to give the user the option to vary the density of displayed quiver arrow points proportional to the current zoom level, so at lower zoom level, not every quiver point is displayed (effectively subsetting the quiver data at lower zoom levels). The second approach could be to provide an option that prevents overlapping quivers from being rendered. This is likely to result in a better user experience, but may be more computationally expensive for Kepler to calculate the best combination of quiver arrows that won't overlap with one another at any given zoom level.
Examples showing black quiver arrows overlaid on a temperature dataset, indicating magnitude and direction of ocean currents:
Describe alternatives you've considered With the current tools available in Kepler, I've tried calculating a series of start and stop lat/long pairs from exisiting magnitudes and directions before loading the dataset and rendering these using the current line function. This approach has significant limitations, namely that this is not scalable as the zoom level changes (as it's using fixed start/stop lat/long pairs), and it doesn't provide a clear way of indicating the origin and direction of each line (even when coupled with a separate point layer showing the lat/longs at the start of the lines, this is not as clear as showing arrows to represent direction). Direction could perhaps be clearer by allowing an alpha colour value at the start of each line (i.e. progressively increasing opacity in the direction of the arrow), but Kepler doesn't appear to support transparency when setting start/stop colours for lines (please correct me if I'm wrong here, as this would also be really handy).
Additional context Although the implementation of animated particles using WebGL may seem like a particularly large exercise (and don't get me wrong, this is not a small job!), the mathematics for the WebGL implementation (including required interpolations) are already freely available for use. There is a great worked example of animating wind data using WebGL and Mapbox, with the code already available on GitHub and a working demo too. Perhaps this might provide a useful reference?