Minor mods.  New plot option: forceSingleAxis.  This instructs the SOS.Plot object (& overview plots, such as for SOS.Table) to use a single y-axis (range, label etc.) even though there may be multiple data series.  For example, this is useful when plotting the min., mean & max. of a given observed property, but don't want three y-axes.
Bugfix.  To fully remove a dialog from the DOM, we need to do destroy, followed by remove.
Bugfix (reported in private communication).  The app tries to plot data as soon as it has the required parameters, which is good.  However, upon subsequent selection of a different offering, say, it will still have all its required parameters (from previous selection, but with the new offering) and so attempt to plot again.  If both offerings have the same observed property then this will work, but if they don't, then you get a bogus "offering with no observed property" entry in the plot legend, but of course no curve on the plot.  Now, when checking if we have required parameters to plot, we also check that the given offering has the given observed property.
The app has a built-in default date range (one month), meaning that as soon as foi/offering/observed property are selected, it has the required parameters to plot.  This is a convenience to allow the user to see some initial data in as few clicks as possible.  However, this implicit date range was often a cause of confusion, as it was hidden.  Now, we initialise the date range controls with this built-in date range, so it's clear to the user what data they will plot.
Bugfix.  If the date range was chosen before clicking on a FOI/offering, then that chosen date range was "forgotten", because a FOI/offering selection initialises a new selected item.  Now, when checking that we have the required parameters to plot, we ensure that the current item is updated with the latest values from the datepicker controls (rather than only on the datepicker change events).
Minor mod.  It's probably useful to return the updated current item.
Bugfix.  When using the forceSingleAxis plot option after having already plotted with multiple axes, the previous first y-axis was incorrectly preserved instead of creating a new (single) y-axis for the newly chosen data.  This is now fixed by emptying the yaxes array before setting the single y-axis.
Added a reverse logarithmic transform for plot's y-axes.  This is useful for upper air soundings, for example.
Minor mod. to stylesheet for square plots (such as the thermogram plots - Stuve & SkewT).
Minor mod.  IE 11 doesn't see the timePeriod member from a SOS temporal coverage response for a selected FOI (although it does respond to the event).  In this case, we just don't update the info box content.
Minor mod.  The metadata infobox now explicitly states which coordinate is longitude, & which is latitude, when selecting an FOI from the map.
Minor mod.  A toolip (using the title attribute) is optionally added to all SOS.Menu entries (select listboxes).  Useful when the text is longer than the width of the listbox.
When formatting a get observations request (XML), IE 11 inserts some extraneous markup related to namespaces (e.g., xmlns:NS1="" NS1:...  etc.), which causes the request to completely fail.  This is a workaround to overcome this.  See: http://osgeo-org.1560.x6.nabble.com/WFS-and-IE-11-td5090636.html
Added new plot type.  A Stuve plot is one of a number of standard thermodynamic diagrams, commonly used for visualising upper air data.  Note that it doesn't (yet) have full support for all aspects of a Stuve plot, such as moist adiabats or mixing ratios.
Minor compatibility mods. (IE8).
Further to commit 63ad8fe39654dd06fcbd657a7d5ff269e8fbdd08.  The xml request issues under IE11 were more general than just get observations calls, hence these mods. address issues with constructing the other requests also (such as get FOI, describe sensor etc.).
Added a mechanism so that all observation data display components can consistently report diagnostic messages.  Now, if no data are available for the chosen date range, the component will report this fact, rather than producing an empty plot/table.
Simplified the diagnostic message mechanism a little (see previous commit).  The ability to prepend a message-level heading still exists, but isn't added by default (so would need to be overridden at the app level, if required).  This makes it easier to internationalise the messages, by just replacing the message strings, without having to override methods.
New SOS.Proxy object.  This allows configuring and enabling/disabling the (OpenLayers) proxy at runtime.  Useful for those sites that are setup for CORS, but don't have a proxy setup.
We now use a different service endpoint for GET and POST requests.  Upon instantiation of a SOS object, the caller sets the GET URL (as previously), and by default the POST URL is set the same as this GET URL.  Upon fetching the service's capabilities (via the GET URL), the service's POST URL (for XML encoded request/response) is parsed from the DCP section and stored.  This POST URL is then subsequently used for all POST requests.  This allows for different GET/POST endpoints.  Note that this behaviour can be disabled by setting the sos.config.post.setUrlFromCapabilities flag to false.  See this issue for details: https://github.com/52North/sos-js/issues/3.