The bufferAlways method of BufferedIOHandler has been renamed as setBufferProperties. The A3DIO, IMISIO, SMETIO and SNIO plugins now correctly support time zones. The plugin howto documentation now warns the developer to take care of time zones issues.

The DEMObject subset constructor was broken, it has been fixed. It involved creating a subset method in the arrays classes.

The Coord class now supports using the given UTM zone when converting from lat/long to UTM. If the computed zone does not match the one requested in the io.ini, it prints a warning but uses the user-supplied zone.

A first implementation of readStationData for SMETIO has been done. 

Some documentation has been added for plugin development

The DEMObject can now be configured to automatically calculate slope/azimuth and/or normals and/or curvature (or none) by setting a few flags.

The installation has been improved (compiling the plugins in their own directory helps)

A few extra tweaks for compiling on Hera, the version number has been updated to 1.1 and some extra documentation added (drawing on "how to write a plugin").

The documentation has been extended by adding a workflow diagram and more details for writing plugins.

A class diagram has been added to the documentation as well as more detailed instructions in the "how to write a plugin" section (with links to the template plugin and CMakeLists compilation files)

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

General cleanup: the time.cc example sets a timezone variable, an unnecessary "mio::" has been removed in Coords, and two template files have been added to help plugin development (and mentionned in the documentation). 

The cmake targets have been changed into "safe", "optimized", "par" and "hera". (the later being specific for the hera cluster).

Most of the doxygen issues have been fixed. A few are still left (and we lost the inheritance structure in doxygen).

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.

a new function called: readStationData has been added. It expects a date and a vector<StationData> as parameters and returns the meta data for the required date (often this date is irrelevant, because stations are fixed, then just pass any date).

A new function is introduced into the IOInterface: writeMeteoData. It expects one vector<vector<MeteoData>> and one vector<vector<StationData>> as well as an optional string (for database info, file name, etc). The relevant io.ini tag is:
METEODEST = GEOTOP

Only GeotopIO has this method fully implemented thus enabling to convert all meteo data captured from any other source to a GEOtop compliant meteo files. The relevant tags are:
METEODESTPATH = /tmp
METEODESTSEQ	= WindS WindDir RelHum AirT SWglobal Iprec

METEODESTPATH determines where the files will be written to and METEODESTSEQ determines the order in which the meteo parameters will be written into the CSV file

The plugin's interface (IOInterface) has been slightly modified: readSpecialPoints now returns a vector of Coords. This means that a plugin can provide coordinates as (lat,long) or (easting, northing) or (grid_i, grid_j). All the plugins have been modified accordingly and POINTS and POINTSArray have been removed from Array.h

The class Stationdata now properly uses the new Coords class. All usual dependencies have been fixed (A3DIO.cc) but not (yet) the optional plugins. The Coords class has been modified so that it computes the matching coordinates as soon as possible instead of the previous implementation that was delaying it as much as possible (thus making "const Coords..." impossible).

The includes have been cleaned up (compilation was failing because of multiple "using namespace" in header files) and all "using namespace" have been removed from header files (please don't put any of these back!!). The doxygen comments has been updated.

The MapProj class has been renamed in Coords. It now contains the coordinates (lat,long) and (xcoord, ycoord) and should therefore be used as a storage and conversion class. The necessary changes have been made to the rest of the code so it uses this class, but it still does NOT use it as a storage of coordinates (which will have to be done in the future). This addressed partially issue 35.

The Special_PTS and CSpecialPointsArray structures have been renamed in "POINT" and "POINTSArray" (there was no reason to call them "special points"). 

A few new methods have been added to DEMObject: getPointsBetween that returns a vector containing the indices of all points located on the line between two points (given by their real world (x,y) coordinates), horizontalDistance that returns the horizontal distance between two points and terrainDistance that returns the distance between two point accros the terrain as described by the DEM (ie: going up and down the terrain).

This is the begining of a plugins developer's guide... (within the doxygen documentation). A few things would need to be filled by Thomas!

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)

A small but irrtating bug in the Makefile has been fixed (failure to install when the parallel version had not yet been compiled). 

The doxygen documentation has been updated with the documentation of the plugins (from a user point of view). The data assimilation reading methods have been slightly tweaked (so that they read a time stamp containing minutes and not only hours). 

All the code that has to do with geographic calculations (projections, conversions to/from swiss coordinates, geodesic distances, etc) has been moved to the MapProj class. An elegant solution for checking the Grid2DObject coordinates (lat/long against xcoord/ycoord) in underway... (almost there!)

Includes issues have been found and fixed (IOInterface and Grid2DObjet.h)

	* Changed method call to readDEM so that polymorphism is not used anymore.

Attempt to get rid of warnings ala: class BufferedIOHandler' has virtual functions but non-virtual destructor

Suppressed some newly introduced warnings and fixed the documentation so doxygen does not complain anymore...

* Complete rewrite of IOHandler: Now it is very easy to add new plugins (adding one line), all the internals (allocation, loading, deleting, loading the right plugin for each IOInterface function) are transparently done.

* changed one parameter in readMeteoData to const unsigned int& from unsigned int. Therefore all children of IOInterface needed to undergo that change

* Fixed a nasty bug in BufferedIOHandler that lead to seg faults.

* had to propagate changes into all children of IOInterface

* function readMeteoData is there to read an interval of data
	readMeteoData(fromDate, toDate, vector< vector<MeteoData> >, vector< vector<MeteoData> >)
* BufferedIOHandler is constructed with another child of IOInterface (e.g. IOHandler) as parameter and deals with all intrinsic issues of buffering, resampling, filtering: so if you have an IOHandler and you want to add buffering:
	BufferedIOHandler(iohandler, configreader)
and then you can access all IOInterface functions, plus a few convenient ones that only BufferedIOHandler exposes:
	getNextMeteoData(date, vector<MeteoData>, vector<StationData>)
	readMeteoData(date, vector<MeteoData>, vector<StationData>)
you can enable and disable buffering:
	bufferediohandler.enableResampling(true);

* A3DIO and IOHandler had to be adapted to the changes in IOInterface 
* added a getYear() function to Date_IO
* MeteoData has a new member variable "resampled" to indicate whether data has been resampled or not

Ok, this is the correct implementation of what I tried to do in the previous commit... Now, the Meteo2DInterpolator can take either Array2D<double> or Grid2DObjects as tables to fill. The overloading of the Write2DGrid has therefore been suppressed: since Grid2DObjects are geography-friendly, they should be used in our applications instead of Array2D (that should be reserved for internal implementation of objects).

So, this is mostly reverting to the code before the last commit, with a few extra lines of code to do the magic...

In order to make using the spatial interpolations easier to use, there is a need to be able to write to files objects of type Array2D. This has been added to IOInterface and implemented in the different plugins.

meteoio_demo has been modified accordingly and is now much simpler.

More fundamentally, we need to think about the way to handle in a nice and elegant way the different type accross the plugins (typically as seen for Write2DGrid): where should we handle what in order to let the user seemlessly write objects to the available mediums?

Nothing special, just some re-indentation in order to make the code lines clear and easy to run and understand.

The whole library has been given its new name and several classes have been renamed in order to better match their purpose. The Makefile has been modified accordingly.