[GRASS-dev] Failure to register map in an STRDS (due to a faulty timestamp?)
nik at nikosalexandris.net
Tue Feb 6 07:39:57 PST 2018
* Nikos Alexandris <nik at nikosalexandris.net> [2018-02-06 16:17:19 +0100]:
>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
>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:
>26 Apr 2015 10:03:51
>The timestamp file under `cell_misc/lst `, under the working Mapset, is
>a valid file, i.e.
>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
>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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 228 bytes
Desc: not available
More information about the grass-dev