Increase flexibility of archive calendar layout. about vesper

[HaroldMills]

This comment, which is mostly copied from a Simplenote note, documents a plan to increase the flexibility of the viewer archive calendar. The comment uses the following terminology:

• span - a sequence of consecutive months
• period - a span with a name
• archive span - span from the first to the last month for which there are data in an archive
• archive month - month within the span of an archive
• nonempty month - archive month for which there are data
• empty month - archive month for which there are no data

The current viewer archive calendar is not flexible enough for some kinds of archives. The current calendar shows month calendars for the span of an archive. This is fine for archives for which there are few or no empty months. However, it does not work well for archives for which there are long spans of empty months, including for example an archive that includes multiple years of migration data. For such an archive it would be better to display multiple spans in the calendar, omitting long spans of empty months.

To make archive calendars more flexible, I plan the following:

1. Introduce an Archive Calendar preset type. An Archive Calendar preset specifies periods to be displayed in an archive calendar. The months may be for particular years or not. For example, the YAML for a preset that defines spring and fall migration periods for any year might look like:

   - name: Spring
     startMonth: April
     endMonth: June
   - name: Fall
     startMonth: August
     endMonth: October
   

2. The user can select an Archive Calendar preset for a calendar, or no preset.

   • If an Archive Calendar preset is selected, the archive calendar will by default include all of the periods defined by the preset that intersect the set of nonempty archive months. Note that all months of a period are included, even if some of them are empty: the entire period is included if any of its months is nonempty.
   • If no Archive Calendar preset is selected, the archive calendar will by default include all nonempty archive months, grouped automatically into periods. The periods may include empty months if the grouping algorithm thinks that's a good idea, for example if there is a single empty month that is immediately proceeded and followed by nonempty months. The periods will be named automatically, for example "August-October 2014".

3. A combo box in the UI allows the user to query the calendar by period name, restricting the periods displayed. For example, for a calendar containing "Fall 2013", "Spring 2014", and "Fall 2014" periods, a query of "Fall" will display only the "Fall 2013" and "Fall 2014" periods. A query of "2014", on the other hand, will display the "Spring 2014" and "Fall 2014" periods. As another example, if no Calendar Periods preset is selected and the resulting automatically-generated calendar periods include one named "August-October 2014" as above, then a query of "Aug" will display that period, along with any others that include the string "Aug" in their names. A query of "Aug 2014" will display only that period.

   A simple query like those above matches a period name if and only if it matches any part of the name, ignoring case. So, for example, "Aug", "AUG", "aug", "gust", "g", "2014", and "0" all match "August-October 2014".

   We should define a little query language that can be used not only for calendar periods, but also stations, detectors, clip classes, and perhaps other entities in the future. At the least, the language should probably support operations like negation, disjunction, and conjunction. For more sophisticated users it might also support regular expressions. This would probably tie us to the regular expression facility of a particular programming language (e.g. Python or JavaScript), but I think that would be okay, and that it would even be okay for it to be different for a standalone viewer implemented in Python and a browser-based viewer implemented in JavaScript. It's an advanced feature.