Accessibility layer doesn't show variation well and is sensitive to spacing of grid
doorleyr opened this issue · 4 comments
The new accessibility layer does not show variations as expected in the tables I'm working on. In general, the colors appear to be almost binary: either blue or pink with no shades in between. For example, below is the shopping access layer in CityScopeJS, and the same layer shown in kepler.gl with a simple red to green heatmap.
The appearance of this type of layer also depends strongly on the spacing of the grid. It will only look like a heatmap if the points are perfectly spaced. The Corktown heatmaps look like columns because the grid spacing is too large. The problems above with colors may also be caused by the grid spacing being too small.
I suggest replacing the current access layer with a simple geojson layer which takes a geojson of polygons as input and maps from red (low) to green/blue (high). By allowing the user to specify the polygons, the problem of variable grid spacing is avoided.
https://deck.gl/docs/api-reference/layers/geojson-layer
The input would be a geojson of polygons representing a gridded heatmap. It should also be possible for this layer to work with both polygon and point inputs, thereby maintaining backwards compatibility with tables (such as Corktown) which are currently supplying geojsons of points for the access layer.
Note that the deckgl Grid layer was previously discussed as another possibility but this only uses a north-south oriented grid which will look weird overlaid on the interactive grid.
Also, the heatmaps which were used in CityScopeJS before now were based on 2D kernel density estimation, which aren't really appropriate for this application. They are meant for representing density of non-valued points, rather than interpolating between values in space. The distinction is well summarised in this issue: visgl/deck.gl#4827
From the get-go, I'm fine switching to ploy-layer. Worth considering however, that the module will have to send it on any update, since we don't have a way to 'hand-shake' with a module, and know if this is the first POST. Still, we can test and see if it's becoming a bottleneck on run time.
the colors appear to be almost binary
That's because there are only 2 colors in our current palate. We can use reacher ones, results should be similar.
The appearance of this type of layer also depends strongly on the spacing of the grid. It will only look like a heatmap if the points are perfectly spaced. The Corktown heatmaps look like columns because the grid spacing is too large. The problems above with colors may also be caused by the grid spacing being too small.
if we stick with this layer, there's a simple fix - this layer is not meant to look like a smoothed out heat map, but indeed in CT case the gaps are two wide. one easy fix is to send another attribute (grid_size?) that tell me what is the gap between cells, which I can then translate to the columns appropriate thickness.
Let's try the simple changes you suggest above and see how it looks.
For colors, I think there should definitely be more of a gradient instead of just binary low/high. I think red-yellow-green as shown in my screenshot above is most intuitive for bad-moderate-good.
For the spacing, I'm ok to supply the grid_size but where should it go? Currently the top-level properties field is just a list of layer names so it can't go in there. I can add a grid_size property at the same level as properties but this is abusing the geojson structure a bit. Any other suggestions?
If you're ok with it, I'll be happy to keep things as they are for the time being; I'm working on a deeply gutted version (https://github.com/CityScope/CS_cityscopeJS/tree/detux) that among many other things bring back the old heatmap, and will allow users to include own color scheme. It's still very pre alpha, but it would be great to focus dev power there.
fixed with new version. HeatMapLayer is broken and will not work when DeckGL map has shadow effects are on.