<div dir="auto">Hi Gabriel,<div dir="auto"><br></div><div dir="auto">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<div dir="auto"><br></div><div dir="auto">HTH,</div><div dir="auto">Vero</div><div dir="auto"><br></div><div dir="auto">[0] <a href="https://grass.osgeo.org/grass74/manuals/r.in.gdal.html">https://grass.osgeo.org/grass74/manuals/r.in.gdal.html</a></div></div></div><br><div class="gmail_quote"><div dir="ltr">El vie., 22 jun. 2018 10:32, Gabriel Cotlier <<a href="mailto:gabiklm01@gmail.com" target="_blank" rel="noreferrer">gabiklm01@gmail.com</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Dear Nikos and Veronica,<div><br></div><div>Thanks a lot for your emails, I'm happy it worked!</div><div><br></div><div>I will try to avoid of the extent message 

<span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">"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 ?</span></div><div><br></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Thanks a lot again for your guidance.</span></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="font-size:12.8px">Gabriel   </span><br></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 22, 2018 at 12:50 AM, Nikos Alexandris <span dir="ltr"><<a href="mailto:nik@nikosalexandris.net" rel="noreferrer noreferrer" target="_blank">nik@nikosalexandris.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Gabriel Cotlier <<a href="mailto:gabiklm01@gmail.com" rel="noreferrer noreferrer" target="_blank">gabiklm01@gmail.com</a>> [2018-06-21 18:24:38 -0300]:<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello Veronica,<br>
<br>
Thanks a lot it worked!!<br>
</blockquote>
<br></span>
Dear Gabriel,<br>
<br>
Thanks for posting details and great it works. Don't worry about the<br>
last image, there are no coefficients for F18 and 2013. We are forced<br>
to skip this image in any analysis.<br>
<br>
<br>
Details<br>
<br>
Veronica is right, and I am ignorant for so many things when it comes to Windows.<br>
<br>
In Linux, one may use the syntax `some_command` or<br>
$(some_command). It's a smart way to feed-in longer list of items, such<br>
as map names in GRASS GIS. Note, the former is old-style, so best to use the $()<br>
notation (if of interest, see<br>
<a href="https://unix.stackexchange.com/a/5782/13011" rel="noreferrer noreferrer noreferrer" target="_blank">https://unix.stackexchange.com/a/5782/13011</a>).<br>
<br>
You might want to re-check the extent you have set, so as to<br>
get rid of the "360 degree EW extent is exceeded by 0.999827 cells"<br>
messages (?). Depending on how you have set your region, maybe the `-a`<br>
option for `g.region` would help (?).<br>
<br>
The last failing image is not a computational error. The error<br>
message<br>
--%<---<span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
ValueError: The selected model does not know about this<br>
combination of Satellite + Year!<br>
</blockquote></span>
--->%--<br>
means that there are no coefficients for satellite "F18" and for the<br>
year 2013. You may read this in<br>
<a href="https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_coefficients.py#L99" rel="noreferrer noreferrer noreferrer" target="_blank">https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_coefficients.py#L99</a><br>
and the referenced papers, of course.<br>
<br>
For various reasons, I did not improve the script in<br>
handling this situations. I just let it emit an error message. I hardly<br>
remember having modified this message to say something like "There are<br>
given coefficients for satellite F?? and Year ????". But I can't trace<br>
anything in my local repository.<br>
<br>
(<br>
Note, there are many newer algorithms. It would be obviously great to<br>
integrate some of them in the existing module. If a new model bases upon<br>
a similar math formula, then it's only necessary to add:<br>
<br>
1. a new set of coefficients in <a href="https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_coefficients.py#L38" rel="noreferrer noreferrer noreferrer" target="_blank">https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_coefficients.py#L38</a><br>
<br>
2. a new equation in <a href="https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_equations.py#L15" rel="noreferrer noreferrer noreferrer" target="_blank">https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_equations.py#L15</a><br>
<br>
3. a new subclass, for the new model, in <a href="https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_models.py" rel="noreferrer noreferrer noreferrer" target="_blank">https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_models.py</a><br>
<br>
Maybe more work if there is a substantially different math logic.<br>
)<br>
<br>
Thanks, Nikos<br>
</blockquote></div><br></div>
</blockquote></div>