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

[Dylan Beaudette]

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 at 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 at gmail.com>:
>> 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
>>
>>
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev