Hi, to reduce a bit of confusion. You can apply a time interval of arbitrary size to a map layer. Use the input file option of t.register and specify the interval size in the input file:
name|start_time|end_time map_1|2001-03-22 00:00:00|2001-06-21 00:00:00 map_2|2001-06-21 00:00:00|2001-09-24 00:00:00 map_3|2001-09-24 00:00:00|2001-12-21 00:00:00 map_4|2001-12-21 00:00:00|2002-03-22 00:00:00 ... Be aware that time intervals in the temporal framework are left closed, right open intervals. Hence, the end time is not part of the interval, but the start time of a potential successor. This assures gap free creation of temporal topological correct time series. The computed granularity of the resulting space-time dataset (STDS) will be 1 day, since 1 day is the greatest common divider of all the seasonal time intervals in the STDS. IMHO, there is no urgent need to support a user defined granularity in the temporal framework. The Gregorian Calendar hierarchy is almost sufficient. Best regards Soeren 2015-08-13 23:35 GMT+02:00 Sören Gebbert <[email protected]>: > Dear Markus and Luca, > feel free to implement user defined granularities in t.register. It > should be convenient to use something like "astro_seasons" as > identifier to apply the astronomical seasons to map layers that should > be registered in the temporal database. > However, the computed granularity of the resulting space-time dataset > will be 1 day, unless you modify the granularity computation in > lib/python/temporal/temporal_granularity.py to acknowledge user > defined granularities. Which would be really nice indeed. > > Best regards > Soeren > > > 2015-08-13 22:08 GMT+02:00 Markus Neteler <[email protected]>: >> Hi Soeren, >> >> On Thu, Aug 13, 2015 at 5:55 PM, Sören Gebbert >> <[email protected]> wrote: >>> Hi Luca, >>> what kind of seasons do you think of? >> >> For example, we would need something like this (Northern hemisphere): >> - spring: 22/03/ .. 20/06/ >> - summer: 21/06/ .. 23/09/ >> - autumn: 24/09/ .. 20/12/ >> - winter: 21/12/ .. 21/03/ >> >> It would be *really* good to let the user decide the start/end date of >> the seasons. >> >> thanks >> Markus _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
