changing dot radius scaling? (3.x) about deck.gl HOT 13 CLOSED

@contra - Correct. The projection shaderlib now enables all layers to work in both meters and lng/lat, and this also enabled us to specify extents in meters, so we tried that.

As you say it is of course also sometimes desirable to specify extents in pixels, but there is no prebuilt mechanism for doing this yet - it will require a touch of hand coding in the vertex shader.

I've not quite made up my mind what I think is the best approach. I was leaning towards preferring to have radius specified in meters, while allowing the app to specify a minimum pixel size for the point using a prop... that should be pretty easy to add to the current layer. What do you think?

from deck.gl.

@ibgreen Size in meters with min/max pixel size solves all of my use cases. Biggest issue right now is being zoomed way out and having the dots be non-existent, and zooming way in and having them consume 50% of the viewport.

from deck.gl.

How does all of this play in with strokeWidth for choropleth/arc/line? Is the plan to move those to the same system as well?

from deck.gl.

strokeWidth is a little harder to change, since it currently uses gl.lineWidth which is specified in screen pixels.

We do have an enhanced-choropleth-layer that extrudes lines to thin triangle strips and yes this gives us that level of control (an also allows us to get clean "mitering"), so it is probably the way to go (i.e. eventually replace choropleth-layer with enhanced-choropleth-layer)

from deck.gl.

@ibgreen Would that work for arcs too?

from deck.gl.

Would that work for arcs too?

Arcs require 3D extrusion (think a thin "tube" rather than just a flat strip), so we need to create more triangles, and mitering (joining) tubes requires a bit more care than joining flat strips. But yes, we could absolutely have a layer that "tessellates" arcs.

from deck.gl.

Couple of examples with 3.x:

There's 25K dots on this map, but none of them are visible due to the scaling.

Zooming in more makes them kind of visible, but still way too small.

Zoom in a little bit more and they become huge.

from deck.gl.

@contra There are two ways to set the radius - getRadius accessor returns radius in meters of that particular point (default 1) and radius is a multiplier (default 30).

You can make them visible in the zoomed out mode by making the radius bigger, but they will of course become even bigger as you zoom in.

We could change the layer to work differently, or have more options - we just need to agree on how we want it to work.

• Do you want the points to always occupy a certain number of screen pixels, regardless of zoom?
• Would you like to be able to specify min and max sizes for them?
• etc...

from deck.gl.

@ibgreen How do you feel about this? Feels a little funny mixing units but can't think of any other way.

new ScatterPlot({
  radius: 3, // meters
  minRadiusPixels: 10 // pixels
  maxRadiusPixels: 20 // pixels
})

This solves all of the cases.

from deck.gl.

@contra - Yes this looks reasonable.

• Maybe radiusMinPixels etc in case we need to specify screen size limits on multiple props.
• These props could default to 0 and say 10000 (something big enough to cover today's screens).

from deck.gl.

Will work on a PR, hopefully I can do this without having to mess with the shaders - no idea how to work on that stuff.

from deck.gl.

@contra Looking forward to the PR, but I do suspect it needs to be done in the shaders.

You need to make sure the props get set as uniforms when they change, declare the new uniforms in the vertex shader, then clamp the intermediate scaled radius value in the shader.

You can always give it a try - it should be easy to just extend the existing code - and I have seen several people here getting hooked on shader programming after having their first ever go at modifying an existing deck.gl layer.

If not - maybe you can put together some of those layer docs we talked about, and I could give this a whirl :)

from deck.gl.

I wanna plus one @ibgreen suggestion to modify the radius. I've have reasonably good success with correlating the zoom level the radius multiplier level

from deck.gl.