WSL/SLF GitLab Repository

  1. 15 Mar, 2010 2 commits
    • Thomas Egger's avatar
      A new function is introduced into the IOInterface: writeMeteoData. It expects... · 4100a120
      Thomas Egger authored
      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
      4100a120
    • Thomas Egger's avatar
      Added Filter to average wind speeds and directions called WindAvgFilter,... · b90d8858
      Thomas Egger authored
      Added Filter to average wind speeds and directions called WindAvgFilter, accessible through the io.ini tags: wind_avg;
      example:
      VW::filter1 = wind_avg
      VW::arg1 = soft center 1 60
      
      The averaging is done vector based by computing the east-west and north-south components of the wind (using cos and sin). The vectors are weighted with the corresponding wind speed.
      b90d8858
  2. 09 Mar, 2010 3 commits
  3. 04 Mar, 2010 2 commits
  4. 01 Mar, 2010 2 commits
    • Mathias Bavay's avatar
      A better example of DEM usage has been prepared: it uses a 1000m resolution... · 6838c914
      Mathias Bavay authored
      A better example of DEM usage has been prepared: it uses a 1000m resolution DEM of the whole of Switzerland (that is, with holes in the dem) and valid coordinates are now much easier to guess...
      6838c914
    • Mathias Bavay's avatar
      A new slope algorithm has been added (HORN), even if it computes the same... · 0e1e6314
      Mathias Bavay authored
      A new slope algorithm has been added (HORN), even if it computes the same slopes as CORRIPIO (except for border cells). This is the algorithm that is used in ArcGIS. Some cleanup has been done in the references (it seems some algorithms have been published several time by different people). The embryo of a real hydrological slope algorithm is coming: it is not nammed CARD any more, but D8 and gives NODATA to the aspect of points that don't have any slope (slope=0). It will have to be completed by adding a sink resolution algorithm.
      0e1e6314
  5. 25 Feb, 2010 1 commit
  6. 23 Feb, 2010 2 commits
    • Mathias Bavay's avatar
      A problem was found during the intialization of the plugins (as well as... · 9bd7b27c
      Mathias Bavay authored
      A problem was found during the intialization of the plugins (as well as A3DIO): the parameters that were passed to initialize the local copies were not always initialized with the raw parameters passed to the constructor but usually with the copy of the previous element. This lead to some copies not to be up to date when calling their constructor (see A3DIO.cc for a clearer view!!).
      9bd7b27c
    • Mathias Bavay's avatar
      The write2DGrid members of the plugins now use the features of the Coords... · 4e158737
      Mathias Bavay authored
      The write2DGrid members of the plugins now use the features of the Coords object to output the grid in the input coordinate system (as specified in the io.ini file). A copy of the Coords object is made, so that it does not change the given grid. This is fixing issue 3
      4e158737
  7. 22 Feb, 2010 2 commits
    • Mathias Bavay's avatar
      The plugin's interface (IOInterface) has been slightly modified:... · 2ee54369
      Mathias Bavay authored
      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
      2ee54369
    • Mathias Bavay's avatar
      A few issues have been fixed in Coords: the copyProj method had a bug, the... · c930a817
      Mathias Bavay authored
      A few issues have been fixed in Coords: the copyProj method had a bug, the distance method now uses cartesian calculation if both projections are equal, a new getProj() method is now available (but it should be rarely needed). The GridxDObject::gridify method now correctly handles "NULL" projection and the Meteo2DInterpolator makes sure that all projections agree before doing the interpolations.
      c930a817
  8. 19 Feb, 2010 1 commit
    • Mathias Bavay's avatar
      Finally, the implementation of issue 35 is here... A few bugs left with the... · cdc01c4b
      Mathias Bavay authored
      Finally, the implementation of issue 35 is here... A few bugs left with the Coords class have been fixed (namely, the methods take 1 optional parameter and not more, because for this usage scenario it was way too dangerous and the user (myself in this case!) could call the method with the wrong parameter left empty). New mebers have been added: grid_i and grid_j as well as methods to deal with them. These contain the grid indices matching the position. Since these indices depend on the chosen DEM/grid, they are NOT updated by Coords but by Grid2DObject or Grid3DObject instead. If the user calls Coords::setLatLon() or Coords::setXY(), then these grid parameters are reset to nodata.
      
      A bug in a constructor of StationData has also been fixed (assigning a temporary object to a member of the class). Some bugs/unlucky deletes in the examples have been fixed (this is the price to pay for work too late at night!)
      
      New constants "lat_epsilon" and "lon_epsilon" have been created in IOUtils. They represent the smallest latitude/longitude resolution (ie: two points within lat_epsilon are considered to have the same latitude)
      cdc01c4b
  9. 18 Feb, 2010 1 commit
    • Mathias Bavay's avatar
      The constructor Coords(ConfigReader) was a bad idea... Convenient, but way too... · e02fa994
      Mathias Bavay authored
      The constructor Coords(ConfigReader) was a bad idea... Convenient, but way too specific. It has been removed. The documentation in the Coords class has been updated.
      
      A saner handling of nodata values by the plugins has been implemented. Now, each plugin should properly get its own internal definition of nodata and return data using IOUtils::nodata to the caller. A new method has been implemented in IOUtils to help cleaning a parameter for nodata.
      
      A check for xmlParseFile (used for compiling the Boschung plugin) was working poorly and has been commented out in configure.ac.
      
      Finally, more cleanup in the ph files has been performed.
      e02fa994
  10. 17 Feb, 2010 1 commit
    • Mathias Bavay's avatar
      The new Coords object is now used by all grids (Grid2DObject, Grid3DObject,... · 687c52df
      Mathias Bavay authored
      The new Coords object is now used by all grids (Grid2DObject, Grid3DObject, DEMObject) as well as by all plugins (but checking proper operation was not possible for GSNIO because of missing libraries on my system...). The documentation has been updated as well as the code examples. A few extra methods have been added when usage has shown the need/convenience of having them (specially for standardazing some processing called by the plugins). A few small bugs have been fixed (possibility of not updating or improperly updating the coordinates in some rare cases).
      
      The proper marshalling for Grid3DObject has been implemented (it was more or less a dummy method until now). One bug has been fixed for Proj4 support. The code of most of the plugins has been cleaned up in order to get rid of the few remaining "using namespace" in header files. 
      687c52df
  11. 16 Feb, 2010 2 commits
    • Mathias Bavay's avatar
      The class Stationdata now properly uses the new Coords class. All usual... · b40dedb4
      Mathias Bavay authored
      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.
      b40dedb4
    • Mathias Bavay's avatar
      The MapProj class has been renamed in Coords. It now contains the coordinates... · d393958b
      Mathias Bavay authored
      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.
      d393958b
  12. 15 Feb, 2010 1 commit
  13. 10 Feb, 2010 3 commits
  14. 09 Feb, 2010 1 commit
    • Mathias Bavay's avatar
      A few static members have been added to MapProj to handle latitude/longitude:... · 8fb751f9
      Mathias Bavay authored
      A few static members have been added to MapProj to handle latitude/longitude: a method for converting a decimal latitude or longitude to degrees, minutes, seconds (formatted as d°m's"),  a method for converting a string containing degrees, minutes, seconds to decimal latitude or longitude and a method for parsing a position expressed as latitude/longitude (given in a string) and returning decimal latitude and longitude. This is the implementation of issue 34.
      8fb751f9
  15. 05 Feb, 2010 1 commit
    • Mathias Bavay's avatar
      In the MapProj class, a new conversion has been added: UTM to/from WGS84.... · ba74049c
      Mathias Bavay authored
      In the MapProj class, a new conversion has been added: UTM to/from WGS84. Simply give "UTM" as the coordinate system and specify in the optional arguments the zone number (for example, 31T).
      
      A (tricky) error has been fixed in the VincentyDistance. The bearing that was chosen was the average between the initial and reverse bearing. That seemd a good idea at the time, but this made reprojecting a local grid computed using Vincenty impossible: the required bearing (starting from the reference point) is the initial bearing, the average one was sending us hundreds of kilometers away from the correct coordinate (when doing (lat,lon) -> local -> (lat,lon)). 
      
      Finally, a few more powN() methods have been added to IOUtils for convenience (yes, the projection business loves these!!)
      ba74049c
  16. 03 Feb, 2010 1 commit
    • Mathias Bavay's avatar
      The Special_PTS and CSpecialPointsArray structures have been renamed in... · 11d9c246
      Mathias Bavay authored
      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).
      11d9c246
  17. 29 Jan, 2010 1 commit
    • Mathias Bavay's avatar
      A bug was preventing RH interpolations from working (the TA grid was... · d5c34620
      Mathias Bavay authored
      A bug was preventing RH interpolations from working (the TA grid was initialized to size 0, and therefore the safety checks were later on stopping the interpolation of RH because the TA grid was of the wrong size). 
      
      A "sanitize" method has been added to DEMObject so that all points that have an elevation but no slope/azimuth/normals/curvature see their elevation set to nodata (so that testing the elevation of a point is enough to guarantee that all information is available). The caller has therefore to decide if he prefers potentially losing a few points to guarantee a more consistent DEM or not...
      d5c34620
  18. 28 Jan, 2010 2 commits
    • Mathias Bavay's avatar
      The parallelization was lagging behind, so this has been fixed: One internal... · f1989ba4
      Mathias Bavay authored
      The parallelization was lagging behind, so this has been fixed: One internal variable was not serialized in DEMObject, there was no serialization at all in Meteo2DInterpolator and some marshalling methods had to be written (in marshall_meteoio). The serialization of Meteo2DInterpolator should be tested however!
      
      The marshalling code has been cleaned up and some missing "std::" added in FilterAlgorithms (doxygen was complaining).
      f1989ba4
    • Mathias Bavay's avatar
      A new method "setDefaultAlgorithm" has been added to the DEMObject so that the... · 3e106b6b
      Mathias Bavay authored
      A new method "setDefaultAlgorithm" has been added to the DEMObject so that the caller can specify which slope computation algorithm to use. The default algorithm argument has also been added to the constructors (as optional argument). This means that each constructor MUST call setDefaultAlgorithm.
      
      A new slope computation algorithm has been added: FLEM for (Fleming and Hoffer, 1979). This algorithm is faster, simpler and usually better then the other ones (according to (Hodgson, >1997)).
      
      Finally, some benchmarks have been done comparing the current slope computation speed with the old implementation (which could not handle holes in DEM): the current method is only 5% slower and it can now handle holes!
      3e106b6b
  19. 27 Jan, 2010 1 commit
    • Mathias Bavay's avatar
      The DEMObject has been modified so that it can now correctly handle grids with... · 86afd8ff
      Mathias Bavay authored
      The DEMObject has been modified so that it can now correctly handle grids with nodata values when computing slope/azimuth/curvature (this is in effect the fix for issue 15). This is "best effort" approach: several strategies are applied if some points are missing in order to still be able to compute as much as possible the parameters for their neighbours (if the latter contain an elevation!). The resulting grids are consistent for slopes (ie: if the slope can be computed, then the azimuth too and the normals too) and the curvature is handled separately (ie: it is possible to find points where ONLY the curvature is nodata).
      
      Several inappropriate behaviors have been fixed for cells next to a nodata point (or next to an edge). This should have fixed issue 7.
      
      The necessary check have been added to libinterpol2D:SimpleDEMWindInterpolate
      86afd8ff
  20. 24 Jan, 2010 1 commit
    • Thomas Egger's avatar
      Added the MeanAvgFilter and updated the MedianAvgFilter. Now the position of... · e304828d
      Thomas Egger authored
      Added the MeanAvgFilter and updated the MedianAvgFilter. Now the position of the filter window can be defined. The keyword soft has the meaning that the configuration of the window position is not strict (it will adapt if there is not enough data available for the user defined window position). If both soft and the position for the window (left, right, center) are missing "center" is assumed. Usage:
      
      TA::filter1 = mean_avg
      TA::arg1   = soft right 10 100
      RH::filter1 = median_avg
      RH::arg1  = 10 200
      
      Meaning: use mean_avg filter on TA, the window shall be right leaning spanning at least 10 points and 100 minutes. Use median_avg filter on RH, the window shall be centered (strictly).
      e304828d
  21. 20 Jan, 2010 1 commit
  22. 19 Jan, 2010 2 commits
    • Mathias Bavay's avatar
      A mistake has been found in BoschungIO: the key for precipitation was wrong... · 4ba28348
      Mathias Bavay authored
      A mistake has been found in BoschungIO: the key for precipitation was wrong (we were reading the precipitation type as a precipitation amount, which was quite bad for the simulation!).
      
      A few missing cases of nodata have been identified (thanks Cyril!) and fixed in libinterpol2D
      4ba28348
    • Cyril Perot's avatar
      * Adds of singleton class DEMLOader in charge of loading and storing DEMObjects in a · be3d1842
      Cyril Perot authored
      dynamic use of meteoio (ie. dynamically loaded from an application -- for exemple from Java application with the JNI mechanism).
      This leads to save the dem file loading time in further interpolation (more than half the time is saved in some cases).
      
      * Tries to make the "dynamic" interpolation call thread-safe in a multithreaded context (ie. concurrent interpolation are called by 
      different threads) : 
      	-> identifies the Critical Section and the critical resources
      	-> use of a 'synchronized' java-like macro to isolate these sections and resources
      be3d1842
  23. 18 Jan, 2010 1 commit
    • Thomas Egger's avatar
      A new interface for the Meteo2DInterpolator: · 0637f7fd
      Thomas Egger authored
      void interpolate(const MeteoData::Parameters& meteoparam, Grid2DObject& result);
      
      The new Meteo2DInterpolator class parses the ConfigReader object passed to it and stores all possible algorithms for each MeteoData variable (user configured). In the next step the user configured algorithms shall be invoked and a quality estimator chooses the most appropiate of the algorithms to interpolate the 2D grid for a given meteo parameter.
      
      Adjustments needed to be made to the ConfigReader class (function findKeys) and a few comments have been added to MeteoFilter for more clarity of the ConfgReader parsing process.
      0637f7fd
  24. 14 Jan, 2010 2 commits
  25. 13 Jan, 2010 2 commits
    • Mathias Bavay's avatar
      The successfull call of MeteoIO from Java has been implemented by Cyril Perot... · 6ae67300
      Mathias Bavay authored
      The successfull call of MeteoIO from Java has been implemented by Cyril Perot but needed a few adjustments in MeteoIO. This commit makes the said adjustments: a few more "#ifdef _POPC_", a missing ConfgReader.addKey(key, section, value) and some previously private members of Meteo2DInterpolator now exposed. 
      
      The plugin unloading sections have been protected by ifndef _METEOIO_JNI because the current implementation of such Java integration uses JNI and does its own plugin loading/unloading.
      6ae67300
    • Mathias Bavay's avatar
      In an effort to make ConfigReader more flexible, its interface has been... · ec219986
      Mathias Bavay authored
      In an effort to make ConfigReader more flexible, its interface has been expanded: it is now possible to read several files into one ConfigReader, or to manually add key/value pairs and it is planned that a string containing command line arguments could be given to populate the internal map of ConfigReader.
      ec219986
  26. 12 Jan, 2010 1 commit