Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 09:55
    PBrockmann commented #446
  • 03:48
    nvictus synchronize #939
  • 00:06
    jbednar commented #4567
  • Nov 23 23:59
    obust edited #4699
  • Nov 23 23:54
    obust opened #4699
  • Nov 23 20:31
    julioasotodv edited #1801
  • Nov 23 20:31
    julioasotodv edited #1801
  • Nov 23 20:30
    julioasotodv edited #1801
  • Nov 23 20:30
    julioasotodv opened #1801
  • Nov 23 20:08
    jlstevens commented #4567
  • Nov 23 20:07
    jlstevens commented #4567
  • Nov 23 20:07
    jlstevens commented #4567
  • Nov 23 19:39
    philippjfr commented #4567
  • Nov 23 19:36
    jlstevens commented #4567
  • Nov 23 19:36
    jlstevens commented #4567
  • Nov 23 19:23
    philippjfr commented #4567
  • Nov 23 19:22
    philippjfr commented #4567
  • Nov 23 19:09
    khider commented #446
  • Nov 23 19:01

    philippjfr on master

    Fix various issues related to d… (compare)

  • Nov 23 19:01
    philippjfr closed #4695
Marc Skov Madsen
@MarcSkovMadsen
(because you cannot say hv.plotting.....)
I want it applied to all plots. Not just individual ones
I also tried hv.extension("bokeh", logo=False) without luck. C.f. https://stackoverflow.com/questions/47585887/remove-bokeh-logo-in-holoviews
James A. Bednar
@jbednar
hv.extension("bokeh", logo=False) refers to the logo printed by hv.extension, not by each plot.
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).
Marc Skov Madsen
@MarcSkovMadsen
I've given awesome-panel.org a make over and upgraded to Panel 0.10. Checkout the changes. You can try out how the different templates and themes works by widgets in the header.
image.png
And if you just want to dive into the gallery of apps
image.png
Marc Skov Madsen
@MarcSkovMadsen
And remember this is running on one low end DEV/ TEST server in Azure. The performance is better on my laptop :-)
James A. Bednar
@jbednar
Very cool!
RaphyStark
@RaphyStark
Thank you for your answers! But it's very difficult for me... I keep your answers in the back of my head and will come here later if needed.
Good evening to you all and stay safe
James A. Bednar
@jbednar
I think it will be clear if you try it out interactively; you'll see what I mean!
If you are expecting this from the particles:
image.png
A physical robot will actually draw this:
image.png
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!
RaphyStark
@RaphyStark
Okay... So that's really difficult haha..
Okay thank you all again for your attentiveness !
Rich Signell
@rsignell-usgs
Best to stick with Python 3.7 when using holoviz? holoviz/holoviews#4667
James A. Bednar
@jbednar
Your call; the warnings are new, but the code involved hasn't changed, and behaves the same under 3.7 and 3.8, so while we do need to make sure the warnings don't appear, it's no worse under 3.8 than 3.7 otherwise.
Jon Mease
@jonmmease
@/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.
James A. Bednar
@jbednar
Sounds good to me!
Marc Skov Madsen
@MarcSkovMadsen
Marc Skov Madsen
@MarcSkovMadsen
image.png
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.
Jon Mease
@jonmmease
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.
James A. Bednar
@jbednar
pyproj is great for supporting arbitrary projections, but if it's just web mercator <-> lat,lon, then it's easy enough to write a Numpy function for that. E.g. datashader has utils.lnglat_to_meters (5 lines or so, and no Numba dependency).
I don't have the corresponding code for the opposite direction, but I assume it would be similar.
Jon Mease
@jonmmease
Yeah, adding a small implementation is fine with me too.
James A. Bednar
@jbednar
I think someone else requested it recently (Jean-Luc?), so having it in HoloViews isn't crazy, as bringing in all the dependencies of GeoViews is often a non-starter.
Jean-Luc Stevens
@jlstevens
this did come up recently
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
James A. Bednar
@jbednar
Right; my current version depends only on Numpy. I forget how I wrote that (years ago!); I think I just followed what Wikipedia said the conversion function was.
Jean-Luc Stevens
@jlstevens
as holoviews doesn't handle any fancy projections it should be possible to avoid other fancier geo dependencies
James A. Bednar
@jbednar
Right. I'm happy for such a function to go into Datashader, but really it's valuable even without Datashader, and HoloViews seems like the least common denominator here. Really it doesn't belong there either, but there's nowhere better it does belong, so...
I guess it could go directly into holoviews/element/tiles.py ; it would make sense there.
Jean-Luc Stevens
@jlstevens
happy for it to be there...or even a special classmethod on hv.Tiles (assuming heavy dependencies can be avoided)
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
James A. Bednar
@jbednar
Agreed!
Jon Mease
@jonmmease
Ok, thanks for the feedback!
Jon Mease
@jonmmease
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.
James A. Bednar
@jbednar
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.