[GRASS-user] Continuously updating space time datasets

[Sören Gebbert]

Hi Stefan,

2014-04-29 18:11 GMT+02:00 Blumentrath, Stefan <Stefan.Blumentrath at nina.no>:
> Hi,
>
> I am trying to (re-) organize some of our climate data based on continuously updated daily time series in the TGRASS framework which I plan to update in chron-jobs.
>
> My question is, is there a recommended approach for updating existing (aggregated) time series.
>
> I see mainly two different scenarios,
> 1) new maps may be added at the end of (aggregated) time series (e.g. monthly temperature for new month aggregated from daily temperature raster) and

You can add new maps with un-ordered time stamps to a space time
datasets anytime, it is simply an entry in a database. The temporal
correct ordering is performed in case of a select query.

> 2) existing maps may be replaced for datasets which have been modified (e.g. updated MODIS tiles) after a time series has been created.

You can overwrite existing maps and update the space time datasets in
which they are registered with t.support.

>
>  Am I right that 1) would require
> a) to simply to register new raw data (e.g. new days with temperature data) while I
> b) would have to create a temporary time series which I use for aggregating, for so being able to register the new aggregated maps to the monthly time series?

Yes, that's the approach i would suggest.

> In order to avoid naming conflicts I would also have to use temporary names, which I then can rename according to target
series, since new maps created with t.rast.aggregate will start with 0 again?

Yes, they will start with _0 again.

> Btw. is there a possibility to use e.g. start dates instead of the sequence 0,1,2 ... (this would also make map names more intuitive)? In any case I would like to avoid to update many years when I get new data only for a few new month or weeks. So I am grateful for any hint in this direction.

Sure, you can simply add an option to t.rast.aggregate to start with a
specific offset when numbering the maps. The code shouldn't be to hard
to understand.

>
> For 2) changes can happen across the entire time series and for single time periods (single days or weeks).  In this case I would have to unregister outdated maps first and then proceed like in 2. Only that - for aggregated time series - I would have to do so for every time period of a space time data set which contains underlying modified data, right?

Right.You have to unregister outdated maps, unless the new maps have
exactly the same time stamp, then you can overwrite them and update
the space time dataset with t.support.

But you can also remove the outdated maps, add new maps and run
t.support to automatically detect removed maps and to update the space
time dataset.

>
> I hope my problem / aim is understandable and my approach is to some degree reasonable. However, I wished there was a more elegant / efficient solution for that?

I hope i could give a meaningful answer.

Best regards
Soeren

btw.
Please use the latest svn version of grass7.1. I made some performance
improvements at the end of last year so that the sqlite and postgresql
backends should work much faster with tens of thousands of maps.



>
> Thanks in advance.
> Stefan
> _______________________________________________
> grass-user mailing list
> grass-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user