When displaying a box graph, pygal displays values outside of the normal zones. You can see the example on their site as well:
You'll notice that no values are above 16,000 or below -4000 (in fact none are below 0). It just doesn't display properly.
This is posted for anyone who doesn't look on the website for answers (which I don't usually).
There is a solution to this problem, and it is not resolved completely yet - but there is a quick fix.
In the meantime, to make it work (as expected) instantiate the object like this:
box_plot = pygal.Box(mode='extremes')
You'll notice that the above example will be solved, and in fact to my knowledge this is the only way to make box plots work.
To follow the issue: Link to the issue request
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 1 year ago.
Improve this question
I am making a bar chart in d3 but when I run locally and on Git it only shows the axes and not the bars.
Code and data: https://github.com/pshukl21/narrativevis.git
This can be frustrating! Looks like there are a couple of things going on, but the main thing is that your data had an extra line that was causing d3.csv to read it in improperly.
Here's the original, unmodified version of your code in a Codesandbox, only with that space deleted.
Delete the space and you can continue building your chart.
Solution:
A good thing to do when reading data into d3 is to do a quick sanity check by using the browser's developer console.
Using the dev tools to inspect, we can see that it looks like we're not getting a value that our D3 code expects -- it's telling us that the function that renders the rect is seeing NaN, which is a clue for where we can look.
And on closer inspection of the array that d3.csv creates, there's something off -- an extra row with no data. That appears to throw our entire array off!
Sure enough, turns out that Github was trying to warn us about this, too, but the soft colored, quiet warning is pretty easy to miss.
Once that's fixed, there may another problem -- we'll need to convert the values in career_WS to a number, or else our chart won't render and we'll get this helpful warning in the console:
We can do that by looping through our data and using the "+", which is a common replacement for parseFloat when working with D3.
data.forEach((row) => {
row.career_WS = +row.career_WS;
});
After we clean our data and make sure it's being read in, things are coming together.
It looks like there's still some work to do.
Fortunately, that is all in the implementation details -- it's not what your question was asking, but from here it's a matter of setting margins, setting scales, and rendering our chart.
Again, using the developer tools is a great way to understand what's failing. Hope this was helpful! ✌️
I am using r82.
I have a mesh with multiple materials. I can change their opacity just fine, but how they are rendered is what I would call "splotchy". I have been using ThreeJs for a while, and EDIT: was able to get the transparency working in a past version (r67) with the same model in a significantly more consistent way. So I was wondering if there is something that now I need to set that I didn't need to set before or if I am just overlooking something. Upon revisiting my older code and testing it again, I found that the same transparency issues were present. It was simply a matter of there not being as obvious "splotches" (and not testing enough, I'm sure). Here is a screenshot.
Here are a few more pictures I took that highlight the issue a bit better. I have the outside wall in a light grey and the floors a dark grey in the model and can toggle the outside walls to be visible or not. In these pictures I have one face of the outside wall purple and a face of the floor in the room on the other side of the wall green.
Based on the angle of the camera, it makes part of the green floor face invisible even though there is only one face between the camera and it.
The materials are all double sided already and there is no sign of this until the transparency is on. I found a similar question that suggested changing the mesh.setFaceCulling (or something similar) but that seemed to be from an older version and wasn't in r82.
Thanks for any help in advance!
EDIT:
I started looking into the old version of threeJS and the current version's source code to see what is done differently regarding transparency. I found transparentObjects, which is an array of the objects (I believe faces) that are going to be rendered and are in sorted based on "reversePainterSortStable". There is another list of objects (I believe for the materials objects, maybe?) called opaqueObjects that uses "painterSortStable". So to see if changing the sort order would change the outcome of how things are looking when transparent I changed it so that transparentObjects got sorted by "painterSortStable" and it did change how things showed up significantly (granted it didn't fix my problem since it just removed some problem spots and created new ones).
So the short version, it looks like it is an issue with the renderOrder of the faces.
That being said, I tried finding how the r67 version of the code handled the "renderOrder" of the faces since it wasn't something that (to my knowledge) could be set in that version and just did it automatically. But I have had no such luck tracking down how it was done as of yet.
So I see two possibilities. 1) find out how the past version correctly did transparency (at least for my purposes) and change the logic in the current version to use that. Or 2) find how to properly set the renderOrder of the faces based on the camera position in the scene. Will look into the second option first, but figured it would be good to document this for others looking to help answer or that have a similar problem.
EDIT 2:
So digging through the source code for threeJs and noticed something about the transparentObjects array I mentioned in the previous edit. The first, that I cannot for the life of me figure out how it gets populated since it doesn't seem like it is added to anywhere in the code. The second is that I think it is being populated with duplicates of the entire building object/mesh (see screenshot below).
The z indexes all seem to be the same. as well as the ids and the objects are all of type "mesh" (of the ones I looked through, granted, since there are a few thousand). So I was going to figure out why its adding what is being added to the array, but that is when I stumbled across the issue of not finding where in the code that the transparentObjects array actually get populated.
EDIT 3:
WestLangley, I tried setting the depth test for the outer wall material to false and got this. Like I said in my response comment, even if it did work it wouldn't fix the issues experienced with the camera inside the building, but wanted to follow up none the less (see snapshot below).
I am following this example of a difference chart. I've added buttons on my page that make ajax calls to fetch new datasets, and then I redraw the difference charts. There are several difference charts on my page.
Upon redrawing, the rendering of the above/below areas becomes corrupted: x-values have both above and below areas rendered. I'm fairly certain it's not a back-end problem, because the initial load produces a correct chart; changing a parameter messes up the redrawn chart; and going back to the default parameters and redrawing the original chart also produces a corrupted chart. In fact, I can partially make out what's happening: the original time series is present on the new graph. It's almost as if there are three series being graphed.
I think it has to do with .datum. I don't fully understand how it works, since it differs from the standard enter/update/exit methods associated with .data. I've read the documentation, but am still confused. Some possibilities:
The original data is hanging around (even though I clean out the container with $('#chart').html(''))
The .append(g) is adding groups without removing the earlier ones.
The svg.append("clipPath").attr("id", "clip-below") is causing problems, since multiple nodes have the same id (even though again, I'm not sure how this could happen since I remove the nodes before the redraw).
I feel like I'm missing a lot of fundamentals here, even though I've spent a decent amount of time trying to understand the library. Can anyone see anything obvious, or point out some good resources for me to look at?
UPDATE: This has to do with there being two charts on the page. I noticed this when I opened the inspector and closed it. The areas of the bottom chart (the difference chart) had screwed up, and I noticed the new line that it was using to separate the above-area from the below-area looked a lot like one of the lines from the top chart.
Does anybody have experience with dependency issues/namespace collisions when drawing two charts on the same page?
The problem was, the id's for the clipping paths were the same.
I would still like some more resources concerning .datum.
My crosstab looks fine in the web viewer but when I export to PDF it's clipping it like showin in the image. It's also making the columns much wider than they need to be. (The web version isn't doing that.)
Does anyone know how to fix it? I tried searching for an answer and didn't see anything.
Without seeing the parameters you're passing to your RenderTask it is hard to tell exactly, so I'm going to guess that you have PAGE_OVERFLOW set to CLIP_CONTENT rather than FIT_TO_PAGE_SIZE.
A note of caution though. This discussion on the Eclipse forum mentions that page-break interval settings might override the page size render options. Note that the OP on the linked discussion was having a problem with the PDF exported from the HTML viewer.
EDIT: according to the docs inside genReport.sh you are able to pass parameters on the command line (-p pageOverflow=FIT_TO_PAGE_SIZE) or you can create a parameter file (-F params.txt)
It is unclear to me whether you can pass the constant (FIT_TO_PAGE_SIZE) or must pass its expected value (2), so you might have to try both.
I think you have restricted the width/height of your report
goto Master Page then click on the general settings and there you find the type drop-down choose Custom.
Through this custom options you can give your own height/width of your report and too in the report layout.By doing this you can expand your report width
NOTE: The master page width should equal to the width of your layout.
I've encountered such a problem, and hope you guys could help me out here.
I have a plot in my GUI, contained multiple lines with different linspecs and a group of legends.
And I've made a context menu which should allow users to open the EXACTLY same plot(retaining all line settings, title, legends, and so forth) in a new window(default figure, where it is able to save/edit the figure).
However I couldn't find a simple way to migrate the plot, except re-run the plot commands which is quite complicated(plot different data, etc.)
So, I am looking for the solution in the following two ways:
is there a simple way to migrate the plot into new figure window?
or is it possible to save the plot directly with current interface?
For 2, I'd like to clarify that I only want to save the plot, not all GUI interface. I've tried saveas(handle.Plot,...) but it saved the GUI interface as an entity.
I hope the point has been made clear, thanks for your time. Cheers.
For this task you can probably use the builtin Matlab function copyobj which does exactly this (i.e. the first option mentionned in your question).
The following piece of code demonstrates its usage:
h1=figure;
a1=plot((1:100),rand(1,100),'r-');
hold on
plot((1:100),rand(1,100),'b+');
legend({'plot1';'plot2'});
h2=figure;
copyobj(get(h1,'children'),h2);
Hope it works as well in your case.
UPDATE: as far as I understand this, your second solution would involve the saveas function which unfortunately works with the figure environment and not with axes (as you experienced it). So a workaround would probably involve copying the desired axes to a new figure with the method given above and then use saveas.