For questions, use https://discourse.holoviz.org/ instead! This chat is for informal discussions and debugging sessions with developers of the HoloViz.org tools (HoloViews, Datashader, Panel, hvPlot, GeoViews, Param, etc.), but user questions should go to the HoloViz Discourse site so that others won't have to ask them again.
I also tried hv.extension("bokeh", logo=False) without luck. C.f. https://stackoverflow.com/questions/47585887/remove-bokeh-logo-in-holoviews
I don't know a convenient way to disable it globally for all plots, but I agree that would be nice to have.
@RaphyStark, be careful using Attractors in that way, because the equations actually include discrete jumps that I don't think your robot can do. :-) Before using a particular pattern, use the https://examples.pyviz.org/attractors/attractors_panel.html dashboard and select a plot_type of "line" and not "points", to connect up between each point. When you do that, you'll see that the pattern changes dramatically, because the equations lead to big jumps in space from one discrete point to the next (for Clifford patterns; others have different properties). So first be sure you're dealing with a pattern that is meaningful to treat as a real trajectory.
Then when you do that, I'm not sure what you're after; you can always decrease N to have fewer discrete steps.
You can also take the output of datashader and sort the locations by aggregated value (most-visited pixels), but I don't see how that would map on to any commands to a robot; the equations themselves already work for that (if it can navigate to a named point in a grid).
And if you just want to dive into the gallery of apps
checkout https://awesome-panel.org/gallery
If you are expecting this from the particles:
A physical robot will actually draw this:
Because the robot will have to physically move between each successive location.
So don't expect results like in the first plot, only the second!
@/all I add the Dash HoloViews PR (holoviz/holoviews#4605) to the HoloViews 1.14.0 milestone. Could folks go through and populate this milestone with what they're planning to be included in 1.14.0? My request would be to aim to get
master into release candidate shape in ~2 weeks and then to get a release out early in the week of the 23rd (before the U.S. Thanksgiving holiday). Let me know how I can help out with review / testing of other PRs.
Talking about Dash. Here is abit of inspiratin https://community.plotly.com/t/dash-enterprise-fieldnotes-1-why-dash-enterprise/46608
Totally agree with the above https://discourse.holoviz.org/t/pipelines-user-guide-broken/1385. The examples on HoloViz.org should be working. Its a matter of trust.
I'm looking at adding Plotly support for the
hv.Tiles element, and one thing I'm running into is that the mapbox library that plotly uses expects coordinates in lat/lon (even though they are displayed in Web Mercator). In the past I've done this with pyproj. How would you all feel about the Plotly backend using pyproj as an optional dependency for the Tiles element? @philippjfr
I know it's overlap with GeoViews functionality, but it's pretty much 2 lines of pyproj for each conversion direction so it doesn't seem like a big issue to me personally.
I don't have the corresponding code for the opposite direction, but I assume it would be similar.
iirc the transform is in datashader without any big dependency...I would investigate how hard it is to get lat/lon <-> web mercator and nothing else without any geo dependency (but maybe numba as datashader depends on it anyway)
essentially that seems like the minimal utility in HoloViews that would exist to handle web mercator
I guess it could go directly into holoviews/element/tiles.py ; it would make sense there.
the only thing I would be against is expanding beyond web mercator and lat/lon...more sophisticated transforms are for geoviews to handle, not holoviews
So in Plotly, there is a
scattermapbox trace (for geo scatter plots) that's separate from the scatter trace. Are these the same thing for Bokeh? I'm wondering if I'll need to do something special in the overlay plot logic to check whether to convert the Scatter element into a plotly scatter or scattermapbox trace.
What's the difference -- geo projecting or not? If so that's the difference between hv.Points and gv.Points (or hv.Scatter and gv.Scatter, depending on whether y is dependent or independent). hv.Points can be overlaid onto hv.Tiles only if the hv.Points data is already projected into Web Mercator, while gv.Points can be overlaid on hv.Tiles or anything else, automatically reprojecting if needed. Sounds like since I think you said mapbox handles the projections internally, then hv.Points can be overlaid onto it even without reprojecting. so there's a bit of a mismatch here. Not sure how to handle that.
The difference is that regular plotly scatter traces can't display on top of a map. The scatter mapbox trace can be displayed on maps, and it only accepts coordinates as lat/lon. I was planning that the plotly backend would interpret the
hv.Scatter dimension values as web-mercator and would perform the conversion to lat/lon internall during display.
The slightly tricky part is that the Plotly data structures generated for
hv.Scatter will be of a different type when the hv.Scatter is overlayed with an hv.Tiles element.