On Fri, Jun 22, 2018 at 10:34 PM, Veronica Andreo <veroand...@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 <gabikl...@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 < n...@nikosalexandris.net> wrote: >>> >>> * Gabriel Cotlier <gabikl...@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 >> >> > > _______________________________________________ > grass-user mailing list > grass-user@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-user
_______________________________________________ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user