[GRASS-dev] Seasonal temporal granularity

lucadelu · August 13, 2015, 12:35pm

Hi devs,

I would like to have seasonal granularity into Temporal Framework, is
this possible?

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

Soeren_Gebbert2 · August 13, 2015, 3:55pm

Hi Luca,
what kind of seasons do you think of?

Meteorological seasons?
They have a granularity of 3 months, so this should be possible already.
If you need the astronomical seasons this is unfortunately not
possible, since a user defined granularity is not supported.

Why do you need a seasonal granularity?

Best regards
Soeren

2015-08-13 14:35 GMT+02:00 Luca Delucchi <lucadeluge@gmail.com>:

Hi devs,

I would like to have seasonal granularity into Temporal Framework, is
this possible?

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

neteler · August 13, 2015, 8:08pm

Hi Soeren,

On Thu, Aug 13, 2015 at 5:55 PM, Sören Gebbert
<soerengebbert@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

Soeren_Gebbert2 · August 13, 2015, 9:35pm

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@osgeo.org>:

Hi Soeren,

On Thu, Aug 13, 2015 at 5:55 PM, Sören Gebbert
<soerengebbert@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

Soeren_Gebbert2 · August 13, 2015, 10:35pm

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@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@osgeo.org>:

Hi Soeren,

On Thu, Aug 13, 2015 at 5:55 PM, Sören Gebbert
<soerengebbert@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

lucadelu · August 19, 2015, 9:58am

On 13 August 2015 at 23:35, Sören Gebbert <soerengebbert@googlemail.com> wrote:

Dear Markus and Luca,

Dear Soeren,

sorry for delay

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.

more than in t.register I would like to have "astro_seasons"
granularity for aggregation,

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.

yes this is a useful starting point, but probably something else
should be modify, could you give me other hints?

Best regards
Soeren

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

lucadelu · August 19, 2015, 10:00am

On 14 August 2015 at 00:35, Sören Gebbert <soerengebbert@googlemail.com> wrote:

Hi,

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:

yes in t.register there aren't problems...

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.

for the aggregation I think this is needed...
how can I calculate average seasonal temperature starting from a daily
temperatures temporal dataset?

Best regards
Soeren

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

Soeren_Gebbert2 · August 19, 2015, 1:46pm

Hi Luca,

Am 19.08.2015 12:01 schrieb “Luca Delucchi” <lucadeluge@gmail.com>:

On 14 August 2015 at 00:35, Sören Gebbert <soerengebbert@googlemail.com> wrote:

Hi,

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:

yes in t.register there aren’t problems…

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.

for the aggregation I think this is needed…
how can I calculate average seasonal temperature starting from a daily
temperatures temporal dataset?

Use t.rast.aggregate.ds, the input is the daily strds, the sampling stds should have seasonal intervals. Then use average as method. The output will have seasonal aggregated temperatures.

Best regards
Soeren

Best regards
Soeren

–
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

veroandreo · August 27, 2015, 8:02pm

Ciao Luca,

Just following the example in t.rast.aggregate.ds manual page, I added a section for seasonal aggregation [0] to the “Temporal data processing” wiki, showing how to get astro_seasonal aggregation from a daily time series. I guess you already solved the problem, but at least it is there for future reference

It would be awesome, anyway, to have astro_season as a predefined granularity!! Way more simple!!!

Cheers,
Vero

[0] https://grasswiki.osgeo.org/wiki/Temporal_data_processing/seasonal_aggregation

···

2015-08-19 10:46 GMT-03:00 Sören Gebbert <soerengebbert@googlemail.com>:

Hi Luca,

Am 19.08.2015 12:01 schrieb “Luca Delucchi” <lucadeluge@gmail.com>:

On 14 August 2015 at 00:35, Sören Gebbert <soerengebbert@googlemail.com> wrote:

Hi,

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:

yes in t.register there aren’t problems…

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.

for the aggregation I think this is needed…
how can I calculate average seasonal temperature starting from a daily
temperatures temporal dataset?

Use t.rast.aggregate.ds, the input is the daily strds, the sampling stds should have seasonal intervals. Then use average as method. The output will have seasonal aggregated temperatures.

Best regards
Soeren

Best regards
Soeren

–
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev