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

[Veronica Andreo]

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 <gabiklm01 at 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 at nikosalexandris.net> wrote:
>
>> * Gabriel Cotlier <gabiklm01 at 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20180622/6316b4bc/attachment.html>