#506 Improved support for polar coordinates

closed-accepted
Ethan Merritt
None
5
2010-11-21
2010-11-08
Ethan Merritt
No

This series of patches addresses the current poor support for polar coordinates by adding features incrementally. Here is a summmary of the planned series. Not all of them are ready yet.

preliminary groundwork (will be added to CVS in advance)
- re-order internal structures so that real axes come before parametric axes
- Allow the set/unset log commands to affect only real axes
- Issue error message if polar mode does not support a requested plot style

polar_rrange.patch
- Treat "set rrange [rmin:rmax]" more like other axes.
- rmax establishes the limits of the plot axes, which are propagated to x and y.
- x and y limits can be separately adjusted later if desired

polar_log.patch
- Allow log scaling along the polar axis. This does _not_ set logscale on x or y.

polar_mouse.patch
- Echo polar coodinates while mousing

polar_scale_on_entry (not fully worked out)
- apply existing polar axis properly whenever polar mode is enabled
(otherwise you have to set polar first and adjust the axis properties later)

polar_rtics
- implement a separate "set rtics ..." command

polar_xerrorbars
- treat xerrorbars as radial arcs

Discussion

1 2 3 > >> (Page 1 of 3)
  • Ethan Merritt
    Ethan Merritt
    2010-11-09

    More things to fix in polar mode:
    - "set table" should write out value in polar coordinates, not x/y
    - "with filledcurves" currently ignores bounding conditions in polar mode

     
  • Péter Juhász
    Péter Juhász
    2010-11-09

    Good work!

    Will the separate rtics mean that the polar grid will be tied to that particular set of ticks and the grid won't disappear when I unset xtics?

     
  • I haven't started working on rtics yet. Mostly the goal is to be able to have logscale markings for the polar axis even though x and y are still linear. Yeah, I suppose that since the grid lines should go through the rtics rather than the xtics, turning off xtics should not affect the grid.

    I find that the arcs produced by polar mode "plot ... with xerrorbars" make a rather ugly plot, so I am wondering whether it is actually worth supporting this style. An alternative is to support "with xyerrorboxes" instead, which would produce arc segments with radial extent determined by yerror and arc width determined by xerror. I dummied up a plot like this and it looked both more pleasing and more likely to be useful. Unfortunately the order of drawing would need to be different in order to get a single pass outline of the curved polygon, so I'd have to start over again with coding it.

     
  • Péter Juhász
    Péter Juhász
    2010-11-09

    To be honest, I can't remember seeing any polar plots with X errorbars as arc segments in any publications, so perhaps it would not be too big an issue to omit that style.

     
  • Péter Juhász
    Péter Juhász
    2010-11-09

    This is different: the wind rose plot is an established style, but conceptually it's closer to a stacked histogram in a polar coordinate system, don't you think? (*)

    I was talking about this style:
    http://root.cern.ch/root/html/MACRO_TGraphPolar_1_CPol.gif
    I was referring to this when I said that this one could be omitted (unless you've already implemented it, in which case it could stay, for sake of completeness if anything).

    (*) now that I called it that, I'm thinking that perhaps there should be a new option for *histograms*: "set style histogram windrose", or something, which would automatically switch to polar mode then plot something like the figure you linked.

     
  • Ethan Merritt
    Ethan Merritt
    2010-11-09

    Right. I didn't mean that a wind rose was an example of xerrorbars. I just meant it's another polar plot style that isn't currently available. I agree that it is effectively a stacked histogram. Whether there's anything in the current histogram code that could be re-purposed to produce a wind rose is another question. That is, even if we added a style "histogram windrose" I'm not sure it would share much with the existing histogram code.

    It would be different if the code stored the un-transformed [angle,radius] rather than converting to [x,y] on input. If it kept the untransformed radius in the y slot, then the existing stacked histogram code would probably work in polar mode. That would require a complete re-implementation of polar mode though, not a set of incremental changes. Maybe not impossible...

     
  • Péter Juhász
    Péter Juhász
    2010-11-09

    > It would be different if the code stored the
    > un-transformed [angle,radius]
    > rather than converting to [x,y] on input.

    This goes on the "when we eventually re-implement the entirety of gnuplot's internals" file, but the approach of keeping the un-transfomed original data would help in many other cases as well. For example, it would allow the introduction of arbitrary axis transformations beside logarithmic that's the only one supported now. It would make possible a 3D plotting mode where the terminal driver (e.g. OpenGL) does the mapping instead of gnuplot.

    With this model, gnuplot would carry the original data through the plotting process, optionally applying a transformation, or a series of transformations, when the settings require them, and these transformations could be implemented on a common framework.

    Just an idea...

     
  • Ethan Merritt
    Ethan Merritt
    2010-11-11

    Apply existing axis properties when polar mode is toggled

     
1 2 3 > >> (Page 1 of 3)