<div dir="ltr"><br><br>On Fri, Jun 22, 2018 at 10:34 PM, Veronica Andreo <<a href="mailto:veroandreo@gmail.com">veroandreo@gmail.com</a>> wrote:<br>><br>> Hi Gabriel,<br>><br><div>> What you could do is import with r.in.gdal -a  that adjusts resolution for lat long maps [0] <br></div><div><br></div><div>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.<br></div><div><br></div><div>> and then (before the intercalibration step), set the region to one of the imported maps with g.region raster=yourmap</div><div><br></div><div>you will then get a message like</div><div>360 degree EW extent is exceeded by 1 cells</div><div><br></div><div>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.</div><div><br></div><div>Markus M<br></div><div><br></div><div>></div>> HTH,<br>> Vero<br>><br>> [0] <a href="https://grass.osgeo.org/grass74/manuals/r.in.gdal.html">https://grass.osgeo.org/grass74/manuals/r.in.gdal.html</a><br>><br>> El vie., 22 jun. 2018 10:32, Gabriel Cotlier <<a href="mailto:gabiklm01@gmail.com">gabiklm01@gmail.com</a>> escribió:<br>>><br>>> Dear Nikos and Veronica,<br>>><br>>> Thanks a lot for your emails, I'm happy it worked!<br>>><br>>> 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 ?<br>>><br>>> Thanks a lot again for your guidance.<br>>><br>>> Gabriel   <br>>><br>>><br>>> On Fri, Jun 22, 2018 at 12:50 AM, Nikos Alexandris <<a href="mailto:nik@nikosalexandris.net">nik@nikosalexandris.net</a>> wrote:<br>>>><br>>>> * Gabriel Cotlier <<a href="mailto:gabiklm01@gmail.com">gabiklm01@gmail.com</a>> [2018-06-21 18:24:38 -0300]:<br>>>><br>>>>> Hello Veronica,<br>>>>><br>>>>> Thanks a lot it worked!!<br>>>><br>>>><br>>>> 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">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>>>> --%<---<br>>>>><br>>>>> ValueError: The selected model does not know about this<br>>>>> combination of Satellite + Year!<br>>>><br>>>> --->%--<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">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">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">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">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>>><br>>><br>><br>> _______________________________________________<br>> grass-user mailing list<br>> <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>> <a href="https://lists.osgeo.org/mailman/listinfo/grass-user">https://lists.osgeo.org/mailman/listinfo/grass-user</a><br><br></div>