deck.gl: Mitering bug: PathLayer produces uneven strokes if the path has acute angles

Deck.gl verson: 46add427dd7d2f132f5699e38edcc90802f3fc30 (dev branch)

Steps to reproduce

Create a PathLayer as follows:

const path = [[-81.29868341618506,41.1053559416184],[-80.97694,41.10014],[-80.82915,41.10922],[-80.84265,41.11511],[-80.76570077085131,41.05483762281574]]

const layer = new PathLayer({
      data: [{path}],
      opacity: 1,
      miterLimit: 1,
      strokeWidth: 6e3
})

Zoom in on Ohio

Expected result

Smooth path.

Actual result

Uneven-width path. See screenshot above.

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 16 (7 by maintainers)

Most upvoted comments

@dcposch the PathLayer is already using pre-allocated typed arrays.

Unfortunately the current deck.gl layers are designed to be projection-agnostic, which means we do not know which side of the vertex is going to be an acute angle when we generate the attributes. I’m doing some experiments on this.

I can see your third suggestion having cool use cases, though utilizing depth test will disable opacity blending, thus breaking some other scenarios. Seems like this could be done easily by subclassing the layer and overriding the shader.

Pessimistress on Feb 8, 2017

I think this issue is closed based on fixes from @Pessimistress

ibgreen on Feb 16, 2017

I think if you clarified that Deck.gl is strictly for geospatial data visualization on top of Mapbox, Mercator only, it might make it easier to get to a place where it’s really solid and stable.

@dcposch That’s good feedback and I understand where you are coming from. At this point let me confirm that geospatial is absolutely the primary use case for deck.gl and any support for other use cases should not compromise this. That said, I’d like to see more concrete examples of things that will be technically significantly easier if we did this.

Yeah, I’d agree with you on that. It would clean up a lot of complexity if deck.gl focused on geospatial displays and dropped support for everything else.

@contra Really value your input especially since you’ve been an active user since the start. Apart from my comment in this ticket, do you find the messaging around deck.gl unclear? Is there anything you feel should be dropped at this point from the current releases? Or is this mainly forward looking comment? I would hate to muddy the waters.

Also curious if anyone is using this for non-geospatial use cases - if so I’d imagine they would use something different.

All I can say is that we are building some pretty amazing “hybrid” apps internally on top of deck.gl (unfortunately not something I can share more about at this point) and we are also finding that deck.gl’s “reactive” programming model, and the ease of packaging WebGL visualizations as reusable layers extends well to other use cases. There is of course a debate about these topics here internally as well, so your input is timely!

ibgreen on Feb 8, 2017

@dcposch Yeah, I’d agree with you on that. It would clean up a lot of complexity if deck.gl focused on geospatial displays and dropped support for everything else. Also curious if anyone is using this for non-geospatial use cases - if so I’d imagine they would use something different.

yocontra on Feb 8, 2017

using Deck.gl with a projection different from the Mapbox default?

As to the technical challenges, it involves:

generalizing the viewport system to allow for viewports created from arbitrary view and projection matrices rather than a list of mercator properties (lat,lng,zoom,pitch,bearing, …).
Updating the GLSL shader project/project64 modules that depend on uniforms generated by the above viewport to handle all cases
separating event handling from the map (possibly providing one or more reference interaction models). Also we have to produce good documentation on all the above to make all this power easy for users and layer writers to understand. And make sure not to break existing code. So it is a non-trivial amount of work.

ibgreen on Feb 8, 2017