[GRASS-user] question on i.nightlights.intercalibration code

Gabriel_Cotlier · June 21, 2018, 2:03pm

I have tried to run i.i.nightlights.intercalibration on the command line and got the following error:

What could be happening?
Thanks a lot

veroandreo · June 21, 2018, 3:12pm

Hi Gabriel,

Are you using Windows? I think you cannot use g.list inside a command as we do in Linux. Solution would be to first get the list of comma separated map names and then paste it in the i.nightlights command.

HTH,
Vero

El jue., 21 jun. 2018 11:05, Gabriel Cotlier <gabiklm01@gmail.com> escribió:

I have tried to run i.i.nightlights.intercalibration on the command line and got the following error:

What could be happening?
Thanks a lot

grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Gabriel_Cotlier · June 21, 2018, 4:33pm

Hello Vero,
Thanks a lot for your response.
I have tried that with no results, with the error in the image bellow:

(attachments)

···

On Thu, Jun 21, 2018 at 12:12 PM, Veronica Andreo <veroandreo@gmail.com> wrote:

Hi Gabriel,

Are you using Windows? I think you cannot use g.list inside a command as we do in Linux. Solution would be to first get the list of comma separated map names and then paste it in the i.nightlights command.

HTH,
Vero

El jue., 21 jun. 2018 11:05, Gabriel Cotlier <gabiklm01@gmail.com> escribió:

I have tried to run i.i.nightlights.intercalibration on the command line and got the following error:

What could be happening?
Thanks a lot

grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

veroandreo · June 21, 2018, 4:50pm

It is a bit difficult to read, can you post the command you used? It seems you typed image twice, suffic instead of suffix and you are using $() to pass the list of map names which is not necesary, AFAIU. Try the following:

i.nightlights.intercalibration image=img1,img2,img3 suffix=c model=liu2012

if that does not work, then, Nikos will know

best,
Vero

(attachments)

···

On Thu, Jun 21, 2018 at 12:12 PM, Veronica Andreo <veroandreo@gmail.com> wrote:

Hi Gabriel,

Are you using Windows? I think you cannot use g.list inside a command as we do in Linux. Solution would be to first get the list of comma separated map names and then paste it in the i.nightlights command.

HTH,
Vero

El jue., 21 jun. 2018 11:05, Gabriel Cotlier <gabiklm01@gmail.com> escribió:

I have tried to run i.i.nightlights.intercalibration on the command line and got the following error:

What could be happening?
Thanks a lot

grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Gabriel_Cotlier · June 21, 2018, 9:24pm

Hello Veronica,

Thanks a lot it worked!!

following the line you wrote:

i.nightlights.intercalibration image=img1,img2,img3 suffix=c elvidge2014

and got the error:

(Thu Jun 21 17:36:56 2018)
i.nightlights.intercalibration image=F101992,F101993,F101994,F121994,F121995,F121996,F121997,F121998,F121999,F141997,F141998,F141999,F142000,F142001,F142002,F142003,F152000,F152001,F152002,F152003,F152004,F152005,F152006,F152007,F162004,F162005,F162006,F162007,F162008,F162009,F182010,F182011,F182012,F182013 suffix=c model=elvidge2014

i Inter-satellite calibration of DMSP-OLS Nighttime Stable Lights
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (-2.057, 1.5903, -0.009) | Associated R^2: 0.9075
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
ERROR:

Timestamp is missing! Please add one to the input map if further times series analysis is important. If you don’t need it, you may use the -t flag.
(Thu Jun 21 17:37:47 2018) Command finished (51 sec)
(Thu Jun 21 17:39:49 2018)

So aggregating the flag -t, because an error that appeared, as follows:

i.nightlights.intercalibration image=F101992,F101993,F101994,F121994,F121995,F121996,F121997,F121998,F121999,F141997,F141998,F141999,F142000,F142001,F142002,F142003,F152000,F152001,F152002,F152003,F152004,F152005,F152006,F152007,F162004,F162005,F162006,F162007,F162008,F162009,F182010,F182011,F182012,F182013 suffix=c model=elvidge2014 -t

And it finally worked!!

But as you can see bellow all inter-calibrated layers were created but F182013 was not generate (F182013.c)

if you see at the end of this email it shows an error for the last layer F182013 of the data set…

Why could this be happening?
Thanks a lot again.

Gabriel

i Inter-satellite calibration of DMSP-OLS Nighttime Stable Lights
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (-2.057, 1.5903, -0.009) | Associated R^2: 0.9075
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attem,pted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (-1.0582, 1.5983, -0.0093) | Associated R^2: 0.936
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (-0.3458, 1.4864, -0.0079) | Associated R^2: 0.9243
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (-0.689, 1.177, -0.0025) | Associated R^2: 0.9071
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (-0.0515, 1.2293, -0.0038) | Associated R^2: 0.9178
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (-0.0959, 1.2727, -0.004) | Associated R^2: 0.9319
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (-0.3321, 1.1782, -0.0026) | Associated R^2: 0.9245
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (-0.0608, 1.0648, -0.0013) | Associated R^2: 0.9536
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (0.0, 1.0, 0.0) | Associated R^2: 1.0
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (-1.1323, 1.7696, -0.0122) | Associated R^2: 0.9101
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (-0.1917, 1.6321, -0.0101) | Associated R^2: 0.9723
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (-0.1557, 1.5055, -0.0078) | Associated R^2: 0.9717
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (1.0988, 1.3155, -0.0053) | Associated R^2: 0.9278
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (0.1943, 1.3219, -0.0051) | Associated R^2: 0.9448
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (1.0517, 1.1905, -0.0036) | Associated R^2: 0.9203
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (0.739, 1.2416, -0.004) | Associated R^2: 0.9432
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (0.1254, 1.0452, -0.001) | Associated R^2: 0.932
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (-0.7024, 1.1081, -0.0012) | Associated R^2: 0.9593
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (0.0491, 0.9568, 0.001) | Associated R^2: 0.9658
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (0.2217, 1.5122, -0.008) | Associated R^2: 0.9314
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (0.5751, 1.3335, -0.0051) | Associated R^2: 0.9479
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (0.6367, 1.2838, -0.0041) | Associated R^2: 0.9335
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (0.8261, 1.279, -0.0041) | Associated R^2: 0.9387
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (1.3606, 1.2974, -0.0045) | Associated R^2: 0.9013
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (0.2853, 1.1955, -0.0034) | Associated R^2: 0.9039
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (-0.0001, 1.4159, -0.0063) | Associated R^2: 0.939
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (0.1065, 1.1371, -0.0016) | Associated R^2: 0.9199
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (0.6394, 0.9114, 0.0014) | Associated R^2: 0.9511
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (0.5564, 0.9931, 0.0) | Associated R^2: 0.945
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (0.9492, 1.0683, -0.0016) | Associated R^2: 0.8918
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (2.343, 0.5102, 0.0065) | Associated R^2: 0.8462
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (1.8956, 0.7345, 0.003) | Associated R^2: 0.9095
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (1.875, 0.6203, 0.0052) | Associated R^2: 0.9392
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

Calibrating average visible Digital Number values
WARNING: No data base element files found
Traceback (most recent call last):
File “C:\Users\Gabriel\AppData\Roaming\GRASS7\addons/scrip
ts/i.nightlights.intercalibration.py”, line 525, in
sys.exit(main())
File “C:\Users\Gabriel\AppData\Roaming\GRASS7\addons/scrip
ts/i.nightlights.intercalibration.py”, line 340, in main
model_parameters = retrieve_model_parameters(Model,
*args)
File “C:\Users\Gabriel\AppData\Roaming\GRASS7\addons/scrip
ts/i.nightlights.intercalibration.py”, line 242, in
retrieve_model_parameters
model = model_class(*args, **kwargs)
File “C:\Users\Gabriel\AppData\Roaming\GRASS7\addons\etc\i
.nightlights.intercalibration\intercalibration_models.py”,
line 155, in init
CalibrationModel.init(self, author, satellite, year)
File “C:\Users\Gabriel\AppData\Roaming\GRASS7\addons\etc\i
.nightlights.intercalibration\intercalibration_models.py”,
line 43, in init
year=self.year)
File “C:\Users\Gabriel\AppData\Roaming\GRASS7\addons\etc\i
.nightlights.intercalibration\intercalibration_models.py”,
line 67, in verify_year
raise ValueError('The selected model does not know about
’
ValueError: The selected model does not know about this
combination of Satellite + Year!
(Thu Jun 21 18:08:00 2018) Command finished (28 min 10 sec)

(attachments)

···

On Thu, Jun 21, 2018 at 1:50 PM, Veronica Andreo <veroandreo@gmail.com> wrote:

It is a bit difficult to read, can you post the command you used? It seems you typed image twice, suffic instead of suffix and you are using $() to pass the list of map names which is not necesary, AFAIU. Try the following:
i.nightlights.intercalibration image=img1,img2,img3 suffix=c model=liu2012
if that does not work, then, Nikos will know

best,
Vero

El jue., 21 jun. 2018 a las 18:34, Gabriel Cotlier (<gabiklm01@gmail.com>) escribió:

Hello Vero,
Thanks a lot for your response.
I have tried that with no results, with the error in the image bellow:

On Thu, Jun 21, 2018 at 12:12 PM, Veronica Andreo <veroandreo@gmail.com> wrote:

Hi Gabriel,

Are you using Windows? I think you cannot use g.list inside a command as we do in Linux. Solution would be to first get the list of comma separated map names and then paste it in the i.nightlights command.

HTH,
Vero

El jue., 21 jun. 2018 11:05, Gabriel Cotlier <gabiklm01@gmail.com> escribió:

I have tried to run i.i.nightlights.intercalibration on the command line and got the following error:

What could be happening?
Thanks a lot

grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

NikosAlexandris · June 22, 2018, 3:50am

* Gabriel Cotlier <gabiklm01@gmail.com> [2018-06-21 18:24:38 -0300]:

Hello Veronica,

Thanks a lot it worked!!

Dear Gabriel,

Thanks for posting details and great it works. Don't worry about the
last image, there are no coefficients for F18 and 2013. We are forced
to skip this image in any analysis.

Details

Veronica is right, and I am ignorant for so many things when it comes to Windows.

In Linux, one may use the syntax `some_command` or
$(some_command). It's a smart way to feed-in longer list of items, such
as map names in GRASS GIS. Note, the former is old-style, so best to use the $()
notation (if of interest, see
https://unix.stackexchange.com/a/5782/13011).

You might want to re-check the extent you have set, so as to
get rid of the "360 degree EW extent is exceeded by 0.999827 cells"
messages (?). Depending on how you have set your region, maybe the `-a`
option for `g.region` would help (?).

The last failing image is not a computational error. The error
message
--%<---

ValueError: The selected model does not know about this
combination of Satellite + Year!

--->%--
means that there are no coefficients for satellite "F18" and for the
year 2013. You may read this in
https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_coefficients.py#L99
and the referenced papers, of course.

For various reasons, I did not improve the script in
handling this situations. I just let it emit an error message. I hardly
remember having modified this message to say something like "There are
given coefficients for satellite F?? and Year ???". But I can't trace
anything in my local repository.

(
Note, there are many newer algorithms. It would be obviously great to
integrate some of them in the existing module. If a new model bases upon
a similar math formula, then it's only necessary to add:

1. a new set of coefficients in https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_coefficients.py#L38

2. a new equation in https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_equations.py#L15

3. a new subclass, for the new model, in https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_models.py

Maybe more work if there is a substantially different math logic.
)

Thanks, Nikos

Gabriel_Cotlier · June 22, 2018, 1:32pm

Dear Nikos and Veronica,

Thanks a lot for your emails, I’m happy it worked!

I will try to avoid of the extent message “360 degree EW extent is exceeded by 0.999827 cells” using: g.region -a, should I enter this command before importing the images - raster data layers ?

Thanks a lot again for your guidance.

Gabriel

···

On Fri, Jun 22, 2018 at 12:50 AM, Nikos Alexandris <nik@nikosalexandris.net> wrote:

Gabriel Cotlier <gabiklm01@gmail.com> [2018-06-21 18:24:38 -0300]:

Hello Veronica,

Thanks a lot it worked!!

Dear Gabriel,

Thanks for posting details and great it works. Don’t worry about the
last image, there are no coefficients for F18 and 2013. We are forced
to skip this image in any analysis.

Details

Veronica is right, and I am ignorant for so many things when it comes to Windows.

In Linux, one may use the syntax some_command or
$(some_command). It’s a smart way to feed-in longer list of items, such
as map names in GRASS GIS. Note, the former is old-style, so best to use the $()
notation (if of interest, see
https://unix.stackexchange.com/a/5782/13011).

You might want to re-check the extent you have set, so as to
get rid of the “360 degree EW extent is exceeded by 0.999827 cells”
messages (?). Depending on how you have set your region, maybe the -a
option for g.region would help (?).

The last failing image is not a computational error. The error
message
–%<—

ValueError: The selected model does not know about this
combination of Satellite + Year!

—>%–
means that there are no coefficients for satellite “F18” and for the
year 2013. You may read this in
https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_coefficients.py#L99
and the referenced papers, of course.

For various reasons, I did not improve the script in
handling this situations. I just let it emit an error message. I hardly
remember having modified this message to say something like “There are
given coefficients for satellite F?? and Year ???”. But I can’t trace
anything in my local repository.

(
Note, there are many newer algorithms. It would be obviously great to
integrate some of them in the existing module. If a new model bases upon
a similar math formula, then it’s only necessary to add:

a new set of coefficients in https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_coefficients.py#L38

a new equation in https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_equations.py#L15

a new subclass, for the new model, in https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_models.py

Maybe more work if there is a substantially different math logic.
)

Thanks, Nikos

veroandreo · June 22, 2018, 8:34pm

Hi Gabriel,

What you could do is import with r.in.gdal -a that adjusts resolution for lat long maps [0] and then (before the intercalibration step), set the region to one of the imported maps with g.region raster=yourmap

HTH,
Vero

[0] https://grass.osgeo.org/grass74/manuals/r.in.gdal.html

···

On Fri, Jun 22, 2018 at 12:50 AM, Nikos Alexandris <nik@nikosalexandris.net> wrote:

Gabriel Cotlier <gabiklm01@gmail.com> [2018-06-21 18:24:38 -0300]:

Hello Veronica,

Thanks a lot it worked!!

Dear Gabriel,

Thanks for posting details and great it works. Don’t worry about the
last image, there are no coefficients for F18 and 2013. We are forced
to skip this image in any analysis.

Details

Veronica is right, and I am ignorant for so many things when it comes to Windows.

In Linux, one may use the syntax some_command or
$(some_command). It’s a smart way to feed-in longer list of items, such
as map names in GRASS GIS. Note, the former is old-style, so best to use the $()
notation (if of interest, see
https://unix.stackexchange.com/a/5782/13011).

You might want to re-check the extent you have set, so as to
get rid of the “360 degree EW extent is exceeded by 0.999827 cells”
messages (?). Depending on how you have set your region, maybe the -a
option for g.region would help (?).

The last failing image is not a computational error. The error
message
–%<—

ValueError: The selected model does not know about this
combination of Satellite + Year!

—>%–
means that there are no coefficients for satellite “F18” and for the
year 2013. You may read this in
https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_coefficients.py#L99
and the referenced papers, of course.

For various reasons, I did not improve the script in
handling this situations. I just let it emit an error message. I hardly
remember having modified this message to say something like “There are
given coefficients for satellite F?? and Year ???”. But I can’t trace
anything in my local repository.

(
Note, there are many newer algorithms. It would be obviously great to
integrate some of them in the existing module. If a new model bases upon
a similar math formula, then it’s only necessary to add:

a new set of coefficients in https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_coefficients.py#L38

a new equation in https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_equations.py#L15

a new subclass, for the new model, in https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_models.py

Maybe more work if there is a substantially different math logic.
)

Thanks, Nikos

hellik · June 23, 2018, 7:14am

Are you using Windows? I think you cannot use g.list inside a command as we

do in Linux

not as elegant in linux, but you can do something similar in windows too

e.g. in the winGRASS command line:

:\>FOR /F %c in ('g.list "type=raster" "pattern=*2" "mapset=user1"
"separator=comma"') DO SET RASTER2REMOVE=%c

C:\>SET RASTER2REMOVE=b172,d172,it172,r172

C:\>echo %RASTER2REMOVE%
b172,d172,it172,r172

C:\>g.remove type=raster name=%RASTER2REMOVE%
The following data base element files would be deleted:
raster/b172@user1
raster/d172@user1
raster/it172@user1
raster/r172@user1
WARNING: Nothing removed. You must use the force flag (-f) to actually
remove them. Exiting.

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html

Markus_Metz · June 23, 2018, 7:35am

On Fri, Jun 22, 2018 at 10:34 PM, Veronica Andreo <veroandreo@gmail.com> wrote:

Hi Gabriel,

What you could do is import with r.in.gdal -a that adjusts resolution for lat long maps [0]

that will help to fix the resolution from 0.008333333300000 to 0.008333333333333, i.e. exactly 30 arc-seconds. The software used to create the raster data has stored the resolution with limited precision.

and then (before the intercalibration step), set the region to one of the imported maps with g.region raster=yourmap

you will then get a message like
360 degree EW extent is exceeded by 1 cells

which is correct because the first and last column are duplicates. The cell centers cover -180, 180, and the EW extents regarding cell borders are E: 180:00:15E, W: 180:00:15W, grown by half a cell, i.e. 15 arc-seconds.

Markus M

HTH,
Vero

[0] https://grass.osgeo.org/grass74/manuals/r.in.gdal.html

El vie., 22 jun. 2018 10:32, Gabriel Cotlier <gabiklm01@gmail.com> escribió:

Dear Nikos and Veronica,

Thanks a lot for your emails, I’m happy it worked!

I will try to avoid of the extent message “360 degree EW extent is exceeded by 0.999827 cells” using: g.region -a, should I enter this command before importing the images - raster data layers ?

Thanks a lot again for your guidance.

Gabriel

On Fri, Jun 22, 2018 at 12:50 AM, Nikos Alexandris <nik@nikosalexandris.net> wrote:

Gabriel Cotlier <gabiklm01@gmail.com> [2018-06-21 18:24:38 -0300]:

Hello Veronica,

Thanks a lot it worked!!

Dear Gabriel,

Thanks for posting details and great it works. Don’t worry about the
last image, there are no coefficients for F18 and 2013. We are forced
to skip this image in any analysis.

Details

Veronica is right, and I am ignorant for so many things when it comes to Windows.

In Linux, one may use the syntax some_command or
$(some_command). It’s a smart way to feed-in longer list of items, such
as map names in GRASS GIS. Note, the former is old-style, so best to use the $()
notation (if of interest, see
https://unix.stackexchange.com/a/5782/13011).

You might want to re-check the extent you have set, so as to
get rid of the “360 degree EW extent is exceeded by 0.999827 cells”
messages (?). Depending on how you have set your region, maybe the -a
option for g.region would help (?).

The last failing image is not a computational error. The error
message
–%<—

ValueError: The selected model does not know about this
combination of Satellite + Year!

—>%–
means that there are no coefficients for satellite “F18” and for the
year 2013. You may read this in
https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_coefficients.py#L99
and the referenced papers, of course.

For various reasons, I did not improve the script in
handling this situations. I just let it emit an error message. I hardly
remember having modified this message to say something like “There are
given coefficients for satellite F?? and Year ???”. But I can’t trace
anything in my local repository.

(
Note, there are many newer algorithms. It would be obviously great to
integrate some of them in the existing module. If a new model bases upon
a similar math formula, then it’s only necessary to add:

a new set of coefficients in https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_coefficients.py#L38

a new equation in https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_equations.py#L15

a new subclass, for the new model, in https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_models.py

Maybe more work if there is a substantially different math logic.
)

Thanks, Nikos

grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

veroandreo · June 23, 2018, 9:10am

Hi,

El sáb., 23 jun. 2018 4:35, Markus Metz <markus.metz.giswork@gmail.com> escribió:

On Fri, Jun 22, 2018 at 10:34 PM, Veronica Andreo <veroandreo@gmail.com> wrote:

Hi Gabriel,

What you could do is import with r.in.gdal -a that adjusts resolution for lat long maps [0]

that will help to fix the resolution from 0.008333333300000 to 0.008333333333333, i.e. exactly 30 arc-seconds. The software used to create the raster data has stored the resolution with limited precision.

Right, I overlooked this

and then (before the intercalibration step), set the region to one of the imported maps with g.region raster=yourmap

you will then get a message like
360 degree EW extent is exceeded by 1 cells

which is correct because the first and last column are duplicates. The cell centers cover -180, 180, and the EW extents regarding cell borders are E: 180:00:15E, W: 180:00:15W, grown by half a cell, i.e. 15 arc-seconds.

So, solution is to just use the data with the extra 15 arc-seconds in each side?

Of I want data to fit 180/-180, would r.region mymap e=180 w=180 help or will it change the data?

Vero

Markus_Metz · June 23, 2018, 9:31am

On Sat, Jun 23, 2018 at 11:10 AM, Veronica Andreo <veroandreo@gmail.com> wrote:

Hi,

El sáb., 23 jun. 2018 4:35, Markus Metz <markus.metz.giswork@gmail.com> escribió:

On Fri, Jun 22, 2018 at 10:34 PM, Veronica Andreo <veroandreo@gmail.com> wrote:

Hi Gabriel,

What you could do is import with r.in.gdal -a that adjusts resolution for lat long maps [0]

that will help to fix the resolution from 0.008333333300000 to 0.008333333333333, i.e. exactly 30 arc-seconds. The software used to create the raster data has stored the resolution with limited precision.

Right, I overlooked this

and then (before the intercalibration step), set the region to one of the imported maps with g.region raster=yourmap

you will then get a message like
360 degree EW extent is exceeded by 1 cells

which is correct because the first and last column are duplicates. The cell centers cover -180, 180, and the EW extents regarding cell borders are E: 180:00:15E, W: 180:00:15W, grown by half a cell, i.e. 15 arc-seconds.

So, solution is to just use the data with the extra 15 arc-seconds in each side?

yes, or chop off the first or last column: set the region to the raster, then modify the current region with g.region w=179:59:45W -p

Of I want data to fit 180/-180, would r.region mymap e=180 w=180 help or will it change the data?

this would modify the data because

the raster will be shifted by half a cell to the east
the cell size (ew resolution) will be changed

Markus M

Vero

Gabriel_Cotlier · June 24, 2018, 8:09pm

Dear Vero and Markus,

Thanks a lot for the guidance and help.

If I understood correctly:

I first have to import one layer when I select a location setting the coordinate system of that layer to the mapset of GRASS (at the start).

Then I have to import all other layers to mapset using command “r.in.gdal -a”

r.in.gdal -a input=C:\Users\Gabriel\Documents\layers\F121995.tif output=F121995

Then I have to running “g.region” to set up the same extent to all layers as follows:

g.region raster=F121995

and I got the layer processed and finished but the error did not went way…

i Inter-satellite calibration of DMSP-OLS Nighttime Stable Lights
WARNING: Operating on current region

Calibrating average visible Digital Number values
Regression coefficients: (-0.0515, 1.2293, -0.0038) | Associated R^2: 0.9178

360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 1 cells

WARNING: As requested, timestamp transferring not attempted.
WARNING: No data base element files found

(Sun Jun 24 17:05:31 2018) Command finished (1 min 2 sec)

What could be doing wrong?
In addition I’m doing it for one layer here, is there a way to do it for many layers at onces with command line or GUI dialog box?

Thanks a lot again.

Gabriel

···

On Sat, Jun 23, 2018 at 6:31 AM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Sat, Jun 23, 2018 at 11:10 AM, Veronica Andreo <veroandreo@gmail.com> wrote:

Hi,

El sáb., 23 jun. 2018 4:35, Markus Metz <markus.metz.giswork@gmail.com> escribió:

On Fri, Jun 22, 2018 at 10:34 PM, Veronica Andreo <veroandreo@gmail.com> wrote:

Hi Gabriel,

What you could do is import with r.in.gdal -a that adjusts resolution for lat long maps [0]

that will help to fix the resolution from 0.008333333300000 to 0.008333333333333, i.e. exactly 30 arc-seconds. The software used to create the raster data has stored the resolution with limited precision.

Right, I overlooked this

and then (before the intercalibration step), set the region to one of the imported maps with g.region raster=yourmap

you will then get a message like
360 degree EW extent is exceeded by 1 cells

which is correct because the first and last column are duplicates. The cell centers cover -180, 180, and the EW extents regarding cell borders are E: 180:00:15E, W: 180:00:15W, grown by half a cell, i.e. 15 arc-seconds.

So, solution is to just use the data with the extra 15 arc-seconds in each side?

yes, or chop off the first or last column: set the region to the raster, then modify the current region with g.region w=179:59:45W -p

Of I want data to fit 180/-180, would r.region mymap e=180 w=180 help or will it change the data?

this would modify the data because

the raster will be shifted by half a cell to the east

the cell size (ew resolution) will be changed

Markus M

Vero

Gabriel_Cotlier · June 25, 2018, 3:40am

Hello,

I think I have found a similar situation solved for Linux version at:

https://trac.osgeo.org/grass/ticket/2757#comment:21

In my case I’m using GRASS 7.4.0 in Windows 10, and when I called for metadata info of the layer I got the message bellow with the problem highlighted in yellow bellow.

What could be happening? It would be very helpful to understand what is happening and how to solve importing many raster layers without this extent problems.
I appreciate your help.

Thanks a lot in advance.
Regards,
Gabriel

(Mon Jun 25 00:30:03 2018)

r.info map=F101992@PERMANENT

···

On Sun, Jun 24, 2018 at 5:09 PM, Gabriel Cotlier <gabiklm01@gmail.com> wrote:

Dear Vero and Markus,

Thanks a lot for the guidance and help.

If I understood correctly:

I first have to import one layer when I select a location setting the coordinate system of that layer to the mapset of GRASS (at the start).

Then I have to import all other layers to mapset using command “r.in.gdal -a”

r.in.gdal -a input=C:\Users\Gabriel\Documents\layers\F121995.tif output=F121995

Then I have to running “g.region” to set up the same extent to all layers as follows:

g.region raster=F121995

and I got the layer processed and finished but the error did not went way…

|i Inter-satellite calibration of DMSP-OLS Nighttime Stable Lights
WARNING: Operating on current region

|> Calibrating average visible Digital Number values

Regression coefficients: (-0.0515, 1.2293, -0.0038) | Associated R^2: 0.9178

360 degree EW extent is exceeded by 0.999827 cells

360 degree EW extent is exceeded by 1 cells

WARNING: As requested, timestamp transferring not attempted.

WARNING: No data base element files found

(Sun Jun 24 17:05:31 2018) Command finished (1 min 2 sec)

What could be doing wrong?
In addition I’m doing it for one layer here, is there a way to do it for many layers at onces with command line or GUI dialog box?

Thanks a lot again.

Gabriel

On Sat, Jun 23, 2018 at 6:31 AM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Sat, Jun 23, 2018 at 11:10 AM, Veronica Andreo <veroandreo@gmail.com> wrote:

Hi,

El sáb., 23 jun. 2018 4:35, Markus Metz <markus.metz.giswork@gmail.com> escribió:

On Fri, Jun 22, 2018 at 10:34 PM, Veronica Andreo <veroandreo@gmail.com> wrote:

Hi Gabriel,

What you could do is import with r.in.gdal -a that adjusts resolution for lat long maps [0]

that will help to fix the resolution from 0.008333333300000 to 0.008333333333333, i.e. exactly 30 arc-seconds. The software used to create the raster data has stored the resolution with limited precision.

Right, I overlooked this

and then (before the intercalibration step), set the region to one of the imported maps with g.region raster=yourmap

you will then get a message like
360 degree EW extent is exceeded by 1 cells

which is correct because the first and last column are duplicates. The cell centers cover -180, 180, and the EW extents regarding cell borders are E: 180:00:15E, W: 180:00:15W, grown by half a cell, i.e. 15 arc-seconds.

So, solution is to just use the data with the extra 15 arc-seconds in each side?

yes, or chop off the first or last column: set the region to the raster, then modify the current region with g.region w=179:59:45W -p

Of I want data to fit 180/-180, would r.region mymap e=180 w=180 help or will it change the data?

this would modify the data because

the raster will be shifted by half a cell to the east

the cell size (ew resolution) will be changed

Markus M

Vero

Markus_Metz · June 25, 2018, 6:29am

On Mon, Jun 25, 2018 at 5:40 AM, Gabriel Cotlier <gabiklm01@gmail.com> wrote:

Hello,

I think I have found a similar situation solved for Linux version at:

https://trac.osgeo.org/grass/ticket/2757#comment:21

In my case I’m using GRASS 7.4.0 in Windows 10, and when I called for metadata info of the layer I got the message bellow with the problem highlighted in yellow bellow.

What could be happening? It would be very helpful to understand what is happening and how to solve importing many raster layers without this extent problems.

The resolution is a bit wrong, it is 0.008333333300000 but should be 0.008333333333333, i.e. exactly 30 arc-seconds. This can be solved with the -a flag of r.in.gdal, or after import with r.region -a.

The message

360 degree EW extent is exceeded by 0.999827 cells

will change to

360 degree EW extent is exceeded by 1 cells

but will not go away, because 360 degree EW extent is exceeded in the input data, the first and last column cover the same geographical area. You can change your current region to chop of e.g. the first column: set the region to the raster, then modify the current region with g.region w=179:59:45W -p and use this region for further processing.

Markus M

360 degree EW extent is exceeded by 1.99983 cells

(Mon Jun 25 00:30:04 2018) Command finished (0 sec)

Virus-free. www.avg.com

On Sun, Jun 24, 2018 at 5:09 PM, Gabriel Cotlier <gabiklm01@gmail.com> wrote:

Dear Vero and Markus,

Thanks a lot for the guidance and help.

If I understood correctly:

I first have to import one layer when I select a location setting the coordinate system of that layer to the mapset of GRASS (at the start).

Then I have to import all other layers to mapset using command “r.in.gdal -a”

r.in.gdal -a input=C:\Users\Gabriel\Documents\layers\F121995.tif output=F121995

Then I have to running “g.region” to set up the same extent to all layers as follows:

g.region raster=F121995

and I got the layer processed and finished but the error did not went way…

|i Inter-satellite calibration of DMSP-OLS Nighttime Stable Lights
WARNING: Operating on current region

|> Calibrating average visible Digital Number values
Regression coefficients: (-0.0515, 1.2293, -0.0038) | Associated R^2: 0.9178

360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 1 cells

WARNING: As requested, timestamp transferring not attempted.
WARNING: No data base element files found

(Sun Jun 24 17:05:31 2018) Command finished (1 min 2 sec)

What could be doing wrong?
In addition I’m doing it for one layer here, is there a way to do it for many layers at onces with command line or GUI dialog box?

Thanks a lot again.

Gabriel

On Sat, Jun 23, 2018 at 6:31 AM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Sat, Jun 23, 2018 at 11:10 AM, Veronica Andreo <veroandreo@gmail.com> wrote:

Hi,

El sáb., 23 jun. 2018 4:35, Markus Metz <markus.metz.giswork@gmail.com> escribió:

On Fri, Jun 22, 2018 at 10:34 PM, Veronica Andreo <veroandreo@gmail.com> wrote:

Hi Gabriel,

What you could do is import with r.in.gdal -a that adjusts resolution for lat long maps [0]

that will help to fix the resolution from 0.008333333300000 to 0.008333333333333, i.e. exactly 30 arc-seconds. The software used to create the raster data has stored the resolution with limited precision.

Right, I overlooked this

and then (before the intercalibration step), set the region to one of the imported maps with g.region raster=yourmap

you will then get a message like
360 degree EW extent is exceeded by 1 cells

which is correct because the first and last column are duplicates. The cell centers cover -180, 180, and the EW extents regarding cell borders are E: 180:00:15E, W: 180:00:15W, grown by half a cell, i.e. 15 arc-seconds.

So, solution is to just use the data with the extra 15 arc-seconds in each side?

yes, or chop off the first or last column: set the region to the raster, then modify the current region with g.region w=179:59:45W -p

Of I want data to fit 180/-180, would r.region mymap e=180 w=180 help or will it change the data?

this would modify the data because

the raster will be shifted by half a cell to the east

the cell size (ew resolution) will be changed

Markus M

Vero

Gabriel_Cotlier · June 25, 2018, 2:33pm

Dear Markus,

Thanks a lot for the explanation.

After importing the layer F101992 I did :

r.region -a map=F101992@PERMANENT

and I got the results as you indicated, with the new resolution message:

360 degree EW extent is exceeded by 1 cells

Nonetheless, the message of the old resolution (360 degree EW extent is exceeded by 0.999827 cells) still appear but in the second line of the message bellow:

Could be this indicating it changed from old to new resolution?

Thanks a lot again for your help.

Best regards,

Gabriel

···

On Mon, Jun 25, 2018 at 3:29 AM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Mon, Jun 25, 2018 at 5:40 AM, Gabriel Cotlier <gabiklm01@gmail.com> wrote:

Hello,

I think I have found a similar situation solved for Linux version at:

https://trac.osgeo.org/grass/ticket/2757#comment:21

In my case I’m using GRASS 7.4.0 in Windows 10, and when I called for metadata info of the layer I got the message bellow with the problem highlighted in yellow bellow.

What could be happening? It would be very helpful to understand what is happening and how to solve importing many raster layers without this extent problems.

The resolution is a bit wrong, it is 0.008333333300000 but should be 0.008333333333333, i.e. exactly 30 arc-seconds. This can be solved with the -a flag of r.in.gdal, or after import with r.region -a.

The message

360 degree EW extent is exceeded by 0.999827 cells

will change to

360 degree EW extent is exceeded by 1 cells

but will not go away, because 360 degree EW extent is exceeded in the input data, the first and last column cover the same geographical area. You can change your current region to chop of e.g. the first column: set the region to the raster, then modify the current region with g.region w=179:59:45W -p and use this region for further processing.

Markus M

360 degree EW extent is exceeded by 1.99983 cells

(Mon Jun 25 00:30:04 2018) Command finished (0 sec)

Virus-free. www.avg.com

On Sun, Jun 24, 2018 at 5:09 PM, Gabriel Cotlier <gabiklm01@gmail.com> wrote:

Dear Vero and Markus,

Thanks a lot for the guidance and help.

If I understood correctly:

I first have to import one layer when I select a location setting the coordinate system of that layer to the mapset of GRASS (at the start).

Then I have to import all other layers to mapset using command “r.in.gdal -a”

r.in.gdal -a input=C:\Users\Gabriel\Documents\layers\F121995.tif output=F121995

Then I have to running “g.region” to set up the same extent to all layers as follows:

g.region raster=F121995

and I got the layer processed and finished but the error did not went way…

|i Inter-satellite calibration of DMSP-OLS Nighttime Stable Lights
WARNING: Operating on current region

|> Calibrating average visible Digital Number values
Regression coefficients: (-0.0515, 1.2293, -0.0038) | Associated R^2: 0.9178

360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 1 cells

WARNING: As requested, timestamp transferring not attempted.
WARNING: No data base element files found

(Sun Jun 24 17:05:31 2018) Command finished (1 min 2 sec)

What could be doing wrong?
In addition I’m doing it for one layer here, is there a way to do it for many layers at onces with command line or GUI dialog box?

Thanks a lot again.

Gabriel

On Sat, Jun 23, 2018 at 6:31 AM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Sat, Jun 23, 2018 at 11:10 AM, Veronica Andreo <veroandreo@gmail.com> wrote:

Hi,

El sáb., 23 jun. 2018 4:35, Markus Metz <markus.metz.giswork@gmail.com> escribió:

On Fri, Jun 22, 2018 at 10:34 PM, Veronica Andreo <veroandreo@gmail.com> wrote:

Hi Gabriel,

What you could do is import with r.in.gdal -a that adjusts resolution for lat long maps [0]

that will help to fix the resolution from 0.008333333300000 to 0.008333333333333, i.e. exactly 30 arc-seconds. The software used to create the raster data has stored the resolution with limited precision.

Right, I overlooked this

and then (before the intercalibration step), set the region to one of the imported maps with g.region raster=yourmap

you will then get a message like
360 degree EW extent is exceeded by 1 cells

which is correct because the first and last column are duplicates. The cell centers cover -180, 180, and the EW extents regarding cell borders are E: 180:00:15E, W: 180:00:15W, grown by half a cell, i.e. 15 arc-seconds.

So, solution is to just use the data with the extra 15 arc-seconds in each side?

yes, or chop off the first or last column: set the region to the raster, then modify the current region with g.region w=179:59:45W -p

Of I want data to fit 180/-180, would r.region mymap e=180 w=180 help or will it change the data?

this would modify the data because

the raster will be shifted by half a cell to the east

the cell size (ew resolution) will be changed

Markus M

Vero

Markus_Metz · June 25, 2018, 4:32pm

On Mon, Jun 25, 2018 at 4:33 PM, Gabriel Cotlier <gabiklm01@gmail.com> wrote:

Dear Markus,

Thanks a lot for the explanation.

After importing the layer F101992 I did :

r.region -a map=F101992@PERMANENT

and I got the results as you indicated, with the new resolution message:

360 degree EW extent is exceeded by 1 cells

Nonetheless, the message of the old resolution (360 degree EW extent is exceeded by 0.999827 cells) still appear but in the second line of the message bellow:

Could be this indicating it changed from old to new resolution?

Have you adjusted the current region to match the adjusted raster with
g.region -p raster=F101992

?

After that, the first or last column could be ignored in further processing by setting the region as I suggested before.

Markus M

Thanks a lot again for your help.

Best regards,

Gabriel

On Mon, Jun 25, 2018 at 3:29 AM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Mon, Jun 25, 2018 at 5:40 AM, Gabriel Cotlier <gabiklm01@gmail.com> wrote:

Hello,

I think I have found a similar situation solved for Linux version at:

https://trac.osgeo.org/grass/ticket/2757#comment:21

In my case I’m using GRASS 7.4.0 in Windows 10, and when I called for metadata info of the layer I got the message bellow with the problem highlighted in yellow bellow.

What could be happening? It would be very helpful to understand what is happening and how to solve importing many raster layers without this extent problems.

The resolution is a bit wrong, it is 0.008333333300000 but should be 0.008333333333333, i.e. exactly 30 arc-seconds. This can be solved with the -a flag of r.in.gdal, or after import with r.region -a.

The message

360 degree EW extent is exceeded by 0.999827 cells

will change to

360 degree EW extent is exceeded by 1 cells

but will not go away, because 360 degree EW extent is exceeded in the input data, the first and last column cover the same geographical area. You can change your current region to chop of e.g. the first column: set the region to the raster, then modify the current region with g.region w=179:59:45W -p and use this region for further processing.

Markus M

360 degree EW extent is exceeded by 1.99983 cells

(Mon Jun 25 00:30:04 2018) Command finished (0 sec)

Virus-free. www.avg.com

On Sun, Jun 24, 2018 at 5:09 PM, Gabriel Cotlier <gabiklm01@gmail.com> wrote:

Dear Vero and Markus,

Thanks a lot for the guidance and help.

If I understood correctly:

I first have to import one layer when I select a location setting the coordinate system of that layer to the mapset of GRASS (at the start).

Then I have to import all other layers to mapset using command “r.in.gdal -a”

r.in.gdal -a input=C:\Users\Gabriel\Documents\layers\F121995.tif output=F121995

Then I have to running “g.region” to set up the same extent to all layers as follows:

g.region raster=F121995

and I got the layer processed and finished but the error did not went way…

|i Inter-satellite calibration of DMSP-OLS Nighttime Stable Lights
WARNING: Operating on current region

|> Calibrating average visible Digital Number values
Regression coefficients: (-0.0515, 1.2293, -0.0038) | Associated R^2: 0.9178

360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 1 cells

WARNING: As requested, timestamp transferring not attempted.
WARNING: No data base element files found

(Sun Jun 24 17:05:31 2018) Command finished (1 min 2 sec)

What could be doing wrong?
In addition I’m doing it for one layer here, is there a way to do it for many layers at onces with command line or GUI dialog box?

Thanks a lot again.

Gabriel

On Sat, Jun 23, 2018 at 6:31 AM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Sat, Jun 23, 2018 at 11:10 AM, Veronica Andreo <veroandreo@gmail.com> wrote:

Hi,

El sáb., 23 jun. 2018 4:35, Markus Metz <markus.metz.giswork@gmail.com> escribió:

On Fri, Jun 22, 2018 at 10:34 PM, Veronica Andreo <veroandreo@gmail.com> wrote:

Hi Gabriel,

What you could do is import with r.in.gdal -a that adjusts resolution for lat long maps [0]

that will help to fix the resolution from 0.008333333300000 to 0.008333333333333, i.e. exactly 30 arc-seconds. The software used to create the raster data has stored the resolution with limited precision.

Right, I overlooked this

and then (before the intercalibration step), set the region to one of the imported maps with g.region raster=yourmap

you will then get a message like
360 degree EW extent is exceeded by 1 cells

which is correct because the first and last column are duplicates. The cell centers cover -180, 180, and the EW extents regarding cell borders are E: 180:00:15E, W: 180:00:15W, grown by half a cell, i.e. 15 arc-seconds.

So, solution is to just use the data with the extra 15 arc-seconds in each side?

yes, or chop off the first or last column: set the region to the raster, then modify the current region with g.region w=179:59:45W -p

Of I want data to fit 180/-180, would r.region mymap e=180 w=180 help or will it change the data?

this would modify the data because

the raster will be shifted by half a cell to the east

the cell size (ew resolution) will be changed

Markus M

Vero

NikosAlexandris · June 26, 2018, 7:53am

* Markus Metz <markus.metz.giswork@gmail.com> [2018-06-25 08:29:45 +0200]:

[..]

The resolution is a bit wrong, it is 0.008333333300000 but should be
0.008333333333333, i.e. exactly 30 arc-seconds. This can be solved with the
-a flag of r.in.gdal, or after import with r.region -a.

The message

360 degree EW extent is exceeded by 0.999827 cells

will change to

360 degree EW extent is exceeded by 1 cells

but will not go away, because 360 degree EW extent is exceeded in the input
data, the first and last column cover the same geographical area. You can
change your current region to chop of e.g. the first column: set the region
to the raster, then modify the current region with g.region w=179:59:45W -p
and use this region for further processing.

I guess this is worth being documented in the manual of the add-on. Would
it also make sense to let the module attempt to perform this "correction"?

Nikos

Markus_Metz · June 26, 2018, 12:40pm

On Tue, Jun 26, 2018 at 9:53 AM, Nikos Alexandris <nik@nikosalexandris.net> wrote:

Markus Metz <markus.metz.giswork@gmail.com> [2018-06-25 08:29:45 +0200]:

[…]

The resolution is a bit wrong, it is 0.008333333300000 but should be
0.008333333333333, i.e. exactly 30 arc-seconds. This can be solved with the
-a flag of r.in.gdal, or after import with r.region -a.

The message

360 degree EW extent is exceeded by 0.999827 cells

will change to

360 degree EW extent is exceeded by 1 cells

but will not go away, because 360 degree EW extent is exceeded in the input
data, the first and last column cover the same geographical area. You can
change your current region to chop of e.g. the first column: set the region
to the raster, then modify the current region with g.region w=179:59:45W -p
and use this region for further processing.

I guess this is worth being documented in the manual of the add-on.

This is a universal problem applying to various raster data in latlong. The first issue, 30 sec represented as 0.008333333300000 instead of 0.008333333333333 is solved by r.in.gdal -a. The second problem, this extra column responsible that 360 degree EW extent is exceeded by 1 cell can be solved by setting the current region accordingly. This is also a universal problem. Maybe the manual of r.in.gdal could include a hint about how to do this. Generally, users are encouraged to inspect the output of r.info after importing raster data to check if everything is as expected.

Would
it also make sense to let the module attempt to perform this “correction”?

If you refer to i.nightlights.intercalibration, I would say no, because it is a more general issue not restricted to DMSP-OLS nightlight data. Even more general, the current region as set by the user is used for raster processing (with a very few exceptions).

Markus M

NikosAlexandris · June 27, 2018, 7:55am

* Markus Metz <markus.metz.giswork@gmail.com> [2018-06-26 14:40:25 +0200]:

On Tue, Jun 26, 2018 at 9:53 AM, Nikos Alexandris <nik@nikosalexandris.net>
wrote:

* Markus Metz <markus.metz.giswork@gmail.com> [2018-06-25 08:29:45 +0200]:

[..]

The resolution is a bit wrong, it is 0.008333333300000 but should be
0.008333333333333, i.e. exactly 30 arc-seconds. This can be solved with

the

-a flag of r.in.gdal, or after import with r.region -a.

The message

360 degree EW extent is exceeded by 0.999827 cells

will change to

360 degree EW extent is exceeded by 1 cells

but will not go away, because 360 degree EW extent is exceeded in the

input

data, the first and last column cover the same geographical area. You can
change your current region to chop of e.g. the first column: set the

region

to the raster, then modify the current region with g.region w=179:59:45W

-p

and use this region for further processing.

I guess this is worth being documented in the manual of the add-on.

This is a universal problem applying to various raster data in latlong. The
first issue, 30 sec represented as 0.008333333300000 instead of
0.008333333333333 is solved by r.in.gdal -a. The second problem, this extra
column responsible that 360 degree EW extent is exceeded by 1 cell can be
solved by setting the current region accordingly. This is also a universal
problem. Maybe the manual of r.in.gdal could include a hint about how to do
this. Generally, users are encouraged to inspect the output of r.info after
importing raster data to check if everything is as expected.

Danke Markus. We should collect some of these hints.

(
Oh! I took on a refreshing read-tour: a pixel's anchor point, pixel-is-area,
pixel-is-center, center-to-center extent model, precision of pixel size.
Yet, I ended up reading about many more issues that people have to deal
with.

Some interesting entries:

- https://gis.stackexchange.com/q/122670/5256
- https://gis.stackexchange.com/a/243050/5256
)

Would
it also make sense to let the module attempt to perform this "correction"?

If you refer to i.nightlights.intercalibration, I would say no, because it
is a more general issue not restricted to DMSP-OLS nightlight data. Even
more general, the current region as set by the user is used for raster
processing (with a very few exceptions).

Yes, I refer to it. Understood, I won't touch upon this within the
module.

Nikos