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

[Nikos Alexandris]

* Markus Metz <markus.metz.giswork at gmail.com> [2018-06-26 14:40:25 +0200]:

>On Tue, Jun 26, 2018 at 9:53 AM, Nikos Alexandris <nik at nikosalexandris.net>
>wrote:
>>
>> * Markus Metz <markus.metz.giswork at gmail.com> [2018-06-25 08:29:45 +0200]:
>>
>> [..]
>>
>>> The resolution is a bit wrong, it is 0.008333333300000 but should be
>>> 0.008333333333333, i.e. exactly 30 arc-seconds. This can be solved with
>the
>>> -a flag of r.in.gdal, or after import with r.region -a.
>>>
>>> The message
>>>
>>>> 360 degree EW extent is exceeded by 0.999827 cells
>>>
>>>
>>> will change to
>>>
>>>> 360 degree EW extent is exceeded by 1 cells
>>>
>>>
>>> but will not go away, because 360 degree EW extent is exceeded in the
>input
>>> data, the first and last column cover the same geographical area. You can
>>> change your current region to chop of e.g. the first column: set the
>region
>>> to the raster, then modify the current region with g.region w=179:59:45W
>-p
>>> and use this region for further processing.


>> I guess this is worth being documented in the manual of the add-on.
>
>This is a universal problem applying to various raster data in latlong. The
>first issue, 30 sec represented as 0.008333333300000 instead of
>0.008333333333333 is solved by r.in.gdal -a. The second problem, this extra
>column responsible that 360 degree EW extent is exceeded by 1 cell can be
>solved by setting the current region accordingly. This is also a universal
>problem. Maybe the manual of r.in.gdal could include a hint about how to do
>this. Generally, users are encouraged to inspect the output of r.info after
>importing raster data to check if everything is as expected.

Danke Markus. We should collect some of these hints.

(
Oh! I took on a refreshing read-tour: a pixel's anchor point, pixel-is-area,
pixel-is-center, center-to-center extent model, precision of pixel size.
Yet, I ended up reading about many more issues that people have to deal
with.

Some interesting entries:

- https://gis.stackexchange.com/q/122670/5256
- https://gis.stackexchange.com/a/243050/5256
)

>> Would
>> it also make sense to let the module attempt to perform this "correction"?
>
>If you refer to i.nightlights.intercalibration, I would say no, because it
>is a more general issue not restricted to DMSP-OLS nightlight data. Even
>more general, the current region as set by the user is used for raster
>processing (with a very few exceptions).

Yes, I refer to it. Understood, I won't touch upon this within the
module.

Nikos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20180627/64445280/attachment.sig>