Opened 3 years ago

Closed 3 years ago

#3168 closed defect (fixed)

Behavior of t.register when r.timestamp was used

Reported by: wenzeslaus Owned by: grass-dev@…
Priority: normal Milestone: 7.2.0
Component: Temporal Version: svn-trunk
Keywords: t.create, t.register, r.timestamp, G_write_raster_timestamp Cc:
CPU: Unspecified Platform: Unspecified

Description

I'm trying to figure out what is the right behavior and usage of t.register in case when the raster map already has a "simple GRASS" time stamp (managed e.g. by r.timestamp).

For example, r.sim.water with -t produces time series which has time stamps from G_write_raster_timestamp(). The time stamps are relative.

Later, when you create a temporal dataset using t.create and set absolute time and use t.register to register the map or maps providing the start time and increment, you get an error saying that the time and date provided as start cannot be converted to integer.

Here is the code to reproduce it:

Error: Failed to load processor bash
No macro or processor named 'bash' found

And this is the error:

ERROR: invalid literal for int() with base 10: '2015-01-01 00:01:00'

It comes from:

if ttype == "absolute":
    ...
else:
    start_time = int(start)  # here

The time stamp is read from the spatial database in register.py:

if not is_in_db:
    map.read_timestamp_from_grass()

The condition doesn't depend on the input parameters to t.register and the behavior seems to be unexpected from the user point of view (plus of course there should be no low-level error like this one).

Change History (5)

comment:1 Changed 3 years ago by huhabla

This is indeed a strange error. I will fix the register method to use only the time stamp from the spatial database, when no time stamp was provided on the command line or in the input file.

One reason why this error happened is that r.sim.water creates a relative time stamp and you specified an absolute time stamp on the command line. Hence, the wrong time stamp conversion.

Interesting error case that i did not test.

comment:2 Changed 3 years ago by huhabla

This issue should be fixed in r69586.

comment:3 Changed 3 years ago by wenzeslaus

Thanks. Works for me now. And the date in the spatial database is overwritten.

> r.timestamp depth.02
1 Jan 2015 00:01:00

This should be probably backported.

comment:4 in reply to:  2 ; Changed 3 years ago by neteler

Replying to huhabla:

This issue should be fixed in r69586.

Backported in r69802. Can we close this?

comment:5 in reply to:  4 Changed 3 years ago by wenzeslaus

Resolution: fixed
Status: newclosed

Replying to neteler:

Backported in r69802. Can we close this?

Yes.

Note: See TracTickets for help on using tickets.