Re: [GRASS-dev] [GRASS GIS] #3168: Behavior of t.register when r.timestamp was used

2016-11-13 Thread GRASS GIS
#3168: Behavior of t.register when r.timestamp was used
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Temporal|Version:  svn-trunk
Resolution:  fixed   |   Keywords:  t.create, t.register, r.timestamp,
   CPU:  |  G_write_raster_timestamp
  Unspecified|   Platform:  Unspecified
-+-
Changes (by wenzeslaus):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Replying to [comment:4 neteler]:
 > Backported in r69802. Can we close this?

 Yes.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3168: Behavior of t.register when r.timestamp was used

2016-11-13 Thread GRASS GIS
#3168: Behavior of t.register when r.timestamp was used
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Temporal|Version:  svn-trunk
Resolution:  |   Keywords:  t.create, t.register, r.timestamp,
   CPU:  |  G_write_raster_timestamp
  Unspecified|   Platform:  Unspecified
-+-

Comment (by neteler):

 Replying to [comment:2 huhabla]:
 > This issue should be fixed in r69586.

 Backported in r69802. Can we close this?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3168: Behavior of t.register when r.timestamp was used

2016-09-28 Thread GRASS GIS
#3168: Behavior of t.register when r.timestamp was used
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Temporal|Version:  svn-trunk
Resolution:  |   Keywords:  t.create, t.register, r.timestamp,
   CPU:  |  G_write_raster_timestamp
  Unspecified|   Platform:  Unspecified
-+-

Comment (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.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3168: Behavior of t.register when r.timestamp was used

2016-09-27 Thread GRASS GIS
#3168: Behavior of t.register when r.timestamp was used
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Temporal|Version:  svn-trunk
Resolution:  |   Keywords:  t.create, t.register, r.timestamp,
   CPU:  |  G_write_raster_timestamp
  Unspecified|   Platform:  Unspecified
-+-

Comment (by huhabla):

 This issue should be fixed in r69586.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3168: Behavior of t.register when r.timestamp was used

2016-09-27 Thread GRASS GIS
#3168: Behavior of t.register when r.timestamp was used
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Temporal|Version:  svn-trunk
Resolution:  |   Keywords:  t.create, t.register, r.timestamp,
   CPU:  |  G_write_raster_timestamp
  Unspecified|   Platform:  Unspecified
-+-

Comment (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.

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #3168: Behavior of t.register when r.timestamp was used

2016-09-27 Thread GRASS GIS
#3168: Behavior of t.register when r.timestamp was used
-+-
 Reporter:  wenzeslaus   |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.2.0
Component:  Temporal |Version:  svn-trunk
 Keywords:  t.create, t.register, r.timestamp,   |CPU:  Unspecified
  G_write_raster_timestamp   |
 Platform:  Unspecified  |
-+-
 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:

 {{{
 #!bash
 g.region s=0 w=0 n=100 e=100 -p res=10
 r.surf.fractal elevation
 r.slope.aspect elevation=elevation dx=dx dy=dy
 r.sim.water el=elevation dx=dx dy=dy depth=depth -t
 t.create output=depth type=strds temporaltype=absolute title="Depths"
 description="Time series of depths from r.sim.water
 t.register input=depth maps=depth.02 start="2015-01-01 00:01:00"
 }}}

 And this is the error:

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

 It comes from:

 {{{
 #!python
 if ttype == "absolute":
 ...
 else:
 start_time = int(start)  # here
 }}}

 The time stamp is read from the spatial database in
 [source:grass/trunk/lib/python/temporal/register.py#L284 register.py]:

 {{{
 #!python
 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).

--
Ticket URL: 
GRASS GIS 

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