The SOS.Map must use the POST service endpoint when populating the FOI layer, as now it may be different to the GET service endpoint (see commit 317e0afd768615b04f8a82d8de7207cf26910320).
Mods. to datetime handling.

A new function formats the datetime strings used in a get observations request, making it easier to override on a per-application basis.  By default, this function formats as ISO8601 without the subsecond component, for broadest applicability.

Also, the datetime parsing utility functions now parse timezone offsets, and shift to UTC.
Allow coordinate order in FOI layer CRS to be explicitly specified.

Allows an application to override the OpenLayers default coordinate ordering for a given CRS.

Also, a new event is fired after the SOS.App's components are initialised (sosAppInitComponents).  This makes it easier for an application to customise the components of the default SOS.App.
Optionally use a FOI Id to identify a single station in a multi-station offering.

For those data models that have multiple station data per offering, setting this option instructs the app to include the Id of the selected FOI (from the map) in a get observation request.  This then filters the offering result so that it returns data only for the selected station.  This is optional, because some applications may want all stations' data, for example, to plot a separate curve for each station.
Minor mods.  SOS.App datepickers are corrected to UTC.

The SOS.App uses jQuery datepickers to select a date range,  then adds time so that the interval starts at midnight of the selected start date, & ends at 23:59:59.999 of the selected end date.  A datepicker returns a javascript date object, with the client's timezone.  These mods.  correct the given date object to be UTC.
All standalone components can now optionally use a FOI Id to identify a single station in a multi-station offering.

For those data models that have multiple station data per offering, explicitly setting the foiId property instructs the component (SOS.Plot, SOS.Table, SOS.Plot.Rose etc.) to include the FOI Id in a get observation request.  This then filters the offering result so that it returns data only for the selected station.  If foiId is set null (the default) then data for all the offering's stations are returned.  This is optional, because some applications may want all stations' data, for example, to plot a separate curve for each station.
Changed SOS.App default option for including FOI Id in getObservations.

An option was introduced to allow conditional inclusion of a FOI's Id (when selected from a map) in a getObservations call from a SOS.App object (see commit d8891ba8f343427e75cb8da25e45de72e502bcda).

Originally, it defaulted to false.  This was so that the app would work as previously.  However, having it true by default means that for a single-station offering, it essentially works as before anyway (as there is only one FOI), whereas for a multi-station offering, it will only plot/tabulate data for that selected station; which is almost certainly what you would always want to do anyway.  As before, setting this to false will override this behaviour.
Show data for all stations of a multi-station offering, if no FOI Id is specified.

The main UI data display components (SOS.Plot and SOS.Table) will now show data for all stations of a multi-station offering, if no FOI Id is specified.  For example, say you have an offering with three stations, and you wish to plot them all on the same plot.  Then omitting a FOI Id, and setting the forceSingleAxis plot option, will plot each station's data as a separate curve on a single plot.

Along with these mods., a label template system has been introduced, to allow specifying which metadata to include in the labels of a SOS.Plot or SOS.Table (or derived display objects).  See the labelTemplates plot/table option for details.
Updated the documentation and examples pages, to reflect the latest code mods.