Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
Hello (especially to people from RSI if they are sneeking in), today I finally got around to take a closer look at the IDL axis handling and spend some thoughts on what I would wish to see in a future release of IDL. Maybe one or the other of you would like to comment or contribute so that we could end up with an even better solution. Th eordering does not express any ranking but is meant to facilitate references. Basically I find that one can very well live with the general scheme of !X, !Y, and !Z variables and all those hundreds of parameters that can be passed to plotting routines. However, I think some tasks could be greatly simplified if the behaviour of some of the elements of !X, !Y, and !Z were slightly changed, and a few more items were added as well as a few more keywords allowed to the plotting routines. Here are my suggestions: !X[YZ] variables: ----------------- (1) !X[YZ] should contain an extra field with their COLOR (index). Additional options would be a field for TITLECOLOR and LABELCOLOR (2) the !X[YZ].STYLE fields should have an additional NOLABEL flag which would have the same effect as TICKNAMES = " ", but is somewhat easier to use and remember. If TICKNAMES is set to " " this NOLABEL flag could automatically be set. (3) !X[YZ].THICK = 0 (or -1) should draw no axis (it's kind of logical, or not?) (4) !X[YZ].TICKS = -1 should prevent tick marks (and minors) (5) !X[YZ].TICKLEN = 0 should also prevent tick marks (6) !X[YZ].GRIDSTYLE = -1 should be default, whereas a GRIDSTYLE ge 0 would automatically set TICKLEN to 1 except if TICKLEN is explicitely given (7) !X[YZ] could sometimes use an additional OFFSET or SHIFT field which for !X would specify an offset in Y, and for !Y an offset in X (haven't thought about !Z). Together with the additional PLOT options I propose below, this would allow easily to draw plots with multiple (more than 4!) axis. (8) two (or three) additional system variables should be !XTOP and !YRIGHT (!Z???) to hold axis information on the secondary axis. Structure identical to !X[YZ] additional keywords for PLOT etc.: ---------------------------------- (9) /XBOT, /XTOP, /YLEFT, /YRIGHT would tell PLOT to use (only) the specified axis. Default would be having each pair identical (i.e. draw a box as it is now). If e.g. /XBOT is set, PLOT should only draw the lower X axis. A subsequent call with PLOT,...,/XTOP,/NOERASE could then be used to add data to the plot drawing and using the top axis only. I recognize that some thoughts would have to be spent on how to handle the "other" axis, whether to simply overdraw the previous one or omit it. But since I am not paid by RSI ... (10) XAXIS=XAXIS and YAXIS=YAXIS would be two keywords which allow passing of an axis structure to the plotting routine. In this case the routine(s) should retain the old values of !X[YZ] and use the given definitions instead. This way one could easily define a set of axis for various plots and then pass them along without having to extract all the keywords individually. If then e.g. the COLOR element of !X[YZ] were included, it would be possible to produce a plot with different colors for the data and the individual axis in one command. A subsequent PLOT without these keywords would then use the original !X[YZ] structures again. (11) If the /NODATA keyword is set, PLOT (or the other routines) should work even if no data is passed, i.e. create some dummy data within the routine or catch this error otherwise. (12) It happens ;-) that the default position of TITLE does not lead to sophisticated results, or one wants to have multiple lines with various character sizes, etc. For these instances, it would be very helpful to have an additional coordinate system which would be similar to NORM except that 0 and 1 would specify the boundaries of the plotting window itself. This helps especially when annotating plots in a !P.MULTI environment. It would allow better use of subroutines which produce a complete plot on a single page: they could more easily be embedded in "programs" which set up the !P.MULTI variable, open a device, and produce a number of plots. Currently one has to take special care and perform some weird calculations in order to place these labels correctly. A WINDOW coordinate system would allow a more consistent relative positioning. I tried to keep the changes as minimal as possible in order to ensure compatibility between this dream version and the current release. If I am not mistaken, any "old" use of the plotting parameters should still give the same results. The only incompatibility might arise if someone uses a copy of say !X, re-creates this like !MYAXIS={ ... } and tries to copy it back into !X. That would obviously miss the additional tags that I proposed. Looking forward to some discussion, Martin. ------------------------------------------------------------ ------- Dr. Martin Schultz Department for Earth&Planetary Sciences, Harvard University 186 Pierce Hall, 29 Oxford St., Cambridge, MA-02138, USA phone: (617)-496-8318 fax : (617)-495-4551 e-mail: mgs@io.harvard.edu IDL-homepage: http://www-as.harvard.edu/people/staff/mgs/idl/ ------------------------------------------------------------ -------
David Fanning wrote: > R. Bauer (r.bauer@fz-juelich.de) writes: > >> Who knows the mechanism which axis is using to calculate the perfect >> ticknames of the tickmarks? > > Not I. But why would you want to know? If you wish to > modify it in some way, it is as simple as writing your > own tickformat routine and calling it with the [XYZ]Tickformat > keywords. > The mechanism is quite good e.g. PRO tst_range a = findgen(6)-1.5 b = sin(a) plot,a,b,/xstyle,/ystyle END In this example the xrange is [-1.5 ,3.5] and the label algorithm knows that it should not begin labeling by -1.5. I know using of functions called by tickformat may be able to do the same. -- R.Bauer Institut fuer Stratosphaerische Chemie (ICG-1) Forschungszentrum Juelich email: R.Bauer@fz-juelich.de
R. Bauer (r.bauer@fz-juelich.de) writes: > Who knows the mechanism which axis is using to calculate the perfect > ticknames of the tickmarks? Not I. But why would you want to know? If you wish to modify it in some way, it is as simple as writing your own tickformat routine and calling it with the [XYZ]Tickformat keywords. Cheers, David ----------------------------------------------------------- David Fanning, Ph.D. Fanning Software Consulting E-Mail: davidf@dfanning.com Phone: 970-221-0438 Coyote's Guide to IDL Programming: http://www.dfanning.com/