You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is important for sharp turns in the data for two related reasons:
with only lines, it looks like the data point is more extreme than it really is
with markers+lines, the line seems to poke through the marker and then leave from the same side it came from:
(in case it's not clear: this is a black point on a red line on an existing scattergeo trace)
We should add this to scattergeo too, and investigate whether any other trace types need it. I suspect not though: scatterternary and scattercarpet inherit from regular scatter so should already have it, and the others are all webgl (cc @dfcreative I think we discussed this already at some point, it's at the very least a completely different kind of implementation)
I'll also note (in case this question comes up regarding any other trace types) that for contour lines we chose an even shorter miter limit of 1, because even if you specify no smoothing these are always modeling the data as if it were continuous and smooth - so we want to round off even sort-of-sharp corners.
The text was updated successfully, but these errors were encountered:
Cartesian scatter lines have a miter limit of 2 https://github.com/plotly/plotly.js/blob/master/src/traces/scatter/plot.js#L42
This is important for sharp turns in the data for two related reasons:
(in case it's not clear: this is a black point on a red line on an existing scattergeo trace)
We should add this to scattergeo too, and investigate whether any other trace types need it. I suspect not though: scatterternary and scattercarpet inherit from regular scatter so should already have it, and the others are all webgl (cc @dfcreative I think we discussed this already at some point, it's at the very least a completely different kind of implementation)
cc @etpinard
I'll also note (in case this question comes up regarding any other trace types) that for contour lines we chose an even shorter miter limit of 1, because even if you specify no smoothing these are always modeling the data as if it were continuous and smooth - so we want to round off even sort-of-sharp corners.
The text was updated successfully, but these errors were encountered: