das-developers / das2docs Goto Github PK

For years we've been talking about sending information for creating a GUI to define the "parameters" string for the Das2Server.

When Das2 was created, thick Java clients where the only Das2Server clients, so the client author didn't need a specification of the parameters. This was either the same person writing the data reader and the Java GUI, or two of us might exchange emails about how the parameters would be specified.

With Autoplot, a GUI provides a tool where the scientist can browse from available datasets, and when these are arranged nicely, this is effective. However, when the reader has special parameters, the scientist must look at the DSDF's param_nn properties and manually form this string for themselves. This is error-prone and tedious.

This ticket is to specify how these param_nn controls (or a new control) can be introduced to make the specification more precise so that a GUI can be created by the client. For example, with the Juno mission we often have controls like

param_02 = 'XMAS | If specified only output the Xmas flag'

which could be implemented as a checkbox with the string "only output the Xmas flag". (Note I did some interpretation there to remove "If specified".) More complex specifications would allow for a drop list of options, integer and float options, and strings with regular expressions. What other controls have we used?

This should also have a fall-back. For example, the Autoplot GUI will still have its "parameters" area, but I imagine it would have a button to press to enter a modal GUI, and the last text area of this GUI would be all the parameters it could not recognize. It would be ideal if this effectively supports existing readers for the Juno mission, but correctly and completely supports future readers.

I've pushed a version of the ICD with individual stream properties provided as sub-elements of . This version is on the branch named, appropriately enough "properties". This suggested improvement for das2.3 streams was not universally agreed upon, thus it is not on the master branch.

I think supporting this change is worthwhile and I can add code to handle it in libdas2 and das2pro in a couple of hours at most, but don't want to make this move unilaterally.

We've always intended to put in controls for how das2streams should be reduced, selecting between linear and log averages, for example. As data is produced by the server, it will be piped through data reduction filters which have generally done linear averages, which are then sent over to the das2 client and displayed in log-Z space. This results in odd artifacts and noisy results when there are just a few measurements in each bin.

The server can at least identify a particular reducer to select the correct method. For example, we could have a reducer which does geometric averages (averaging in log) on the server side, but there is no way for the das2 client (often Autoplot) to know that if the data is to be further reduced for display, that geometric averages should be used.

Further, there are other spaces which might be identified, for example "mod360" which means the average of 259 and 1 is 0. Also one might wish to indicate that the data can never be averaged, and nearest neighbor selection should be done or an error thrown.

CDAWeb has metadata for averaging, https://spdf.gsfc.nasa.gov/istp_guide/vattributes.html#AVG_TYPE which should be reviewed as well.