Hi devs,
I have noticed since last week or so that every time I run a temporal command, it clutters my terminal with “internal” stuff from the module. I have not changed verbosity level. Could it be that some library change produced that or some remaining debugging setting??
Here’s an example of what I see:
.rast.series input=month_max_LST_per_year output=slope_month_max_LST method=slope --o
100%
UPDATE raster_base SET name = ‘slope_month_max_LST’ ,creator = ‘veroandreo’ ,mapset = ‘modis_lst’ ,creation_time = ‘2019-07-30 01:40:56.813449’ ,temporal_type = ‘absolute’ ,id = ‘slope_month_max_LST@modis_lst’ WHERE id = ‘slope_month_max_LST@modis_lst’;
UPDATE raster_absolute_time SET start_time = ‘2015-01-01 00:00:00’ ,id = ‘slope_month_max_LST@modis_lst’ ,end_time = ‘2018-01-01 00:00:00’ WHERE id = ‘slope_month_max_LST@modis_lst’;
UPDATE raster_spatial_extent SET north = 323380.124115 ,bottom = 0.000000 ,west = 122934.464115 ,top = 0.000000 ,proj = ‘XY’ ,east = 934934.464115 ,id = ‘slope_month_max_LST@modis_lst’ ,south = 9780.124115 WHERE id = ‘slope_month_max_LST@modis_lst’;
UPDATE raster_metadata SET max = 1.500000 ,rows = 145 ,min = -2.000000 ,datatype = ‘DCELL’ ,number_of_cells = 8120 ,cols = 56 ,ewres = 5600.000000 ,nsres = 5600.000000 ,id = ‘slope_month_max_LST@modis_lst’ WHERE id = ‘slope_month_max_LST@modis_lst’;
UPDATE raster_stds_register SET id = ‘slope_month_max_LST@modis_lst’ ,registered_stds = NULL WHERE id = ‘slope_month_max_LST@modis_lst’;
Any hints?
Vero
On Mon, Jul 29, 2019 at 7:45 PM Veronica Andreo <veroandreo@gmail.com> wrote:
Hi devs,
I have noticed since last week or so that every time I run a temporal command, it clutters my terminal with “internal” stuff from the module. I have not changed verbosity level. Could it be that some library change produced that or some remaining debugging setting??
Here’s an example of what I see:
.rast.series input=month_max_LST_per_year output=slope_month_max_LST method=slope --o
100%
UPDATE raster_base SET name = ‘slope_month_max_LST’ ,creator = ‘veroandreo’ ,mapset = ‘modis_lst’ ,creation_time = ‘2019-07-30 01:40:56.813449’ ,temporal_type = ‘absolute’ ,id = ‘slope_month_max_LST@modis_lst’ WHERE id = ‘slope_month_max_LST@modis_lst’;
UPDATE raster_absolute_time SET start_time = ‘2015-01-01 00:00:00’ ,id = ‘slope_month_max_LST@modis_lst’ ,end_time = ‘2018-01-01 00:00:00’ WHERE id = ‘slope_month_max_LST@modis_lst’;
UPDATE raster_spatial_extent SET north = 323380.124115 ,bottom = 0.000000 ,west = 122934.464115 ,top = 0.000000 ,proj = ‘XY’ ,east = 934934.464115 ,id = ‘slope_month_max_LST@modis_lst’ ,south = 9780.124115 WHERE id = ‘slope_month_max_LST@modis_lst’;
UPDATE raster_metadata SET max = 1.500000 ,rows = 145 ,min = -2.000000 ,datatype = ‘DCELL’ ,number_of_cells = 8120 ,cols = 56 ,ewres = 5600.000000 ,nsres = 5600.000000 ,id = ‘slope_month_max_LST@modis_lst’ WHERE id = ‘slope_month_max_LST@modis_lst’;
UPDATE raster_stds_register SET id = ‘slope_month_max_LST@modis_lst’ ,registered_stds = NULL WHERE id = ‘slope_month_max_LST@modis_lst’;
Any hints?
Hi Vero,
This looks like some forgotten debug messages/prints, but just to be sure, first check that you did not switch on debug mode (g.gisenv). I don’t see changes in temporal code, but perhaps I’m missing something.
Related to that (from user perspective), have you tried --qq recently? It didn’t seem to work for me.
Vaclav
Vero
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Hi Vashek,
No, I haven’t changed anything with g.gisenv. There were not recent changes in the temporal stuff that I am aware of. Maybe some forgotten debug messages/prints in more low level python library change?? No idea, I just started noticing last week in a two weeks old grass77.
I haven’t tried it. Is it supposed to work with all modules? The same command I showed before with --qq gives error “that’s not a valid flag”
Vero
El mar., 30 jul. 2019 a las 2:05, Vaclav Petras (<wenzeslaus@gmail.com>) escribió:
On Mon, Jul 29, 2019 at 7:45 PM Veronica Andreo <veroandreo@gmail.com> wrote:
Hi devs,
I have noticed since last week or so that every time I run a temporal command, it clutters my terminal with “internal” stuff from the module. I have not changed verbosity level. Could it be that some library change produced that or some remaining debugging setting??
Here’s an example of what I see:
.rast.series input=month_max_LST_per_year output=slope_month_max_LST method=slope --o
100%
UPDATE raster_base SET name = ‘slope_month_max_LST’ ,creator = ‘veroandreo’ ,mapset = ‘modis_lst’ ,creation_time = ‘2019-07-30 01:40:56.813449’ ,temporal_type = ‘absolute’ ,id = ‘slope_month_max_LST@modis_lst’ WHERE id = ‘slope_month_max_LST@modis_lst’;
UPDATE raster_absolute_time SET start_time = ‘2015-01-01 00:00:00’ ,id = ‘slope_month_max_LST@modis_lst’ ,end_time = ‘2018-01-01 00:00:00’ WHERE id = ‘slope_month_max_LST@modis_lst’;
UPDATE raster_spatial_extent SET north = 323380.124115 ,bottom = 0.000000 ,west = 122934.464115 ,top = 0.000000 ,proj = ‘XY’ ,east = 934934.464115 ,id = ‘slope_month_max_LST@modis_lst’ ,south = 9780.124115 WHERE id = ‘slope_month_max_LST@modis_lst’;
UPDATE raster_metadata SET max = 1.500000 ,rows = 145 ,min = -2.000000 ,datatype = ‘DCELL’ ,number_of_cells = 8120 ,cols = 56 ,ewres = 5600.000000 ,nsres = 5600.000000 ,id = ‘slope_month_max_LST@modis_lst’ WHERE id = ‘slope_month_max_LST@modis_lst’;
UPDATE raster_stds_register SET id = ‘slope_month_max_LST@modis_lst’ ,registered_stds = NULL WHERE id = ‘slope_month_max_LST@modis_lst’;
Any hints?
Hi Vero,
This looks like some forgotten debug messages/prints, but just to be sure, first check that you did not switch on debug mode (g.gisenv). I don’t see changes in temporal code, but perhaps I’m missing something.
Related to that (from user perspective), have you tried --qq recently? It didn’t seem to work for me.
Vaclav
Vero
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Sorry, yes, I must have left it there. Should be fixed now.
Anna
On Mon, Jul 29, 2019 at 9:31 PM Veronica Andreo <veroandreo@gmail.com> wrote:
Hi Vashek,
No, I haven’t changed anything with g.gisenv. There were not recent changes in the temporal stuff that I am aware of. Maybe some forgotten debug messages/prints in more low level python library change?? No idea, I just started noticing last week in a two weeks old grass77.
I haven’t tried it. Is it supposed to work with all modules? The same command I showed before with --qq gives error “that’s not a valid flag”
Vero
El mar., 30 jul. 2019 a las 2:05, Vaclav Petras (<wenzeslaus@gmail.com>) escribió:
On Mon, Jul 29, 2019 at 7:45 PM Veronica Andreo <veroandreo@gmail.com> wrote:
Hi devs,
I have noticed since last week or so that every time I run a temporal command, it clutters my terminal with “internal” stuff from the module. I have not changed verbosity level. Could it be that some library change produced that or some remaining debugging setting??
Here’s an example of what I see:
.rast.series input=month_max_LST_per_year output=slope_month_max_LST method=slope --o
100%
UPDATE raster_base SET name = ‘slope_month_max_LST’ ,creator = ‘veroandreo’ ,mapset = ‘modis_lst’ ,creation_time = ‘2019-07-30 01:40:56.813449’ ,temporal_type = ‘absolute’ ,id = ‘slope_month_max_LST@modis_lst’ WHERE id = ‘slope_month_max_LST@modis_lst’;
UPDATE raster_absolute_time SET start_time = ‘2015-01-01 00:00:00’ ,id = ‘slope_month_max_LST@modis_lst’ ,end_time = ‘2018-01-01 00:00:00’ WHERE id = ‘slope_month_max_LST@modis_lst’;
UPDATE raster_spatial_extent SET north = 323380.124115 ,bottom = 0.000000 ,west = 122934.464115 ,top = 0.000000 ,proj = ‘XY’ ,east = 934934.464115 ,id = ‘slope_month_max_LST@modis_lst’ ,south = 9780.124115 WHERE id = ‘slope_month_max_LST@modis_lst’;
UPDATE raster_metadata SET max = 1.500000 ,rows = 145 ,min = -2.000000 ,datatype = ‘DCELL’ ,number_of_cells = 8120 ,cols = 56 ,ewres = 5600.000000 ,nsres = 5600.000000 ,id = ‘slope_month_max_LST@modis_lst’ WHERE id = ‘slope_month_max_LST@modis_lst’;
UPDATE raster_stds_register SET id = ‘slope_month_max_LST@modis_lst’ ,registered_stds = NULL WHERE id = ‘slope_month_max_LST@modis_lst’;
Any hints?
Hi Vero,
This looks like some forgotten debug messages/prints, but just to be sure, first check that you did not switch on debug mode (g.gisenv). I don’t see changes in temporal code, but perhaps I’m missing something.
Related to that (from user perspective), have you tried --qq recently? It didn’t seem to work for me.
Vaclav
Vero
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Great! Thanks, Anna!
El mar., 30 jul. 2019 a las 5:06, Anna Petrášová (<kratochanna@gmail.com>) escribió:
Sorry, yes, I must have left it there. Should be fixed now.
Anna
On Mon, Jul 29, 2019 at 9:31 PM Veronica Andreo <veroandreo@gmail.com> wrote:
Hi Vashek,
No, I haven’t changed anything with g.gisenv. There were not recent changes in the temporal stuff that I am aware of. Maybe some forgotten debug messages/prints in more low level python library change?? No idea, I just started noticing last week in a two weeks old grass77.
I haven’t tried it. Is it supposed to work with all modules? The same command I showed before with --qq gives error “that’s not a valid flag”
Vero
El mar., 30 jul. 2019 a las 2:05, Vaclav Petras (<wenzeslaus@gmail.com>) escribió:
On Mon, Jul 29, 2019 at 7:45 PM Veronica Andreo <veroandreo@gmail.com> wrote:
Hi devs,
I have noticed since last week or so that every time I run a temporal command, it clutters my terminal with “internal” stuff from the module. I have not changed verbosity level. Could it be that some library change produced that or some remaining debugging setting??
Here’s an example of what I see:
.rast.series input=month_max_LST_per_year output=slope_month_max_LST method=slope --o
100%
UPDATE raster_base SET name = ‘slope_month_max_LST’ ,creator = ‘veroandreo’ ,mapset = ‘modis_lst’ ,creation_time = ‘2019-07-30 01:40:56.813449’ ,temporal_type = ‘absolute’ ,id = ‘slope_month_max_LST@modis_lst’ WHERE id = ‘slope_month_max_LST@modis_lst’;
UPDATE raster_absolute_time SET start_time = ‘2015-01-01 00:00:00’ ,id = ‘slope_month_max_LST@modis_lst’ ,end_time = ‘2018-01-01 00:00:00’ WHERE id = ‘slope_month_max_LST@modis_lst’;
UPDATE raster_spatial_extent SET north = 323380.124115 ,bottom = 0.000000 ,west = 122934.464115 ,top = 0.000000 ,proj = ‘XY’ ,east = 934934.464115 ,id = ‘slope_month_max_LST@modis_lst’ ,south = 9780.124115 WHERE id = ‘slope_month_max_LST@modis_lst’;
UPDATE raster_metadata SET max = 1.500000 ,rows = 145 ,min = -2.000000 ,datatype = ‘DCELL’ ,number_of_cells = 8120 ,cols = 56 ,ewres = 5600.000000 ,nsres = 5600.000000 ,id = ‘slope_month_max_LST@modis_lst’ WHERE id = ‘slope_month_max_LST@modis_lst’;
UPDATE raster_stds_register SET id = ‘slope_month_max_LST@modis_lst’ ,registered_stds = NULL WHERE id = ‘slope_month_max_LST@modis_lst’;
Any hints?
Hi Vero,
This looks like some forgotten debug messages/prints, but just to be sure, first check that you did not switch on debug mode (g.gisenv). I don’t see changes in temporal code, but perhaps I’m missing something.
Related to that (from user perspective), have you tried --qq recently? It didn’t seem to work for me.
Vaclav
Vero
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev