Since the IIR filter implementation can do both High and Low pass, it has been renamed to IIR and options have been added to use it as either low or high pass filter. The documentation has been improved and stability constraints now lead to a warning message if the filter would start to be unstable.

The Butterworth filter has been replaced by a critically damped filter implemented as IIRLowPass that properly corrects for the phase (ie behaves as zero-phase filter).

Well, the Butterworth filter is changing a lot... It is not Butterworth anymore but a critically damped filter. Although the options are currently hard-coded, it will offer the choice of bidirectional filtering with a technique to suppress the overshoot that are created in this case (at the cost of higher computing time).

a zero-phase version of the two poles Butterworth filter has been implemented. This is based on backward/forward filtering. The problem is that this doubles the order of the filter and this seems to be too much for our signals (tested on HS).

better file structure: all the classes purely focused on data storage (such as grids, dates, etc) have been moved into a "dataClasses" directory. All subdirectories are nhow named similarly to the classes and methods: the words after the first one are capitalized.

The filters have been slightly simplified, some IOUtils functions optimized (after reading an interesting post about the handling of rvalues), a bug fixed in PNGIO on Windows, the macros MAX and MIN are not used anymore (relying on std::max and std::min instead). A new data generator is on its way to generate HNW from HS differences (but this will require architectural changes to the DataGenerator).

A low pass Butterworth filter has been implemented as a tentative answer to issue 308. Unfortunately, this filter has a non-null phase (ie the signal is shifted in time), meaning that for our applications, it is mostly worthless...

New warnings have been tried to detect variable shadowing (one variable declared with the same name as another one), alignement issues, etc. This produces very verbose output (not all warnings are legitimate) but allowed to fix lots of cases of misalignement and shadowing issues. These options have been left in the CMakeLists but NOT enabled (since these warnings are not so easy to interpret).

The last filters that had not been ported to the new filtering infrastructure have been ported and their documentation updated. All filters now use window specifications (instead of vector of pointers). The misleading filter argument "index" (for parameter type) has been renamed as "param" for all filters. The use of "unsigned int" for looping over vectors has been replaced by "size_t". The old "soft" behavior for the filters has been restored (ie: if not soft, a point that can not be checked by the filter is deleted).

A few more "consts" have been added.

The "RateFilter" filter has been renammed "FilterRate" in order to be more consistent with other filters (this does not change anything user-side). A new filter has been created, HNW_MELT. This applies the Snowpack criteria on a precipitation measurement: if relative humidity is not high enough or TA and TSS too far apart, it is considered that any measured precipitation comes from snow melting in the (unheated) rain gauge, therefore the measurement is deleted.

The last occurences of NROFSTATIONS have been deleted in BormaIO, closing issue 163.

Some code cleanup took place in CosmoIO and FilterMax.

In IMISIO, a new option and behavior has been implemented to properly manage precipitation measurements: ANETZ stations keep their HNW (they are considered reliable). IMIS stations by default don't produce HNW anymore. A key (USE_IMIS_HNW) can force using them, but a detection of winter conditions (ie: TA>0 and TSS>0) removes measurements known to be invalid. If neither TA nor TSS are available, then HNW is deleted (in order to prevent injecting HNW=0 in the system during a freeze event if the station would happen to miss TA and TSS). USE_IMIS_HNW should always be followed by the HNW_MELT filter.

Updated/improved some documentation for SNIO and the min/max/minmax filters. Using relative paths in CMakelists, since this should make VC++ put the files at the correct location.

Documentation update. A new section "how to build your io.ini configuration file" has been added to the end user section of the documentation.

The min and max filters have been implemented. The "how to write a filter" documentation page has been updated to relfect the latest changes. The operator << has been implemented for various objects involved in the data processing.

New filter system rolled out with currently two filters up and running: min_max and mean_avg (without the soft option, only left or right centering). The new filter system is built upon processing blocks that take a vector<MeteoData> as input and return a processed vector<MeteoData>. The individual filters are stacked in a ProcessingStack where they are invoked sequentially.

MeteoData now has an extra public member variable: StationData meta. It will hold the meta information of the measurment instead of dragging along a second vector<StationData> alongside the vector<MeteoData> everywhere.

This has huge implications: the IOInterface has been rewritten, subsequently changes need to be propagated into all plugins and all modules dealing with meta data.

The new filtering and resampling framework. Filtering/Processing and Resampling have been separated from each other, the Resampling is now done with the class Meteo1DInterpolator which utilizes the static algorithms within ResamplingAlgorithms. The filtering remains a task of class MeteoFilter. The calling of the resampling and filtering as well as the data selection is now based in the facade class MeteoProcessor. MeteoProcessor::processData function calls the filtering algorithms, then passes the filtered data to the resampling algorithms and finally runs a "check only" filtering pass.

The filtering system underwent some changes in order to simplify the tasks at hand, the interface has changed.

The RateFilter is currently disfunctional, needs to be reimplemented.

Overall all include statements within in the library have been replaced by angle brackets, the default install path for the include file is $CMAKE_INSTALL_DIR/include/meteoio, the meteoio libraries (static and shared) will be installed in $CMAKE_INSTALL_DIR/lib per default.

The plugins will be installed in the subdirectory $CMAKE_INSTALL_DIR/lib/meteoio/plugins

Changed the name of the Date_IO class to Date. In case of namespace conflicts, just use mio::Date to reference the MeteoIO Date class.

The license information has been added: LPGLv3 headers in all header files, license texts as well as a Linux Software Map entry file.

The installation procedure has been added to cmake configuration files (similar to the autotools)

MeteoFilter operates on static filter algorithms which are defined in FilterAlgorithms.*
FilterProperties is a small helper class to declare properties of an Algorithm (e.g. how many data points it requires, ...)
The new MeteoFilter system is utilized by class BufferedIOHandler.

The old filter system is removed from Makefiles/CMake and the SVN directory.
Legacy MeteoIO classes Meteo1DResampler and MeteoBuffer, which were solely required by the old filter system are also removed.