This patch introduces a new plotting style 'sectors' which plots an annular sector segment per each data.
The patch file on the latest source tree is the attached file 'gnuplot_sectors.patch'.
See also the attached file 'About_Sectors_Patch.pdf' for more information about the patch.
The script 'figures.gp' that generates the figures for the patch document is also attached.
I hope you will consider accepting this patch.
That looks really nice.
I am currently testing it in a private branch and would be happy to merge it after testing and resolving any problems. Oh, and it will need a section in the user manual as well.
I made a demo from your figures script which runs fine interactively. Some of the figures probably belong in the user manual rather than a demo, but that can be sorted out later.
So far I found a couple of minor issues that were easily resolved (see attached patch series).
There is one issue that I have not figured out. If I use the postscript terminal to run the demo, some of the plots come out with artifacts (extra lines that should not be there). I attach a copy of the resulting postscript file. I have not yet figured out what the problem is. Maybe you can spot it. Or maybe it doesn't happen on your machine?
Thank you for reviewing the code so quickly and
for your time and effort in fixing some of the issues.
I was able to reproduce the Postscript terminal issue myself.
I have found the cause, but can't find of a way to deal with it.
Causes :
PS_vector() in Postscript terminal inserts "stroke X,Y M" to separate the output of consecutive line segments by MAX_REL_PATHLEN(250). And finally, "Z", i.e., closepath is called. When drawing a polygon with more than 250 line segments, "stroke" creates a new path at the 250th vertex and tries to close the path at last vertex. Therefore, the line between the last point and the 250th vertex will appear as an artifact.
I have fount another issue.
When drawing "sectors" without fill, the same outlines are drawn twice.
This is because do_sectors() is called twice in plot_sectors(). The same phenomenon occurs in plot_circles(), which calls do_arc() twice.
I think I have fixed the postscript terminal issue.
Are you sure about borders being drawn twice?
For circles, one call to do_arc() passes style=0 which calls draw_clip_polygon() to draw only the border, the second call to do_arc() passes style!=0 which calls term->filled_polygon() to draw only the filled area.
For sectors it may be a bit more complicated because I see there are two call sites for draw_clip_polygon(). But it looks to me that the first site is called only if the sector is a complete circle and the second site is called only if the sector is a wedge. Is there a command or style setting that causes the border to be drawn twice for the same sector?
Never mind, I see it.
The first call to do_sector passes
style
but ifstyle == FS_EMPTY
that is the same as passing 0.And you are quite correct. plot_circles() has the same duplication.
Good catch!
I have pushed this wonderful contribution to 6.1 (master branch).
I made a first attempt at documentation based on your examples and rationale statement. Please have a look and offer any corrections / suggestions / comments. I have credited you for the fix needed in order to not draw empty circles twice.
Not yet done: Add some or all of the demo plots to the collection on the gnuplot web site.
Add the new style to the 6.0 branch also.
Question: I am a bit confused about the interpretation of input data columns 5 + 6 in the case of
set polar
. I documented it as being x/y coordinates, but a bit of experimentation indicates this is not correct. What was your intent?Thank you for merging the patch.
I am very happy to hear that.
Answer to your question:
I did not consider the use case of specifying the 5th and 6th columns as the center position in polar mode, other than the origin. My intention is that in polar mode the center position is fixed to the 0,0 origin.
To be honest, I had simply implemented it so that the graphic coordinates would be obtained from the 5th and 6th data in the specified coordinate mode (polar or not) and the graphic would be drawn with that position as the center.
I think it would be easier for users to understand that in polar mode, the center position is fixed at the origin, and the reference point for the sector segment is specified by polar coordinate. If the user wants to shift the origin, they should be encouraged to use the cartesian mode.
For example, would it be possible to prohibit (warn) the 5th and 6th columns in polar mode?
Or modify the manual to describe it as currently implementation.
Another point of view.
The reason for supporting polar mode is that it is intended for superimposition with other plotting styles, such as points, lines, labels, etc., and it is more convenient to do so in polar mode.
Sorry. I got a little confused too.
In Fig.2, I already used columns 5 and 6 in polar mode to shift some segments of the dounut chart along radial direction .
In cartesian mode, it is a bit troublesome to do this.
I think you mean Fig 3?
Fig. 2 shows exactly how to do this in Cartesian mode. It shifts the two halves of the polar plot by displacing them +/- ½ along the x axis. If you do
set polar; replot
there is instead no apparent displacement of the two halves. That was where I started to get confused. If I doset polar
and change the Fig 2 plot command to use offsets in column 7 rather than column 6, it results in displacement along the vertical. That makes it looks like column 7 = y (Cartesan) rather than column 7 = R (polar). I tried experimenting further and just got more confused. That's why I asked what the intent is.I agree that Fig. 3 shows why you might want radial displacement. However the code in the script does not make it at all obvious what is going on. To me the more intuitive way to create a chart that looks like this would be to vary the radial coordinate of the corner point (column 2) rather than shifting the origin. I realize this doesn't produce exactly the same result, but it is what I (incorrectly) thought the plot was showing.
The type of chart in Fig 3 would actually be easier to produce if the sectors were defined in terms of their midpoint rather than by a corner. Then the displacement would be easier to describe. I'm not suggesting to go back to the beginning and redefine sectors; just pointing out that this figure is not the best one for illustrating how displacement in polar mode works. I think it would be clearer to have something analogous to the first figure in https://gnuplot.sourceforge.net/demo_6.0/circles.html , where visually similar radial plots are centered at different places on the figure. Can you think of a real-world example of such a figure in polar mode?
Last edit: Ethan Merritt 2023-03-06
Sorry, You are right. It was Fig.3, not Fig.2.
My explanation in 'About_Sectors_Patch.pdf' was insufficient. In this document, columns 5 - 6 are labeled center_x and center_y, but in "polar mode" they should be center_t and center_r. You already modified document in source tree.
For the current implementation, to obtain the same figure as Fig. 2 in "polar mode", write columns 5-6 of the plot command in polar coordinate as follows,
Here, I used the image of "addition of offset" rather than "shift of origin". In any case, your point makes me think that a donut chart drawn with some segments shifted, as in Fig. 3, is not appropriate as the first one to show. These segment shift means only fancy emphasis, so it is not essential to the application.
It is difficult to come up with good examples.
pie_with_pies.gp
This is a fairly artificial example, but I have created a chart of Yes/No survey results aggregated by group. I drew a large Pie chart with the number of people in the group, and smaller Pie charts with the survey results within each group, placing them in polar coordinates.
geometric_diagram.gp
This is just for fun, a diagramatic figure using circular sectors.
I think there are very few practical examples of "sectors" style in polar mode, where the origin must be shifted. For a simple example, pie(donuts) charts arranged in a circle at equal intervals might be sufficient.
In the donut chart part of 'demo/sectors.dem', I modified it to show three patterns of donut chart.
I hope you will apply this change if it will help to eliminate some of the confusion.
Great. Thanks. Applied to 6.0 demo collection