Opened 11 years ago
Closed 7 years ago
#2294 closed enhancement (fixed)
t.rast.aggregate: Name output rasters based on start-time
Reported by: | sbl | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 7.4.0 |
Component: | Temporal | Version: | svn-trunk |
Keywords: | t.rast.aggregate | Cc: | |
CPU: | All | Platform: | All |
Description
Using a numerical suffix for aggregated time series data makes it less intuitive to use the results outside the TGRASS framework. One has to look up the time stamp for e.g. a rastermap "temperature_avg_months_317" in order to know which time periode it refers to (even those people who produced it), while "temperature_avg_months_1989_09" already tells something.
Please find attached a proposal for naming output rasters based on start time - truncated according to granularity, implemented in a flag (s).
The attached patch is a modification of a patch I made for GRAS 7.0 wich I currently use and where it works fine for absolute time datasets. Not sure if it is suitable for relative or cyclic time though and it has not been tested with GRASS 7.1. So it needs a critical review in any case.
I do not know if such a solution would be relevant for t.rast.accumulate too (I have not used the module yet)...
If you find it useful I can send a patch for GRASS 7.0 too.
Attachments (2)
Change History (15)
by , 11 years ago
Attachment: | time_suffix_modules.diff added |
---|
by , 11 years ago
Attachment: | time_suffix_lib.diff added |
---|
comment:1 by , 10 years ago
Component: | Default → Temporal |
---|---|
CPU: | Unspecified → All |
Platform: | Unspecified → All |
comment:2 by , 10 years ago
comment:3 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Great thanks! Closing the ticket.
follow-ups: 5 7 comment:4 by , 10 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
I am reopening this ticket because there are unsolved issues here.
- Can this patch handle relative timestamp?
- We should keep option to choose between the temporal and numerical suffix. Possibly as a parameter?
- With numerical suffix, it should pad the number with zeros.
- This should be applied to all t.* modules generating new maps.
follow-up: 6 comment:5 by , 10 years ago
Replying to annakrat:
I am reopening this ticket because there are unsolved issues here.
- Can this patch handle relative timestamp?
- We should keep option to choose between the temporal and numerical suffix. Possibly as a parameter?
- With numerical suffix, it should pad the number with zeros.
I did that in r61888.
- This should be applied to all t.* modules generating new maps.
comment:6 by , 10 years ago
comment:7 by , 9 years ago
Replying to annakrat:
I am reopening this ticket because there are unsolved issues here.
- Can this patch handle relative timestamp?
- We should keep option to choose between the temporal and numerical suffix. Possibly as a parameter?
- With numerical suffix, it should pad the number with zeros.
- This should be applied to all t.* modules generating new maps.
After discussion in mailing list we replace -s
flag with suffix
option, this is done for most of the involved modules in r67935, r67936, r67939, r67940, r67942, r67944. Missing modules will be implemented in the next days.
comment:8 by , 9 years ago
Other modules modified in r67944.
I also implemented algebra and mapcalc modules but there are still some errors, using testsuite. I will investigate in the next days.
comment:11 by , 8 years ago
Milestone: | 7.2.1 → 7.2.2 |
---|
comment:12 by , 7 years ago
Milestone: | 7.2.2 → 7.4.0 |
---|
All enhancement tickets should be assigned to 7.4 milestone.
comment:13 by , 7 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Closing this as fixed, as remaining modules that should get the suffix option are addressed here: https://trac.osgeo.org/grass/ticket/3302
Many thanks for your patches.
I have integrated it in r61066 and modified the aggregation methods to allow parallel processing and faster metadata management. The new aggregation methods are experimental, hence no backport to 7.0 is planned right now. Further testing is needed.
Your map name suffix approach is now available as library method and can be reused in other modules as well.