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 El vie., 22 jun. 2018 10:32, Gabriel Cotlier <[email protected]> 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 < > [email protected]> wrote: > >> * Gabriel Cotlier <[email protected]> [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 >> > >
_______________________________________________ grass-user mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/grass-user
