click drag zoom should work on time axes, too - lets investigate this

[karlmsmith]

Reported by steven.c.hankin on 27 Jan 2013 01:46 UTC Click drag zooming on time axes already works on the SOCAT prop-prop viewer. Is it possible that it would be little effort to make the same work in the LAS V8 UI (e.g. on Billy's ZT plots)? Might it be that little more is needed than to communicate the time limits of the axis as numerical T values in the map scale file?

It seems worth investing 25 minutes to suss out whether this might be a quick fix. The setting of priority=high on this ticket refers only to the investigation. If the investigation shows that the fix will be quick, however, then that task to fix it deserves to be a high priority, too.

Migrated-From: http://dunkel.pmel.noaa.gov/trac/las/ticket/1495

[karlmsmith]

Comment by @noaaroland on 28 Jan 2013 23:32 UTC I have thought about this already. As Jon used to say it seems pretty straight forward. However, the general LAS context is a bit more complicated than the specific case that was implemented in pure JavaScript for SOCAT because of the greater variety of ways an axes can be specified. For example, in Billy's case the t-axis is defined as text strings. We already get what Ferret thinks of as the numerical values of the axis, the code that has to be written is that which schelps those values between the numeric values and text strings and then lines it up to the available time steps in the axis. If it's ok not to update the text menus until after the dragging is finished it's an easier problem to solve.

If it's the top priority, I'll start working on it, but if not we can take it up in 8.1.

[karlmsmith]

Comment by steven.c.hankin on 29 Jan 2013 00:34 UTC This makes perfect sense -- that the root problem isn't in the click-dragging on the map; it is in the synchronization of time positions between the image and the time widget. Before deciding whether this ought to be part of V8.0 lets think through the possible solutions.

On the image the click-dragging of T is just like any other axis. The T values are just numbers. The challenge is figuring out what the date-strings on the time widget correspond best to those numbers, right? (just restating what you said above) Suppose the map scale included the T0 date and the units (in effect, it included "days since 1-jan-1900"). Then the LAS UI would be able to translate the string values that it knows on the date widget into T values that correspond to the click-drag positions, right? It would know how to round out to the nearest time widget time range. Would this solve the problem?

A different challenge is that the LAS UI and the back-end understand the discretization of the time axis differently. The back-end has the complete representation; it knows of every time points. The UI has a subsampling of those points. (Ditto this for the Z axis.) This means that potentially the back end could send back a zoomed image with a date range T=3-jan-2001: 27-jan-2001 but the UI widgets would show it as Tlo=1-jan, Thi=1-Feb. So it goes ... I think we could live with this as an improvement over having no zooming at all. (Something like this must be happening on the Z axis now, right?) In another track ticket we should maybe start a discussion of ideas for making the UI aware of '''all''' of the axis points -- continuous slider widgets, Ajax queries and stuff like that.

[karlmsmith]

Modified by @noaaroland on 31 Jan 2013 16:29 UTC