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

Veronica Andreo veroandreo at gmail.com
Wed Oct 14 10:26:31 PDT 2015


Hi Dylan,

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

> On Wed, Oct 14, 2015 at 5:10 AM, Veronica Andreo <veroandreo at 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 :)

Cheers,
Vero

[0] https://trac.osgeo.org/grass/ticket/2735
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20151014/a2632deb/attachment-0001.html>


More information about the grass-dev mailing list