WSL/SLF GitLab Repository

MainPage.h 27.1 KB
 Thomas Egger committed Jun 21, 2010 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 /***********************************************************************************/ /* Copyright 2009-2010 WSL Institute for Snow and Avalanche Research SLF-DAVOS */ /***********************************************************************************/ /* This file is part of MeteoIO. MeteoIO is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. MeteoIO is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with MeteoIO. If not, see . */ #ifndef __MAINPAGE_H__ #define __MAINPAGE_H__ namespace mio {  Mathias Bavay committed Jan 26, 2011 22 23 24 25 26 27 //groups /*! \defgroup meteolaws Meteorological Laws Documentation for meteorological laws and constants. */ /*! \defgroup plugins IO plugins  Mathias Bavay committed Feb 16, 2011 28  Documentation for available IO plugins. Please consider having a look at the \ref plugins "Available plugins and usage" page and the \ref dev_plugins "How to write a Plugin" page.  Mathias Bavay committed Jan 26, 2011 29 30 31 */ /*! \defgroup stats Statistical calculations  Mathias Bavay committed Feb 16, 2011 32  Documentation for available statistical calculations. This is heavily used by the \ref processing "Available data processing elements" as well as the \ref resampling "1D interpolations" and \ref interpol2d "2D interpolations".  Mathias Bavay committed Feb 11, 2011 33 34 35 */ /*! \defgroup processing Data processing elements  Mathias Bavay committed Feb 16, 2011 36  Documentation for available data processing components. These can be used on incoming meteorological data. See \ref processing "Available data processing elements".  Mathias Bavay committed Jan 26, 2011 37 38 39 40 41 42 */ /*! \defgroup data_str Data structures Documentation for available data structures. */  Mathias Bavay committed Jan 06, 2012 43 44 45 46 /*! \defgroup graphics Graphical elements and operations Documentation for available classes and methods for dealing with graphical elements, color conversions, etc */  Thomas Egger committed Jun 21, 2010 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61  /** * @mainpage Welcome to MeteoIO * @section intro_sec Introduction * This library aims at making data access easy and safe for numerical simulations in environmental sciences requiring general meteorological data. It's main design goals are: * - providing data format/protocol independent data access * - providing safe and robust I/O * - making I/O code as unobtrusive and simple as possible for the user * - providing ready to use data to the user, which means transparent caching, filtering, resampling, spatial interpolation. * - enabling unattended use from an IO point of view * - offering high modularity so that individual elements of the library can easily be replaced/expanded/added * - by its modularity, help interdisciplinary development, each module being targeted at a specific developer profile * * This library is available under LPGL version 3 or above, see www.gnu.org. * * @section table_of_content Table of content  Mathias Bavay committed Dec 05, 2012 62 63 64 65 66  * -# External Links * -# MeteoIO's home page * -# Installation, compilation * -# Getting help * -# subscribe to MeteoIO's release announcements  Thomas Egger committed Jun 21, 2010 67 68 69 70  * -# End User documentation * -# \subpage general "General concepts" * -# \subpage plugins "Available plugins" and usage * -# \subpage coords "Available coordinate systems" and usage  Mathias Bavay committed Feb 11, 2011 71  * -# \subpage processing "Available processing elements" and usage  Mathias Bavay committed Jul 12, 2010 72  * -# \subpage resampling "Available temporal interpolations" and usage  Thomas Egger committed Jun 21, 2010 73  * -# \subpage interpol2d "Available spatial interpolations" and usage  Mathias Bavay committed Feb 11, 2011 74  * -# \subpage build_io "How to build your io.ini configuration file"  Thomas Egger committed Jun 21, 2010 75  * -# Programing using MeteoIO  Mathias Bavay committed Jul 13, 2010 76  * -# \subpage workflow "Example Workflow"  Thomas Egger committed Jun 21, 2010 77 78 79 80  * -# \subpage quick_overview "Quick overview" of the functionnality provided by MeteoIO * -# \subpage examples "Usage examples" * -# Expanding MeteoIO * -# How to \subpage dev_plugins "write a Plugin"  Mathias Bavay committed Feb 11, 2011 81  * -# How to \subpage dev_processing "write a processing element"  82  * -# How to \subpage dev_2Dinterpol "write a spatial interpolation algorithm"  Thomas Egger committed Jun 21, 2010 83 84 85 86 87 88 89 90 91 92  */ /** * @page general General concepts * Since MeteoIO is a library, you, as an end user, will have a limited direct exposure to it: the library is called by the program that you are using, not directly by yourself. You will basically have to set some parameters in a configuration file that defines how MeteoIO has to behave. This configuration file is often named "io.ini" and follows the INI file format standard (see http://en.wikipedia.org/wiki/INI_file). In order to understand how this file is structured, let us first have a look at the general structure of MeteoIO and afterward the structure of this configuration file and where to find the available configuration parameters. * * @section MeteoIO_structure General MeteoIO structure * MeteoIO can be seen as a set of modules that is focused on the handling of input/output operations (including data preparation) for numerical simulations in the realm of earth sciences. On the visible side, it offers the following modules: * - a set of plugins for accessing the data (for example, a plugin might be responsible for fetching the raw data from a given database) * - a set of filters and processing elements for applying transformations to the data (for example, a filter might remove all data that is out of range)  93  * - a set of spatial interpolation algorithms (for example, such an algorithm might perform Inverse Distance Weighting for filling a grid with spatially interpolated data)  Thomas Egger committed Jun 21, 2010 94 95 96 97  * * Moreover, a few assumptions are made about the data that you are using: each data point has to be associated with a geographic location (defined by some sort of coordinates) and very often you will also need to provide a Digital Elevation Model. Therefore, you will also notice a few extra modules that come to play on the visible side: * - a module to deal with Digital Elevation Models. Such module will, for example, interpret a grid of data as a grid of elevations and compute a grid of slopes. * - a module to deal with coordinate systems. Such module will require you to define which coordinate system are your data in and transparently handle potential coordinate conversions in the program that you are using.  98  * - a module to deal with configuration files. The program that you are using might be using this module for other configuration files.  Thomas Egger committed Jun 21, 2010 99 100  * * @section Config Configuration file  Mathias Bavay committed Feb 11, 2011 101  * @anchor config_doc  Thomas Egger committed Jun 21, 2010 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128  * @subsection Config_syntax Configuration file syntax * The configuration inputs/outputs file is divided in sections. Each section name is enclosed in brackets. * @code * [My_section] * bla bla bla * @endcode * * Within each section, you might have comments and/or key/value pairs. The comments start with a "#" or a ";" sign and run until the end of the line. A whole line might be commented out, or only a fraction of it. A key/value pair is a keyword, followed by a "=" sign, followed by the value to associate with this key. * @code * #This is a commented out line * PI = 3.14159 #key/value pair and a comment * @endcode * * A valid value can be an integer, a float, or string, a list of keywords, a mixed list of keywords and numbers... * @code * TA::algorithms = IDW_LAPSE CST_LAPSE * @endcode * * @subsection Config_structure Configuration file structure * MeteoIO imposes a minimum structure to the configuration file: It must contain the [General], [Input] and [Output] sections. If any filter is to be used, a [Filters] section has to be present and if any spatial interpolation is to be used, an [Interpolations2D] section has to be present. A minimal set of keys has to be there, an potentially a number of optional keys. Moreover, the program that you are using might also impose you some specific keys or sections. * The keys and their location in the configuration file (ie: to which section they belong) depends on the module that is actually using them. The optional keys depend on the specific options handled by each specific module (or plugin, or algorithm). Therefore, we can draw the following skeleton: * @code * [General] * * [Input] * COORDSYS = CH1903 #mandatory: which coordinate system is used for the geographic coordinates * COORDPARAM = -999 #extra arguments for the chosen coordinate system (often, none)  Mathias Bavay committed Feb 11, 2011 129  * TIME_ZONE = +1 #default time zone for inputs  Thomas Egger committed Jun 21, 2010 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158  * * DEM = ARC #plugin to use for reading DEM information * #this might be followed by any number of arguments that are specific to this plugin * * METEO = A3D #plugin to use for reading meteorological data * #this might be followed by any number of arguments that are specific to this plugin * * [Output] * COORDSYS = CH1903 * * GRID2D = ARC #plugin to use for writing 2D grids * * [Filters] * TA::filter1 = min_max #first filter to use on the parameter TA * TA::arg1 = 230 330 #arguments for this first filter * TA::filter2 = rate #second filter to use (in chronological order) * TA::arg2 = 0.01 #arguments for this second filter * #add any extra filter that you want to use. They will be applied serially * * [Interpolations2D] * TA::algorithms = IDW_LAPSE CST_LAPSE #list of algorithms to consider for use for spatially interpolating parameter TA * TA::cst_lapse = -0.008 #parameter for a specific interpolation algorithm for parameter TA * * @endcode * * @subsection Finding_docs Where to find the proper documentation * As can be seen from the previous example, each plugin, each filter or each interpolation algorithm might have its own parameters. Therefore, this is the documentation of each specific plugin/filter/algorithm that has to be used in order to figure out what can be configured when it (see the next sections in the welcome page). */  Mathias Bavay committed Feb 11, 2011 159 /**  Mathias Bavay committed Jun 27, 2012 160  * @page build_io How to build your io.ini configuration file  Mathias Bavay committed Feb 11, 2011 161 162 163 164  * As shown in \ref config_doc , the operation of MeteoIO is driven by a configuration file. This section will show you * how to practically set up your first configuration file. Please read \ref general documentation page before starting! * * You first need to create the various sections:  165  * - [General] : The documentation about this section is found in ??. It currently contains the PLUGIN_PATH key that  Mathias Bavay committed Aug 24, 2011 166  * points to the place where to find the plugins as well as some buffering keys (see BufferedIOHandler).  Mathias Bavay committed Feb 11, 2011 167 168 169 170 171  * - [Input] : This section contains the list of all the plugins that you want to use as well as their parameters. You can * use one plugin for the meteorological data (key=METEO), one for grids (key=GRID2D), one for special points * (key=SPECIALPTS), one for data assimilation (key=DA), one for landuse (key=LANDUSE) and one for Digital * Elevation Model (key=DEM). Please see \ref plugins for the available plugins. Afterwards, each plugin comes * with its own set of keys, as specified in the plugin's documentation. Morevover, the geographic coordinate  Mathias Bavay committed Oct 06, 2011 172 173  * system should often be specified, as explained in \ref coords. For the meteorological parameters, it is also * possible to copy one parameter into a new one, as shown in \ref data_generators.  Mathias Bavay committed Feb 11, 2011 174 175  * * - [Output] : This section is very similar to the [Input] section, but (obviously) for outputing the data.  Mathias Bavay committed Aug 24, 2011 176  *  Mathias Bavay committed Feb 11, 2011 177 178  * - [Filters] : This section lists the pre-processing that has to be performed on the incoming meteorological data. * It builds a stack of processing elements one after the other one, for each meteorological parameter.  Mathias Bavay committed Aug 24, 2011 179  * See \ref processing for more information. It also contains  Mathias Bavay committed Feb 11, 2011 180  *  181 182 183 184  * - [Interpolations1D] : This section deals with temporal resampling of the incoming meteorological data. The goal is * to be able to take in data at any sampling rate and to extract values at any user given time step * according to the resampling specifications of the user. The search window size can be given with * key WINDOW_SIZE that expresses (in seconds) how far a valid point can be searched for when  Mathias Bavay committed Aug 24, 2011 185  * re-interpolating a missing value (up to WINDOW_SIZE/2 before and after the requested point).  Mathias Bavay committed Feb 11, 2011 186 187 188  * See \ref resampling . * * - [Interpolations2D] : This section deals with the spatial interpolation of meteorological data, based on a provided  189 190 191  * Digital Elevation Model. The goal is to populate two dimensional grids with meteorological * parameters from point measurements, according to the specifications of the user. * See \ref interpol2d .  Mathias Bavay committed Feb 11, 2011 192 193  * * The application that you are using might also need its own section(s), check this with your application.  Mathias Bavay committed Aug 24, 2011 194  *  Mathias Bavay committed Feb 11, 2011 195 196  */  Mathias Bavay committed Jul 13, 2010 197 198 199 200 201 202 203  /** * @page workflow Workflow * Here is a workflow example showing how meteorological data is requested by the user's application and delivered. This is a simplified view, in order to show the general structure. Requesting grids (2D grids, DEM, etc) is very similar but does not perfom filtering or resampling. * \image html workflow_meteoreading.png "simplified meteo reading workflow" * \image latex workflow_meteoreading.eps "simplified meteo reading workflow" width=0.9\textwidth */  Thomas Egger committed Jun 21, 2010 204 205 206 207  /** * @page quick_overview Quick overview * This library contains various classes that have been designed to deal with various sets of problems. This page shows the different sets of problems and what kind of functionnality the library offers to tackle them. *  Mathias Bavay committed Jul 12, 2010 208 209 210  * @section class_structure Class structure * \image html structure.png "simplified class structure" * \image latex structure.eps "simplified class structure" width=0.9\textwidth  Thomas Egger committed Jun 21, 2010 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247  * * @section iohandler_sec Data reading * The class IOHandler provides the meteorological data from the sources selected by the user in its configuration file. This class inherits from IOInterface and is implemented through plugins that are responsible for implementing a given data access (see \ref dev_plugins "Plugins developer's guide" for more information). It therefore proposes a uniform, standardized access to the data that can be meteorological data, gridded data (including Digital Elevation Model (DEM) data or variations like for landuse codes) and tables of coordinates (for special processing at users selected locations). A buffered version of this class exists: BufferedIOHandler that should be prefered. The description of the plugins and their usage can be found in \ref plugins "Available plugins". * This class also transparently calls the filtering class, FilterAlgorithms in order to filter the data according to the configuration of the user. * * * @section meteo Meteorological data * The data structures designed for storing meteorological data have been split into two classes: MeteoData and StationData. * @subsection meteodata MeteoData * The class MeteoData stores the measurement data coming from some idealized station. It contains the widest set of meteorological measurements. It can be compared, assigned and set (either using a constructor or by calling a set method). Its meteorological parameters can be directly accessed or using a param() method that takes a enum in order to be able to cycle through the parameters. * @subsection stationdata StationData * The class StationData contains the metadata of a weather station, that is mostly its location. It supports the comparison operators. * @subsection getmeteo_sec Getting the data * The getMeteoData method defined in the IOHandler class provides a vector of MeteoData and StationData for the requested time step. More details are given in \ref iohandler_sec . * * * @section arrays Arrays related functionnalities * @subsection arrays_sec Arrays * The classes Array, Array2D and Array3D are designed for the storage and handling of 1D, 2D, 3D arrays in memory. These classes provide access to a given element (read/write), sizing or resizing of an existing array as well as clearing an array. They also provide the minimum and the maximum of the values that are stored in the array. Finally, a subset of an array can be extracted. * @subsection grids_sec Grids * Built on top of the arrays, defined as classes Grid2DObject and Grid3DObject, the grids add the geolocalization. This means that the coordinates of the lower-left corner of the array are stored as well as the cellsize. They can be built manually, or by providing an array. A subset constructor is available, allowing to extract a subset of the grid. It is also possible to get the lat/long (in WGS84) coordinates matching an (i,j) coordinate in the grid. Finally, It is possible to test for geolocalization equality (ie: do two grids have the same geolocalization). * @subsection dem_sec Digital Elevation Models * The last layer for gridded data is class DEMObject. Various parameters that are specific to Digital Elevation Models (DEM) are added: for each grid point, the slope, the azimuth, the curvature as well as the normal vector are defined (an optional parameter can be used to select the algorithm to be used). The minimums and maximums (over the grid) for each of these parameters are available. A subset of the DEM can be extracted using the subset constructor. * * * @section proj_sec Geographic projections * The class Coords is dedicated to geographic projections. It can use both internal algorithms and projections provided by libproj4. * @subsection coord_conv Coordinate conversion * The class Coords takes one or two arguments describing the coordinate system of the input data and then converts back and forth with lat/long WGS84. It can be used to construct a local coordinate system, that is to say a metric grid whose origin is chosen by the user (through the lat/long parameters provided to the constructor). This is useful when working with multiple gridded coordinate system in order to get a common system that would still allow easy distances calculations. See the supported \ref Coordinate_types "projections". * @subsection dist_sec Distances * A few method used internally to work with custom, local grids are exposed to the user in order to easily compute distances beetwen points (using their lat/long). The algorithms can optionnaly be chosen (otherwise a default choice is used). * * * @section interpol_sec Interpolations * @subsection interpol2d_sec Spatial interpolations * The class Meteo2DInterpolator receives a Digital Elevation Model (DEM) in its constructor as well as two vectors, one of MeteoData the other one of StationData. Then it allows filling 2D grid (as Grid2DObject) with spatially interpolated meteorological parameters. * @subsection interpol1d_sec 1D interpolations  Mathias Bavay committed Jul 12, 2010 248  * The ResamplingAlgorithms class uses the Interpol1D class to perform temporal interpolations (for resampling).  Thomas Egger committed Jun 21, 2010 249 250  * * @section config_sec Configuration files handling  Thomas Egger committed Jul 26, 2010 251  * In order to offer a consistent interface to the user as well as make it easy to read configuration parameters, the class Config is exposed. Once constructed with a configuration file name, each key's parameter can be retrieved with a call to the templatized getValue() method.  Thomas Egger committed Jun 21, 2010 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267  * * * @section date_sec Dates handling * Dates should be constructed as a Date object. Then, it is easy to built a new date from a julian date, from an ISO formatted date string, from a date split in fields or from a UNIX date (number of seconds since epoch). Then the various representation of the date can be retrieved, the date arithmetics can be done (for example, get the date that is 1 year, 3 months, 15 hours after 2008-12-01T11:54:00) as well as comparisons. The date printing can be controlled by keywords. * * * @section exceptions_sec Exceptions * A few customized exceptions have been defined in IOException : these exceptions have to do with I/O, parameter parsing, argument validity, etc and consistently print usefull debuging information when thrown. * * * @section misc_sec Miscellaneous * The IOUtils class is a static class that contains a few helper functions, in order to deal with things as diverse as units conversions, checking for file presence, equality within a given epsilon, string parsing. * */ //Plugins overview given in IOHandler.cc  Mathias Bavay committed Feb 15, 2011 268 //Filters overview given in ProcessingBlock.cc  Thomas Egger committed Jun 21, 2010 269 //Plugin development given in IOInterface.h  270 //2D interpolation development given in Meteo2DInterpolator.h  Thomas Egger committed Jun 21, 2010 271 272  /**  Mathias Bavay committed Feb 11, 2011 273  * @page dev_processing Processing elements developer's guide  Thomas Egger committed Jun 21, 2010 274  *  Mathias Bavay committed Feb 11, 2011 275  * In order to add a new filter/processing element to the already existing set of components, the developer only needs to  Mathias Bavay committed Aug 24, 2011 276  * add a class derived from either ProcessingBlock, FilterBlock or WindowedFilter in meteoio/meteofilters.  Mathias Bavay committed Feb 11, 2011 277  * It is important to understand that the processing elements operate on a "per parameter" basis.  Mathias Bavay committed Aug 24, 2011 278  * This means that an element might be executed for the parameter TA and another one for the parameter HNW, so the  Mathias Bavay committed Feb 11, 2011 279  * algorithm only has to deal with a generic processing method based on double values.  Thomas Egger committed Jun 21, 2010 280  *  Mathias Bavay committed Feb 11, 2011 281  * To implement a new processing element, the following steps are necessary:  Thomas Egger committed Jun 21, 2010 282  *  Mathias Bavay committed Feb 11, 2011 283 284  * -# Implementing the element, as a derived class of ProcessingBlock or FilterBlock or WindowedFilter, by creating * two files: the header file and its  Mathias Bavay committed Feb 01, 2011 285 286  * implementation file, in the meteofilters subdirectory of the source code. * The class will contain two public methods: a constructor  Mathias Bavay committed Feb 11, 2011 287  * that takes a vector of strings containing the element's arguments and a method  Thomas Egger committed Jun 21, 2010 288  * @code  Mathias Bavay committed Feb 01, 2011 289  * process(const unsigned int& index, const std::vector& ivec, std::vector& ovec)  Thomas Egger committed Jun 21, 2010 290  * @endcode  Mathias Bavay committed Feb 01, 2011 291  * that  Mathias Bavay committed Feb 11, 2011 292  * applies the element to the provided vector of values, for a meteo parameter pointed to by index. This index  Mathias Bavay committed Feb 01, 2011 293 294 295 296  * is the MeteoData parameter that this filter shall be run upon (see MeteoData for the enumeration of * parameters). The constructor must set up properties.for_second_pass to mark if the filter can be applied * a second time during a second pass, that is after resampling. * A private method  Thomas Egger committed Jun 21, 2010 297  * @code  Mathias Bavay committed Feb 01, 2011 298  * parse_args(std::vector vec_args)  Thomas Egger committed Jun 21, 2010 299  * @endcode  Mathias Bavay committed Feb 01, 2011 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320  * is also implemented to extract the numerical * values out of the vector of strings of arguments. * -# Adding the created implementation file to meteofilters/CMakeLists.txt in a similar way as for the other * filters * -# Registering the filter within the function BlockFactory::initStaticData(), by simply adding a line * similar to (in meteofilters/ProcessingBlocks.cc): * @code * availableBlocks.insert("MIN"); * @endcode * Where the filter key can be freely chosen (although it has to be unique and easy/meanigful to the end user * who will use it in his configuration file) * -# Adding the filter in the processing loop, in BlockFactory::getBlock(), by adding three lines similar to: * @code * else if (blockname == "MIN_MAX"){ * return new FilterMinMax(vec_args); * } * @endcode * -# Including the filter's header file in meteofilters/ProcessingBlocks.cc * * The class FilterMax can be used as an example of implementation of a basic filter that will check whether a * value is greater than an argument  Thomas Egger committed Jun 21, 2010 321 322  * supplied to the filter and if so changes the value either to IOUtils::nodata (normal operation) or to the * maximum value supplied in the argument (soft mode of operation). An example section in the io.ini file supplied  Thomas Egger committed Jul 26, 2010 323  * to the Config could look like this:  Thomas Egger committed Jun 21, 2010 324 325 326 327 328 329 330  * @code * [Filters] * TA::filter1 = max * TA::arg1 = soft 280 * @endcode * Which has the following interpretation: Apply filter max (max-value-filter) to the parameter TA (air temperature) * in case that a value is greater than 280 degrees Kelvin change that value to 280.  Mathias Bavay committed Feb 01, 2011 331  * A more customized operation could be:  Thomas Egger committed Jun 21, 2010 332  * @code  Mathias Bavay committed Feb 01, 2011 333 334 335  * [Filters] * TA::filter1 = max * TA::arg1 = soft 280 260  Thomas Egger committed Jun 21, 2010 336  * @endcode  Mathias Bavay committed Feb 01, 2011 337  * Which will replace any value greater than 280 Kelvin by 260 Kelvin.  Mathias Bavay committed Aug 24, 2011 338  *  Thomas Egger committed Jun 21, 2010 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353  */ /** * @page examples Examples * Here is a simple exmaple showing how to get some meteorological data into the MeteoData and StationData vectors. * \code * #include * #include "MeteoIO.h" * * int main(int argc, char** argv) { * (void)argc; * //provide date as ISO formatted, for example 2008-12-01T15:35:00 * Date d1; * std::vector vecMeteo; *  Mathias Bavay committed Jan 26, 2011 354  * mio::IOManager *io = NULL;  Thomas Egger committed Jun 21, 2010 355 356  * * try {  Thomas Egger committed Jul 26, 2010 357  * mio::Config cfg("io.ini");  Mathias Bavay committed Jan 26, 2011 358  * io = new mio::IOManager(cfg);  Mathias Bavay committed Aug 24, 2011 359  * } catch (const IOException& e){  Mathias Bavay committed Dec 05, 2012 360  * std::cout << "Problem with IOManager creation, cause: " << e.what() << std::endl;  Thomas Egger committed Jun 21, 2010 361 362 363  * } * * try {  Mathias Bavay committed Jan 26, 2011 364  * mio::IOUtils::convertString(d1,argv[1]);  365  * io->readMeteoData(d1, vecMeteo);  Mathias Bavay committed Aug 24, 2011 366  * } catch (const IOException& e){  Thomas Egger committed Jun 21, 2010 367 368 369 370 371  * std::cout << "Problem when reading data, cause: " << e.what() << std::endl; * } * * //writing some data out in order to prove that it really worked! * for (unsigned int ii=0; ii < vecMeteo.size(); ii++) {  372  * std::cout << "---------- Station: " << (ii+1) << " / " << vecMeteo.size() << std::endl;  Thomas Egger committed Jun 21, 2010 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388  * std::cout << vecMeteo[ii] << std::endl; * } * * delete io; * * return 0; * } * \endcode * * Now, we can also read a Digital Elevation Model, extract a sub set as defined by some geographical coordinates and distances and write it back to disk: * \code * #include "MeteoIO.h" * * int main(void) { * const double dist_x=700, dist_y=1200; * mio::DEMObject dem;  Mathias Bavay committed Jan 26, 2011 389  * mio::IOManager *io = NULL;  Mathias Bavay committed Sep 24, 2012 390  * mio::Config *cfg = NULL;  Thomas Egger committed Jun 21, 2010 391 392 393  * int i,j; * * try {  Thomas Egger committed Jul 26, 2010 394  * cfg = new mio::Config("io.ini");  Mathias Bavay committed Jan 26, 2011 395  * io = new mio::IOManager(cfg);  Mathias Bavay committed Aug 24, 2011 396  * } catch (const IOException& e){  Thomas Egger committed Jun 21, 2010 397 398 399  * std::cout << "Problem with IOHandler creation, cause: " << e.what() << std::endl; * } *  Mathias Bavay committed Sep 24, 2012 400 401 402 403 404 405 406 407  * try { * io->readDEM(dem); * mio::Coords point(*cfg); * point.setLatLon(46.1592, 8.12993); * dem.WGS84_to_grid(point, i,j); * * const int ncols = (int)ceil(dist_x/dem.cellsize); * const int nrows = (int)ceil(dist_y/dem.cellsize);  Thomas Egger committed Jun 21, 2010 408  *  Mathias Bavay committed Sep 24, 2012 409 410 411 412 413  * mio::DEMObject sub_dem(dem, i, j, ncols, nrows); * io->write2DGrid(sub_dem,"sub_dem.dem"); * } catch (const IOException& e){ * std::cout << "Problem processing DEM: " << e.what() << std::endl; * }  Thomas Egger committed Jun 21, 2010 414 415 416 417 418  * * return 0; * } * \endcode *  Mathias Bavay committed Jan 26, 2011 419  * The next example shows how to compute and output spatial interpolations.  Thomas Egger committed Jun 21, 2010 420  * \code  Mathias Bavay committed Jan 26, 2011 421  * #include "MeteoIO.h"  Thomas Egger committed Jun 21, 2010 422  *  Mathias Bavay committed Sep 24, 2012 423  * void real_main(void) {  Mathias Bavay committed Jan 26, 2011 424  * mio::Date d1;  Mathias Bavay committed Aug 24, 2011 425  *  Mathias Bavay committed Jan 26, 2011 426 427 428  * //initializing the io handlers according to the config file * mio::Config cfg("io.ini"); * mio::IOManager io(cfg);  Mathias Bavay committed Aug 24, 2011 429  *  Mathias Bavay committed Jan 26, 2011 430 431 432  * //reading the dem (necessary for several spatial interpolations algoritms) * mio::DEMObject dem; * io.readDEM(dem);  Mathias Bavay committed Aug 24, 2011 433  *  Mathias Bavay committed Jan 26, 2011 434 435 436  * //we assume that the time given on the command line is in TZ=+1 * d1.setTimeZone(1.); * mio::IOUtils::convertString(d1,argv[1]);  Mathias Bavay committed Aug 24, 2011 437  *  Mathias Bavay committed Jan 26, 2011 438 439 440 441  * //performing spatial interpolations * mio::Grid2DObject ta_grid; * io.interpolate(d1, dem, MeteoData::TA, ta_grid); * io.write2DGrid(param,"ta.asc");  Mathias Bavay committed Sep 24, 2012 442 443 444 445 446 447 448 449  * } * * int main(void) { * try { * real_main(); * } catch (const IOException& e){ * std::cout << e.what() << std::endl; * }  Mathias Bavay committed Aug 24, 2011 450  *  Mathias Bavay committed Jan 26, 2011 451  * return 0;  Thomas Egger committed Jun 21, 2010 452 453  * } * \endcode  Mathias Bavay committed Dec 05, 2012 454 455 456  * * Do not forget to have a look at the examples provided in doc/examples! An example io.ini is provided as well as some data sets * (7 weather stations as well as one DEM).  Thomas Egger committed Jun 21, 2010 457 458 459 460  */ } //end namespace mio #endif