Hei Sören, Thanks for your reply. Good to know that my solutions were not too far off. So, I feel I start getting better understanding of the TGRASS framework. And I am implementing some of your suggestions on organizing time series data in the email exchange we had earlier (http://osgeo-org.1560.x6.nabble.com/Organizing-spatial-time-series-data-for-mixed-GIS-environments-td5092505.html#a5092887). I was not fully aware of the functionality of t.support, so that hint was helpful too! I shall have a look at the naming options in t.rast.aggregate, esp. because renaming seems to be tricky with external data (http://trac.osgeo.org/grass/ticket/2282).
Again, thanks for helping! Cheers Stefan P.S.: BTW, I already made a patch in order to speed up aggregation.py (http://trac.osgeo.org/grass/ticket/2281), hope that one is valid / useful. -----Original Message----- From: Sören Gebbert [mailto:soerengebb...@googlemail.com] Sent: 6. mai 2014 21:09 To: Blumentrath, Stefan Cc: GRASS user list Subject: Re: [GRASS-user] Continuously updating space time datasets Hi Stefan, 2014-04-29 18:11 GMT+02:00 Blumentrath, Stefan <stefan.blumentr...@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@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
