Time series development

This page is born out of discussions in Lausanne. A lot of people seem to be interested in having some standardized, documented format for dealing with time series in GRASS, so that we can deal with data (e.g. climate station, water gauges), link with models, etc., without having to come up with a custom solution each time. This could also lead to modules to help with interpolation to deal with missing values, etc.

There was also discussion of possibly setting up a mailing list. Do we want this?

I would vote against just-another-mailing list Neteler 23:51, 18 September 2006 (CEST)

Ideas from MN

• each imported raster map get's automatically "registered" in an SQL table
  • Table structure:
    • map name
    • map creator (optional)
    • time stamp of import
    • time stamp of map production (optional)
    • time range of validity (optional)
• g.list, g.rename etc. tools have a new "where" parameter do search maps in this table
• g.remove will also remove row from SQL table
• SQL commands can be used for search by time stamps

maxi's proposal

• what about a table with time series (sort of header of each time series) and another table for aech time serie with a list of associated filename and related timestamp?
  • time series head table structure:
    • series name
    • creator name
    • timestamp of creation
    • range of validity
    • time step
    • ....
  • time serie associated map (table named like the related time serie):
    • timestamp
    • map name
    • timestamp of import

Open Issues

• will 'g.list rast' show also rasters belonging to time series?
• how to deal with huge file number in a folder? (very long serie often deals with a huge number of maps)
  • limitation: how many rasters can a folder contain ('fileno' in /etc/security/limits.conf).
  • efficiency: huge number of files will tremendiously slow down each map listing procedures.
• associated color table: only one color table should serve one series (avoid multiple color table for each map)