Surface graph has issue with small time ranges

[ShaneHudson]

Hello,

I've had an issue for quite a while and thought it would be good to raise here. It's an issue with graphs that are over a small amount of time. I've attempted to make a demonstration but the screenshot below will show my issue more clearly.

Take a look at the following:
A) https://jsfiddle.net/Lv4qpoyu/3/
B) https://jsfiddle.net/5au0xepd/1/

In A) you can see some random data over 50 minutes. In B) you can see random data over 50 seconds. A) works perfectly well, nice little graph. B) looks like an utter mess and is near impossible to use.

So that brings us to C), the screenshots (the first taken a few months ago, the second today) below that shows my real dataset. In a 2D heatmap it works fine but in a 3D surface graph it shows the data correctly but with the axis completely messed up. Sometimes it looks worse than others, but all the time there is a continuation of the date (y) axis. Sometimes it requires you to zoom out to see, but it is always there in the distance. This makes it unusable to me if I want to put it in front of users.

When I've looked online for help I found someone else having the exact same issue but they were using the python version of the library with a scatter3d.

This seems to be a bug opposed to an issue in my code. I have autorange set to false, the range of data is correct (["2018-09-06 20:48:32", "2018-09-06 20:55:57"] for second screenshot) and is using moment dates. I have double checked it on the latest version too and no change. Does anyone have any idea what is causing this issue?

Cheers
Shane

[ShaneHudson]

It looks like this may be related to #3155 but would appreciate any help on the matter.

[archmoj]

@ShaneHudson Thank you very much for reporting this issue.

[ShaneHudson]

Also another thing I've noticed, potentially related to this, is if there is no data on the graph but ranges are set on the axis then for the heatmap it shows correct ranges but the surface plot shows from 2000 to 2001.

[archmoj]

@ShaneHudson Could you please create a demo related to the second issue?

[ShaneHudson]

Thanks for doing that bug fix @archmoj. Do you have any idea when the next version will be published on npm please?

[archmoj]

My pleasure @ShaneHudson.
And thank you for using Plotly at first place!
Version 1.43.0 is setup and it would possibly be released tomorrow.
There are other bug fixes and improvements related to axis ticks & surface traces. In particular this PR should help improve the accuracy of data points on the surface. Although concerning small time-steps we are still working on the dataScale issue as well as local time offsets on 3D axes and webGL.
Therefore this issue is still open.
But until it fixed, one practical solution may be to use minutes instead of the whole date in the axis ticks and then add the date info into the axis label using a break line.
Now with this PR being merged, your graph could look like this demo.

[archmoj]

@ShaneHudson Also here is an alternative demo using superscripts & break-lines. Hope it may help.

[archmoj]

@ShaneHudson FYI - here is the new release v.1.43.0.

[etpinard]

@archmoj can we close this issue?

[archmoj]

@etpinard No. It is not fixed yet.

[ShaneHudson]

I've upgraded to the latest version of Plotly, so here's an updated graph. Looking across a minute.

[archmoj]

@ShaneHudson
Curious to know if you noticed any improvement?

[ShaneHudson]

I'm afraid not. I understand that the very small time scales are bound to throw it off, but the use-case is a raspberry pi that is uploading scans of radio frequency at regular intervals. The steps on the graph are caused by the scan being done in sweeps.

Another thing I noticed but probably related to this is that the 3D graph also struggles/fails when only one point in time is available. Is that expected behaviour?

[ShaneHudson]

Here's another screenshot.

[ShaneHudson]

Do note though that the bug does look different that it did originally, but my data has changed since then so I am looking at a small time range.

[wuyuanyi135]

+1.
https://codepen.io/wuyuanyi135/pen/bGNrvym
When the date difference is within one day, the display was problematic.

[jfftonsic]

The bug still happens, here is a simple plotly.py that reproduces this kind of error

import plotly.graph_objects as go
from datetime import datetime

s = go.Surface()
# s.x = ["2020-05-29T09:00:00","2020-05-29T10:00:00","2020-05-29T11:00:00"]
# s.x = ["2020-05-29","2020-05-30","2020-05-31"]
s.x = [datetime(2020, 5, 29, 9, 0, 0), datetime(2020, 5, 29, 10, 0, 0), datetime(2020, 5, 29, 11, 0, 0)]
s.y = [1, 1.5, 3]
s.z = [[0.5, 2, 2.5], [0.5, 2, 2.5], [0.5, 2, 2.5], [0.5, 2, 2.5], [0.5, 2, 2.5], [0.5, 2, 2.5], [0.5, 2, 2.5],
       [0.5, 2, 2.5], [0.5, 2, 2.5], ]
s.scene = 'scene1'

layout = go.Layout()
# the below assignment is just for the IDE auto-completion to work..
scene1 = go.layout.Scene(layout.scene1)
# scene1.xaxis.tickmode = 'array'
# scene1.xaxis.type = 'category'

layout.scene1 = scene1

fig = go.Figure(s, layout=layout)
fig.show()

which results in

I managed to find a workaround which is uncommenting the lines

# scene1.xaxis.tickmode = 'array'
# scene1.xaxis.type = 'category'

It will not fit every use case but... it's what I got right now after hours banging head on the wall.

[jackparmer]

This issue has been tagged with NEEDS SPON$OR

A community PR for this feature would certainly be welcome, but our experience is deeper features like this are difficult to complete without the Plotly maintainers leading the effort.

What Sponsorship includes:

• Completion of this feature to the Sponsor's satisfaction, in a manner coherent with the rest of the Plotly.js library and API
• Tests for this feature
• Long-term support (continued support of this feature in the latest version of Plotly.js)
• Documentation at plotly.com/javascript
• Possibility of integrating this feature with Plotly Graphing Libraries (Python, R, F#, Julia, MATLAB, etc)
• Possibility of integrating this feature with Dash
• Feature announcement on community.plotly.com with shout out to Sponsor (or can remain anonymous)
• Gratification of advancing the world's most downloaded, interactive scientific graphing libraries (>50M downloads across supported languages)

Please include the link to this issue when contacting us to discuss.

[hborchardt]

Hi, I would like to know if you are able to and would be interested in trying to move forward the related pull request that I opened in the gl-axes3d repository that you depend on? My main motivation in the PR is improving plotly :) and I saw that plotly maintainers are also maintaining some of the gl-vis repositories. @archmoj maybe?

[Quost]

Take a look at the following:
A) https://jsfiddle.net/Lv4qpoyu/3/

Hey, how are you doing? I found this issue, and there is something related to what I'm facing here.
You shared above a fiddle, and there is an axis label that is quite big, and this label enters the chart as you can see here:

I have some dates and would like to use them on my x labels, but it's not getting nice:

[positron96]

Any progress on this? I see there is a related PR for a project that haven't been updated in 4 years...

[hborchardt]

Hi @positron96 , I still like my changes in that PR. Currently the pipeline for my project that uses plotly patches the plotly bundle with those adjustments, which is not ideal 😄 but works. I can post the script later, in case nothing will happen.

[hborchardt]

Here's the patch as a bash script, to be called with the dist folder containing plotly as first argument:

set -x
PATH_WHERE_TO_REPLACE=$1;

# replace `* model * vec4(something)` with `* (model * vec4(something))` for better numerical stability in 3D graphs
find $PATH_WHERE_TO_REPLACE -type f -name "*plotly*.js" | xargs sed -r -i -e 's/\* model \* vec4\(([^\)]*)\)/* (model * vec4(\1))/g'