* Markus Metz <[email protected]> [2018-06-26 14:40:25 +0200]:
On Tue, Jun 26, 2018 at 9:53 AM, Nikos Alexandris <[email protected]> wrote:* Markus Metz <[email protected]> [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 withthe-a flag of r.in.gdal, or after import with r.region -a. The message360 degree EW extent is exceeded by 0.999827 cellswill change to360 degree EW extent is exceeded by 1 cellsbut will not go away, because 360 degree EW extent is exceeded in theinputdata, 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 theregionto the raster, then modify the current region with g.region w=179:59:45W-pand 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
signature.asc
Description: PGP signature
_______________________________________________ grass-user mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/grass-user
