[GRASS-dev] odd behavior from t.register when loading from file and no "end date" is specified

GRASS GIS GRASS GIS developer
1

Hi,

I recently notices something when working with t.register and a large
collection of daily files. My typical work-flow is something like
this:

# make some data
r.mapcalc expression="prec_1 = 100"
r.mapcalc expression="prec_2 = 200"
r.mapcalc expression="prec_3 = 300"
r.mapcalc expression="prec_4 = 400"
r.mapcalc expression="prec_5 = 500"
r.mapcalc expression="prec_6 = 600"

# create a new space-time data set
t.create --o type=strds temporaltype=absolute \
    output=precip_abs title="Example" \
    descr="Example"

# generate a file describing the raster names and start dates
echo "prec_1|1981-01-01|
prec_2|1981-01-02|
prec_3|1981-01-03|
prec_4|1981-01-04|
prec_5|1981-01-05|
prec_6|1981-01-06|" > precip_abs.files

... In many cases the list of raster and dates is generated by parsing
raster names, like this:

g.list type=rast pattern="file_*" | \
awk -F '_' '{print
$1"_"$2"|"substr($2,1,4)"-"substr($2,5,2)"-"substr($2,7,2)}' >
somefile

... this is really handy when you have a lot of files (>10k), but
cannot generate both "start" and "stop" dates for the t.register input
file.

OK, well (unless I am mistaken) t.register should be able to figure
this out when invoked with the "-i" flag:

# register maps from file, filling-in stop dates
t.register --o -i input=precip_abs file=precip_abs.files type=raster
increment="1 day"

... however, this results in the following:

# double-check start | stop dates:
t.rast.list precip_abs

name|mapset|start_time|end_time
prec_1|PERMANENT|1981-01-02 00:00:00|1981-01-03 00:00:00
prec_2|PERMANENT|1981-01-03 00:00:00|1981-01-04 00:00:00
prec_3|PERMANENT|1981-01-04 00:00:00|1981-01-05 00:00:00
prec_4|PERMANENT|1981-01-05 00:00:00|1981-01-06 00:00:00
prec_5|PERMANENT|1981-01-06 00:00:00|1981-01-07 00:00:00
prec_6|PERMANENT|1981-01-07 00:00:00|1981-01-08 00:00:00

... these maps are offset by 1 day into the future.

Is this the intended result?

I am able to get my expected result if I fully specify the start and
stop dates in the t.register input file. This get a little tricky, but
(insert your favorite scripting language) can make the process of
adding 1 day to each line simple.

This is with grass_trunk as of:

Last Changed Rev: 66487
Last Changed Date: 2015-10-13 02:54:55 -0700 (Tue, 13 Oct 2015)

Am I abusing t.register or otherwise misinterpreting the manual pages?

Thanks,
Dylan

2

Hi Dylan,

I guess -i flag “might” (not sure) be incompatible with a file with start_time… so, if you have a list with mapname|start_time, you would only pass that and no need to set an increment really, because it would be implicit in the start_time (of course if your maps have different granularities, then you need to specify start and end time)… this is what I get with your example:

GRASS 7.1.svn (latlong_wgs84):~ > t.register --o input=precip_abs file=precip_abs.files type=raster
…

GRASS 7.1.svn (latlong_wgs84):~ > t.rast.list precip_abs
name>mapset>start_time|end_time
prec_1|pruebas|1981-01-01 00:00:00|None
prec_2|pruebas|1981-01-02 00:00:00|None
prec_3|pruebas|1981-01-03 00:00:00|None
prec_4|pruebas|1981-01-04 00:00:00|None
prec_5|pruebas|1981-01-05 00:00:00|None
prec_6|pruebas|1981-01-06 00:00:00|None

If I use the list of mapnames only (without start_time) and so, I set -i flag, increment=“1 days” and start=“1981-01-01”, then I get:

GRASS 7.1.svn (latlong_wgs84):~ > t.register --o -i input=precip_abs file=somefile type=raster increment=“1 days” start=“1981-01-01”
…
GRASS 7.1.svn (latlong_wgs84):~ > t.rast.list precip_abs

name>mapset>start_time|end_time
prec_1|pruebas|1981-01-01 00:00:00|1981-01-02 00:00:00
prec_2|pruebas|1981-01-02 00:00:00|1981-01-03 00:00:00
prec_3|pruebas|1981-01-03 00:00:00|1981-01-04 00:00:00
prec_4|pruebas|1981-01-04 00:00:00|1981-01-05 00:00:00
prec_5|pruebas|1981-01-05 00:00:00|1981-01-06 00:00:00
prec_6|pruebas|1981-01-06 00:00:00|1981-01-07 00:00:00

I’m using r66429

HTH,
Vero

···

2015-10-13 18:10 GMT-03:00 Dylan Beaudette <dylan.beaudette@gmail.com>:

Hi,

I recently notices something when working with t.register and a large
collection of daily files. My typical work-flow is something like
this:

make some data

r.mapcalc expression=“prec_1 = 100”
r.mapcalc expression=“prec_2 = 200”
r.mapcalc expression=“prec_3 = 300”
r.mapcalc expression=“prec_4 = 400”
r.mapcalc expression=“prec_5 = 500”
r.mapcalc expression=“prec_6 = 600”

create a new space-time data set

t.create --o type=strds temporaltype=absolute
output=precip_abs title=“Example”
descr=“Example”

generate a file describing the raster names and start dates

echo “prec_1|1981-01-01|
prec_2|1981-01-02|
prec_3|1981-01-03|
prec_4|1981-01-04|
prec_5|1981-01-05|
prec_6|1981-01-06|” > precip_abs.files

… In many cases the list of raster and dates is generated by parsing
raster names, like this:

g.list type=rast pattern=“file_*” |
awk -F ‘’ '{print
$1"“$2”|“substr($2,1,4)”-“substr($2,5,2)”-"substr($2,7,2)}’ >
somefile

… this is really handy when you have a lot of files (>10k), but
cannot generate both “start” and “stop” dates for the t.register input
file.

OK, well (unless I am mistaken) t.register should be able to figure
this out when invoked with the “-i” flag:

register maps from file, filling-in stop dates

t.register --o -i input=precip_abs file=precip_abs.files type=raster
increment=“1 day”

… however, this results in the following:

double-check start | stop dates:

t.rast.list precip_abs

name|mapset|start_time|end_time
prec_1|PERMANENT|1981-01-02 00:00:00|1981-01-03 00:00:00
prec_2|PERMANENT|1981-01-03 00:00:00|1981-01-04 00:00:00
prec_3|PERMANENT|1981-01-04 00:00:00|1981-01-05 00:00:00
prec_4|PERMANENT|1981-01-05 00:00:00|1981-01-06 00:00:00
prec_5|PERMANENT|1981-01-06 00:00:00|1981-01-07 00:00:00
prec_6|PERMANENT|1981-01-07 00:00:00|1981-01-08 00:00:00

… these maps are offset by 1 day into the future.

Is this the intended result?

I am able to get my expected result if I fully specify the start and
stop dates in the t.register input file. This get a little tricky, but
(insert your favorite scripting language) can make the process of
adding 1 day to each line simple.

This is with grass_trunk as of:

Last Changed Rev: 66487
Last Changed Date: 2015-10-13 02:54:55 -0700 (Tue, 13 Oct 2015)

Am I abusing t.register or otherwise misinterpreting the manual pages?

Thanks,
Dylan

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

3

On Wed, Oct 14, 2015 at 5:10 AM, Veronica Andreo <veroandreo@gmail.com> wrote:

Hi Dylan,

I guess -i flag "might" (not sure) be incompatible with a file with
start_time... so, if you have a list with mapname|start_time, you would only
pass that and no need to set an increment really, because it would be
implicit in the start_time (of course if your maps have different
granularities, then you need to specify start and end time)... this is what
I get with your example:

GRASS 7.1.svn (latlong_wgs84):~ > t.register --o input=precip_abs
file=precip_abs.files type=raster
...

GRASS 7.1.svn (latlong_wgs84):~ > t.rast.list precip_abs
name|mapset|start_time|end_time
prec_1|pruebas|1981-01-01 00:00:00|None
prec_2|pruebas|1981-01-02 00:00:00|None
prec_3|pruebas|1981-01-03 00:00:00|None
prec_4|pruebas|1981-01-04 00:00:00|None
prec_5|pruebas|1981-01-05 00:00:00|None
prec_6|pruebas|1981-01-06 00:00:00|None

Hi Veronica,

I have often wondered if some of the arguments to t.register were
mutually exclusive. Perhaps this is a documentation opportunity. Happy
to help with that.

The output you list above matches my observations. I can still do most
of my work with no end_time defined--the resulting STRDS is "point"
support--however, t.mapcalc complains when using multiple "point"
support STRDS as input. Thus, I have been trying to register my daily
data as "interval" support.

If I use the list of mapnames only (without start_time) and so, I set -i
flag, increment="1 days" and start="1981-01-01", then I get:

GRASS 7.1.svn (latlong_wgs84):~ > t.register --o -i input=precip_abs
file=somefile type=raster increment="1 days" start="1981-01-01"
...
GRASS 7.1.svn (latlong_wgs84):~ > t.rast.list precip_abs
name|mapset|start_time|end_time
prec_1|pruebas|1981-01-01 00:00:00|1981-01-02 00:00:00
prec_2|pruebas|1981-01-02 00:00:00|1981-01-03 00:00:00
prec_3|pruebas|1981-01-03 00:00:00|1981-01-04 00:00:00
prec_4|pruebas|1981-01-04 00:00:00|1981-01-05 00:00:00
prec_5|pruebas|1981-01-05 00:00:00|1981-01-06 00:00:00
prec_6|pruebas|1981-01-06 00:00:00|1981-01-07 00:00:00

Interesting! This is my "expected" output, and indeed I can replicate
this behavior on my machine. I am using r66489.

Can you reproduce the behavior as described in my original posting,
when using a file specifying the start date _and_ and arguments: "-i
increment='1 days'" ?

Thanks!
Dylan

I'm using r66429

HTH,
Vero

2015-10-13 18:10 GMT-03:00 Dylan Beaudette <dylan.beaudette@gmail.com>:

Hi,

I recently notices something when working with t.register and a large
collection of daily files. My typical work-flow is something like
this:

# make some data
r.mapcalc expression="prec_1 = 100"
r.mapcalc expression="prec_2 = 200"
r.mapcalc expression="prec_3 = 300"
r.mapcalc expression="prec_4 = 400"
r.mapcalc expression="prec_5 = 500"
r.mapcalc expression="prec_6 = 600"

# create a new space-time data set
t.create --o type=strds temporaltype=absolute \
    output=precip_abs title="Example" \
    descr="Example"

# generate a file describing the raster names and start dates
echo "prec_1|1981-01-01|
prec_2|1981-01-02|
prec_3|1981-01-03|
prec_4|1981-01-04|
prec_5|1981-01-05|
prec_6|1981-01-06|" > precip_abs.files

... In many cases the list of raster and dates is generated by parsing
raster names, like this:

g.list type=rast pattern="file_*" | \
awk -F '_' '{print
$1"_"$2"|"substr($2,1,4)"-"substr($2,5,2)"-"substr($2,7,2)}' >
somefile

... this is really handy when you have a lot of files (>10k), but
cannot generate both "start" and "stop" dates for the t.register input
file.

OK, well (unless I am mistaken) t.register should be able to figure
this out when invoked with the "-i" flag:

# register maps from file, filling-in stop dates
t.register --o -i input=precip_abs file=precip_abs.files type=raster
increment="1 day"

... however, this results in the following:

# double-check start | stop dates:
t.rast.list precip_abs

name|mapset|start_time|end_time
prec_1|PERMANENT|1981-01-02 00:00:00|1981-01-03 00:00:00
prec_2|PERMANENT|1981-01-03 00:00:00|1981-01-04 00:00:00
prec_3|PERMANENT|1981-01-04 00:00:00|1981-01-05 00:00:00
prec_4|PERMANENT|1981-01-05 00:00:00|1981-01-06 00:00:00
prec_5|PERMANENT|1981-01-06 00:00:00|1981-01-07 00:00:00
prec_6|PERMANENT|1981-01-07 00:00:00|1981-01-08 00:00:00

... these maps are offset by 1 day into the future.

Is this the intended result?

I am able to get my expected result if I fully specify the start and
stop dates in the t.register input file. This get a little tricky, but
(insert your favorite scripting language) can make the process of
adding 1 day to each line simple.

This is with grass_trunk as of:

Last Changed Rev: 66487
Last Changed Date: 2015-10-13 02:54:55 -0700 (Tue, 13 Oct 2015)

Am I abusing t.register or otherwise misinterpreting the manual pages?

Thanks,
Dylan
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

4

Hi Dylan,

2015-10-14 13:25 GMT-03:00 Dylan Beaudette <dylan.beaudette@gmail.com>:

On Wed, Oct 14, 2015 at 5:10 AM, Veronica Andreo <veroandreo@gmail.com>
wrote:
> Hi Dylan,
>
> I guess -i flag "might" (not sure) be incompatible with a file with
> start_time... so, if you have a list with mapname|start_time, you would
only
> pass that and no need to set an increment really, because it would be
> implicit in the start_time (of course if your maps have different
> granularities, then you need to specify start and end time)... this is
what
> I get with your example:
>
> GRASS 7.1.svn (latlong_wgs84):~ > t.register --o input=precip_abs
> file=precip_abs.files type=raster
> ...
>
> GRASS 7.1.svn (latlong_wgs84):~ > t.rast.list precip_abs
> name|mapset|start_time|end_time
> prec_1|pruebas|1981-01-01 00:00:00|None
> prec_2|pruebas|1981-01-02 00:00:00|None
> prec_3|pruebas|1981-01-03 00:00:00|None
> prec_4|pruebas|1981-01-04 00:00:00|None
> prec_5|pruebas|1981-01-05 00:00:00|None
> prec_6|pruebas|1981-01-06 00:00:00|None

Hi Veronica,

I have often wondered if some of the arguments to t.register were
mutually exclusive. Perhaps this is a documentation opportunity. Happy
to help with that.

yeah, well, I'm not really sure... but at least, when you pass a file with
start_time, and also set an increment, that start_time seems to changed
accordingly... So, as you set start_time 1981-01-01 and increment "1 days",
the strds starts in 1981-01-02...

The output you list above matches my observations. I can still do most
of my work with no end_time defined--the resulting STRDS is "point"
support--however, t.mapcalc complains when using multiple "point"
support STRDS as input. Thus, I have been trying to register my daily
data as "interval" support.

I'm not sure to understand what you mean with "point" support.
But t.rast.mapcalc sometimes fail with multiple input strds because of a
simple replace approach [0]... have you tried the same operations with
t.rast.algebra??

If I use the list of mapnames only (without start_time) and so, I set -i
> flag, increment="1 days" and start="1981-01-01", then I get:
>
> GRASS 7.1.svn (latlong_wgs84):~ > t.register --o -i input=precip_abs
> file=somefile type=raster increment="1 days" start="1981-01-01"
> ...
> GRASS 7.1.svn (latlong_wgs84):~ > t.rast.list precip_abs
> name|mapset|start_time|end_time
> prec_1|pruebas|1981-01-01 00:00:00|1981-01-02 00:00:00
> prec_2|pruebas|1981-01-02 00:00:00|1981-01-03 00:00:00
> prec_3|pruebas|1981-01-03 00:00:00|1981-01-04 00:00:00
> prec_4|pruebas|1981-01-04 00:00:00|1981-01-05 00:00:00
> prec_5|pruebas|1981-01-05 00:00:00|1981-01-06 00:00:00
> prec_6|pruebas|1981-01-06 00:00:00|1981-01-07 00:00:00

Interesting! This is my "expected" output, and indeed I can replicate
this behavior on my machine. I am using r66489.

Can you reproduce the behavior as described in my original posting,
when using a file specifying the start date _and_ and arguments: "-i
increment='1 days'" ?

Yes, and I got the same results you posted.

I believe the best practice would be to use one approach or the other,
i.e.: only the file with mapnames and start_time (and optionally end_time),
or the list of mapnames (either as `g.list ... ` or in a text file), the -i
flag and increment parameter.

Maybe this wiki is also helpful somehow:
https://grasswiki.osgeo.org/wiki/Temporal_data_processing
Contributions, corrections, sugestions are most welcome :slight_smile:

Cheers,
Vero

[0] https://trac.osgeo.org/grass/ticket/2735

5

Hi all,
sorry for my late response.

The documentation is unfortunately not clear about the use of "-i"
flag, increment and text files. I will update this.

The main idea is:
The -i flag and the increment option will only work if a start time
was defined at the command line (no end time!).
In case time stamps are set in the input file, then the -i flag and
the increment option should not be used.

If you have time instances in the text files only but you need time intervals,
then use t.snap on the STDS to create a correct temporal topology
(maps use the start time of a potential predecessor as end time).

About the input file:
please use this format only:

name

or

name | start

or

name | start | end

do not put an additional separator at the end of the line, since this
will confuse the simple parsing approach in t.register.

Best regards
Soeren

2015-10-14 19:26 GMT+02:00 Veronica Andreo <veroandreo@gmail.com>:

Hi Dylan,

2015-10-14 13:25 GMT-03:00 Dylan Beaudette <dylan.beaudette@gmail.com>:

On Wed, Oct 14, 2015 at 5:10 AM, Veronica Andreo <veroandreo@gmail.com>
wrote:
> Hi Dylan,
>
> I guess -i flag "might" (not sure) be incompatible with a file with
> start_time... so, if you have a list with mapname|start_time, you would
> only
> pass that and no need to set an increment really, because it would be
> implicit in the start_time (of course if your maps have different
> granularities, then you need to specify start and end time)... this is
> what
> I get with your example:
>
> GRASS 7.1.svn (latlong_wgs84):~ > t.register --o input=precip_abs
> file=precip_abs.files type=raster
> ...
>
> GRASS 7.1.svn (latlong_wgs84):~ > t.rast.list precip_abs
> name|mapset|start_time|end_time
> prec_1|pruebas|1981-01-01 00:00:00|None
> prec_2|pruebas|1981-01-02 00:00:00|None
> prec_3|pruebas|1981-01-03 00:00:00|None
> prec_4|pruebas|1981-01-04 00:00:00|None
> prec_5|pruebas|1981-01-05 00:00:00|None
> prec_6|pruebas|1981-01-06 00:00:00|None

Hi Veronica,

I have often wondered if some of the arguments to t.register were
mutually exclusive. Perhaps this is a documentation opportunity. Happy
to help with that.

yeah, well, I'm not really sure... but at least, when you pass a file with
start_time, and also set an increment, that start_time seems to changed
accordingly... So, as you set start_time 1981-01-01 and increment "1 days",
the strds starts in 1981-01-02...

The output you list above matches my observations. I can still do most
of my work with no end_time defined--the resulting STRDS is "point"
support--however, t.mapcalc complains when using multiple "point"
support STRDS as input. Thus, I have been trying to register my daily
data as "interval" support.

I'm not sure to understand what you mean with "point" support.
But t.rast.mapcalc sometimes fail with multiple input strds because of a
simple replace approach [0]... have you tried the same operations with
t.rast.algebra??

> If I use the list of mapnames only (without start_time) and so, I set -i
> flag, increment="1 days" and start="1981-01-01", then I get:
>
> GRASS 7.1.svn (latlong_wgs84):~ > t.register --o -i input=precip_abs
> file=somefile type=raster increment="1 days" start="1981-01-01"
> ...
> GRASS 7.1.svn (latlong_wgs84):~ > t.rast.list precip_abs
> name|mapset|start_time|end_time
> prec_1|pruebas|1981-01-01 00:00:00|1981-01-02 00:00:00
> prec_2|pruebas|1981-01-02 00:00:00|1981-01-03 00:00:00
> prec_3|pruebas|1981-01-03 00:00:00|1981-01-04 00:00:00
> prec_4|pruebas|1981-01-04 00:00:00|1981-01-05 00:00:00
> prec_5|pruebas|1981-01-05 00:00:00|1981-01-06 00:00:00
> prec_6|pruebas|1981-01-06 00:00:00|1981-01-07 00:00:00

Interesting! This is my "expected" output, and indeed I can replicate
this behavior on my machine. I am using r66489.

Can you reproduce the behavior as described in my original posting,
when using a file specifying the start date _and_ and arguments: "-i
increment='1 days'" ?

Yes, and I got the same results you posted.

I believe the best practice would be to use one approach or the other, i.e.:
only the file with mapnames and start_time (and optionally end_time), or the
list of mapnames (either as `g.list ... ` or in a text file), the -i flag
and increment parameter.

Maybe this wiki is also helpful somehow:
https://grasswiki.osgeo.org/wiki/Temporal_data_processing
Contributions, corrections, sugestions are most welcome :slight_smile:

Cheers,
Vero

[0] https://trac.osgeo.org/grass/ticket/2735

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

6

On Sun, Oct 18, 2015 at 3:24 PM, Sören Gebbert
<soerengebbert@googlemail.com> wrote:

Hi all,
sorry for my late response.

The documentation is unfortunately not clear about the use of "-i"
flag, increment and text files. I will update this.

The main idea is:
The -i flag and the increment option will only work if a start time
was defined at the command line (no end time!).
In case time stamps are set in the input file, then the -i flag and
the increment option should not be used.

Wish:
It would be great to either drop -i and let t.register manage it by
itself upon presence of start time + no end time + increment defined
(warning/error otherwise).
Or at least, to generate some more messages in case of conflicting settings.
I had the same problem myself and it took me (too) long to identify the problem.

thanks
Markus

7

Hi,

2015-10-18 17:01 GMT+02:00 Markus Neteler <neteler@osgeo.org>:

On Sun, Oct 18, 2015 at 3:24 PM, Sören Gebbert
<soerengebbert@googlemail.com> wrote:

Hi all,
sorry for my late response.

The documentation is unfortunately not clear about the use of "-i"
flag, increment and text files. I will update this.

The main idea is:
The -i flag and the increment option will only work if a start time
was defined at the command line (no end time!).
In case time stamps are set in the input file, then the -i flag and
the increment option should not be used.

Wish:
It would be great to either drop -i and let t.register manage it by
itself upon presence of start time + no end time + increment defined
(warning/error otherwise).
Or at least, to generate some more messages in case of conflicting settings.
I had the same problem myself and it took me (too) long to identify the problem.

Using an increment does not automatically mean to create time
intervals. It can also be used to create time instances.
I will try to add some more warnings about option usage.

Best regards
Soeren

thanks
Markus

8

Thank you Soeren, your notes are quite helpful. Along these lines, the
new (to me) temporal framework in GRASS is great--it has made many
routine analysis much more efficient, and, it has made many new types
of analysis possible. Thank you and to others that have contributed to
this work!

I'll be sure to review the updated manual pages.

Dylan

On Sun, Oct 18, 2015 at 6:24 AM, Sören Gebbert
<soerengebbert@googlemail.com> wrote:

Hi all,
sorry for my late response.

The documentation is unfortunately not clear about the use of "-i"
flag, increment and text files. I will update this.

The main idea is:
The -i flag and the increment option will only work if a start time
was defined at the command line (no end time!).
In case time stamps are set in the input file, then the -i flag and
the increment option should not be used.

If you have time instances in the text files only but you need time intervals,
then use t.snap on the STDS to create a correct temporal topology
(maps use the start time of a potential predecessor as end time).

About the input file:
please use this format only:

name

or

name | start

or

name | start | end

do not put an additional separator at the end of the line, since this
will confuse the simple parsing approach in t.register.

Best regards
Soeren

2015-10-14 19:26 GMT+02:00 Veronica Andreo <veroandreo@gmail.com>:

Hi Dylan,

2015-10-14 13:25 GMT-03:00 Dylan Beaudette <dylan.beaudette@gmail.com>:

On Wed, Oct 14, 2015 at 5:10 AM, Veronica Andreo <veroandreo@gmail.com>
wrote:
> Hi Dylan,
>
> I guess -i flag "might" (not sure) be incompatible with a file with
> start_time... so, if you have a list with mapname|start_time, you would
> only
> pass that and no need to set an increment really, because it would be
> implicit in the start_time (of course if your maps have different
> granularities, then you need to specify start and end time)... this is
> what
> I get with your example:
>
> GRASS 7.1.svn (latlong_wgs84):~ > t.register --o input=precip_abs
> file=precip_abs.files type=raster
> ...
>
> GRASS 7.1.svn (latlong_wgs84):~ > t.rast.list precip_abs
> name|mapset|start_time|end_time
> prec_1|pruebas|1981-01-01 00:00:00|None
> prec_2|pruebas|1981-01-02 00:00:00|None
> prec_3|pruebas|1981-01-03 00:00:00|None
> prec_4|pruebas|1981-01-04 00:00:00|None
> prec_5|pruebas|1981-01-05 00:00:00|None
> prec_6|pruebas|1981-01-06 00:00:00|None

Hi Veronica,

I have often wondered if some of the arguments to t.register were
mutually exclusive. Perhaps this is a documentation opportunity. Happy
to help with that.

yeah, well, I'm not really sure... but at least, when you pass a file with
start_time, and also set an increment, that start_time seems to changed
accordingly... So, as you set start_time 1981-01-01 and increment "1 days",
the strds starts in 1981-01-02...

The output you list above matches my observations. I can still do most
of my work with no end_time defined--the resulting STRDS is "point"
support--however, t.mapcalc complains when using multiple "point"
support STRDS as input. Thus, I have been trying to register my daily
data as "interval" support.

I'm not sure to understand what you mean with "point" support.
But t.rast.mapcalc sometimes fail with multiple input strds because of a
simple replace approach [0]... have you tried the same operations with
t.rast.algebra??

> If I use the list of mapnames only (without start_time) and so, I set -i
> flag, increment="1 days" and start="1981-01-01", then I get:
>
> GRASS 7.1.svn (latlong_wgs84):~ > t.register --o -i input=precip_abs
> file=somefile type=raster increment="1 days" start="1981-01-01"
> ...
> GRASS 7.1.svn (latlong_wgs84):~ > t.rast.list precip_abs
> name|mapset|start_time|end_time
> prec_1|pruebas|1981-01-01 00:00:00|1981-01-02 00:00:00
> prec_2|pruebas|1981-01-02 00:00:00|1981-01-03 00:00:00
> prec_3|pruebas|1981-01-03 00:00:00|1981-01-04 00:00:00
> prec_4|pruebas|1981-01-04 00:00:00|1981-01-05 00:00:00
> prec_5|pruebas|1981-01-05 00:00:00|1981-01-06 00:00:00
> prec_6|pruebas|1981-01-06 00:00:00|1981-01-07 00:00:00

Interesting! This is my "expected" output, and indeed I can replicate
this behavior on my machine. I am using r66489.

Can you reproduce the behavior as described in my original posting,
when using a file specifying the start date _and_ and arguments: "-i
increment='1 days'" ?

Yes, and I got the same results you posted.

I believe the best practice would be to use one approach or the other, i.e.:
only the file with mapnames and start_time (and optionally end_time), or the
list of mapnames (either as `g.list ... ` or in a text file), the -i flag
and increment parameter.

Maybe this wiki is also helpful somehow:
https://grasswiki.osgeo.org/wiki/Temporal_data_processing
Contributions, corrections, sugestions are most welcome :slight_smile:

Cheers,
Vero

[0] https://trac.osgeo.org/grass/ticket/2735

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