[GRASS-dev] Seasonal temporal granularity

[Sören Gebbert]

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 <soerengebbert at googlemail.com>:
> 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 <neteler at osgeo.org>:
>> Hi Soeren,
>>
>> On Thu, Aug 13, 2015 at 5:55 PM, Sören Gebbert
>> <soerengebbert at googlemail.com> 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