[GRASS-dev] Failure to register map in an STRDS (due to a faulty timestamp?)

Dear list,

among a set of timestamped raster maps, one fails to register in an
STRDS. I.e., when trying to register this single raster map

t.register --o input=lst map=lst_LC81930282015116LGN00

returns

ERROR: 'NoneType' object has no attribute 'tzinfo'.

This leads to something like a Python function expects a specific type of
data while it receives, as an input, another one.

The map is timestamped:

r.timestamp lst_LC81930282015116LGN00
26 Apr 2015 10:03:51

The timestamp file under `cell_misc/lst `, under the working Mapset, is
a valid file, i.e.

file LC81930282015116LGN00/cell_misc/lst/timestamp

returns

LC81930282015116LGN00/cell_misc/lst/timestamp: ASCII text

The computational region is all set, its univariate figures are computed
and printed on the command line, and, finally, the map draws normally on a
wx-Monitor.

This is one error that frequently comes up during analyses of tens
of thousands of Landsat 8 images.

I've set a short course on tracking what is where (using DEBUG=?
levels), but I think this is not the right choice.

Anyone an idea? Do I need to deeply debug this, using `pdb` for example?
Attached a outputs of g.region, g.proj, r.info, r.univar for and the
timestamp (file) of the map in question.

Thank you, Nikos

--
Nikos Alexandris | Remote Sensing & Geomatics
GPG Key Fingerprint 6F9D4506F3CA28380974D31A9053534B693C4FB3

(attachments)

g_proj (117 Bytes)
g_region (112 Bytes)
r_info_lst_LC81930282015116LGN00 (5.01 KB)
r_univar_lst_LC81930282015116LGN00 (346 Bytes)
timestamp (21 Bytes)

* Nikos Alexandris <nik@nikosalexandris.net> [2018-02-06 16:17:19 +0100]:

Dear list,

among a set of timestamped raster maps, one fails to register in an
STRDS. I.e., when trying to register this single raster map

t.register --o input=lst map=lst_LC81930282015116LGN00

returns

ERROR: 'NoneType' object has no attribute 'tzinfo'.

This leads to something like a Python function expects a specific type of
data while it receives, as an input, another one.

The map is timestamped:

r.timestamp lst_LC81930282015116LGN00
26 Apr 2015 10:03:51

The timestamp file under `cell_misc/lst `, under the working Mapset, is
a valid file, i.e.

file LC81930282015116LGN00/cell_misc/lst/timestamp

returns

LC81930282015116LGN00/cell_misc/lst/timestamp: ASCII text

The computational region is all set, its univariate figures are computed
and printed on the command line, and, finally, the map draws normally on a
wx-Monitor.

This is one error that frequently comes up during analyses of tens
of thousands of Landsat 8 images.

I've set a short course on tracking what is where (using DEBUG=?
levels), but I think this is not the right choice.

Anyone an idea? Do I need to deeply debug this, using `pdb` for example?
Attached a outputs of g.region, g.proj, r.info, r.univar for and the
timestamp (file) of the map in question.

Just another, important, note. All single scenes/ as the one in question
here/ are processed separately, each in a dedicated docker container
based on debian(:latest).

I've seen some errors related to locale settings, when there was no
default UTF-8 preset. Could this be something related?

Nikos