Let's say that I have two Raster objects (or any other Holoviews object really). I can easily visualize one with appropriate color scaling, and I can do a layout to get both figures with the same scaling and coloring. What if I want to do two figures (e.g. because I need them on different pages), but with the same coloring and scaling so that the figures are comparable.
If there's no way to do this automatically, is there any way to access the relevant settings and then feed them manually to the second figure?
If you're using a notebook: The %opts line magic : IPython specific syntax applied globally [string format]http://holoviews.org/user_guide/Customizing_Plots.html and I think hv.opts works globally in script.
For both backends, you can do hv.renderer('bokeh').get_plot(your_element_variable).state (or replace bokeh with matplotlib) and get the original bokeh/matplotlib items.
Then you can use matplotlib's plt.getp() or bokeh's attribute calling (as I've done here https://github.com/ahuang11/holoext/blob/master/holoext/xbokeh.py#L501-L508) to get the base item's color/font/labels/etc.
Related
Below, you can see two barplots I've superimposed in order to better see the contrast. Both barplots were generated using identical code (different data, but this is unimportant) in two simultaneously opened Jupyter Notebooks. The code for both calls 'C3' as the color, but as you can clearly see, this displays differently in both notebooks. This is the case with both the inline and the plt.savefig versions of the images. I have also tried other colors such as 'C0' and get similar slight differences.
Any ideas what might be causing this and how I might remedy it? Thanking you all in advance.
Per the color documentation the CN syntax is used to index into the current color cycler. Since RGB codes work and CN doesn't, it leads me to the conclusion that somehow the different notebooks are using different color cycles. Try the following snippet in each notebook and see if it gives you a different answer:
import matplotlib as mpl
print(mpl.rcParams["axes.prop_cycle"])
I think it's likely that somewhere in one of the notebooks there's been a call to set_prop_cycle() that has somehow changed the cycler that is being used. Also check out this post for more info on selecting the colors via the cycler.
The short answer would be to avoid the 'CN' notation.
I am building a simple python application without GUI, in which I wished to add some colors, which I was able to do with the help of some modules like termcolor, tqdm, simple_colors etc.. I also need a way to increase font size in the print statement whenever necessary. It would be good if someone also can tell me if there is a way to use different font styles at required positions rather than changing the font of the entire application.
This is a follow up to my post three weeks ago here How do I use m_map in octave, without really being a nuissance to kind and busy people. My problem is simply how does one overlay a basemap on an octave contour plot. After interpolating my irregularly spaced data (works for both contour lines and filled contours) I plot with the code:
contour(xi, yi, obsi, cstart:cstep:cend)
colorbar;
xlabel('Longitude'),ylabel('Latitude')
title('Mean Rain Onset')
saveas(gcf,'rainzam.pdf')
And I get
I have downloaded several map formats: ne_50m_admin_0_countries.zip, the apparently obsolete m_map (with associated tbase.Z, gshhg-bin-2.3.2.zip), soa.7z, world-bounds.7z, gshhg-gmt-2.3.2.tar.gz, dcw-gmt-1.1.1.tar.gz.
My question is has anyone used any of these maps in octave or gnuplot, and how to? I would appreciate any assistance.
Basically you have to load those maps in octave, they represent borders or coastlines with two variables (x,y) which you can then add to your plot with
hold on
plot(x,y)
That's the easy part, the hard part is to load the maps. All of them have different formats, which means it is a completely different story how to load them. For instance, the ne_50m_admin_0_countries.zip has a dbf format. Either you convert it first to ascii text and load it easily with the load function of octave or you need the OI package (http://wiki.octave.org/IO_package), which in turn demands java (http://wiki.octave.org/Java_package). I don't think this is the easy way for a newbie, so I suggest to convert the maps individually to text: google for "convert dbf to csv", "convert dbf to text", "convert dbf to ascii", etc... Perhaps some of those maps can be even loaded with excel and then saved as text (csv), the important issue is to convert them to text!
If you want to draw physical coastlines, you may download them from this link
https://www.naturalearthdata.com/downloads/
Then, after the drawing of a contour map of your own datas, you may add the coastlines using the following commands:
pkg load mapping
hold on
h = shapedraw ('FileName.shp','r','linewidth',1)
In this Kivy garden Plot module, a texture parameter is passed to a Line() constructor, and subsequently used for anti-aliasing. I couldn't find any documentation on this argument in the official docs. From looking at the source of Line, it looks like this parameter is not parsed altogether.
Is this a legacy parameter? If so, how was it used and how can this functionality be achieved now?
This works because the SmoothLinePlot is using a custom fragment shader, defined here. This uses the information in the texture to achieve the antialiasing effect.
The normal Line actually does use the texture (actually all VertexInstructions can take a texture parameter and have vertices including texture coordinates), but in a trivial way that doesn't work for more than this antialiasing, and isn't taken advantage of by kivy's default fragment shader. This actually is covered in the source of Line, the texture property is checked here, and the information about what texture coordinates to use is set when constructing the vertices later, e.g. here.
Assuming you're using kivy master (some of these changes are recent, the Line used to only parse the (0,0) coordinate of the texture), I think you should be able to see this in action by assigning a texture to any line. I'm not sure what effect you'll see, as the texture is mapped along line segments, not the whole line, and in a way that may not give visual consistency.
I'm using d3 to draw a bar chart, where the bars are used to compare different groups (e.g. men/women). For the filling I take a color which is saved in the data file (json) and vary it using d3.rgb().darker()/.brighter().
.attr("fill", function(d){return d3.rgb(d.color).darker(1);})
It works in Firefox but in Internet Explorer 9 all the bars are shown as black (which is the first used color). I was wondering if this is just an issue with this browser in particular or if I am missing something to avoid this behavior.
One solution would be of course to assign the colors individually, but if possible I'd like to use the provided possibilities.
This happens because you're using attr("fill") instead of style("fill") to set a style property.
The style function includes some additional checking to turn a property value into an appropriate string if needed, so you wouldn't need to do the toString() yourself manually.
Changing your original line to:
.style("fill", function(d){return d3.rgb(d.color).darker(1);})
should work on all browsers including IE.