On Tue, Feb 7, 2017 at 3:43 PM, Markus Neteler <nete...@osgeo.org> wrote: > > On Tue, Feb 7, 2017 at 3:32 PM, Markus Metz > <markus.metz.gisw...@gmail.com> wrote: > [...] > > Unfortunately it changes East from 179.9998611 to 179.9998597 and north > > from 83.9998611 to 83.9998604. > > > > The more serious problem is that GRASS can not handle ll coordinates like > > 180:0:0.50W or 90:0:0.5S. > > > > I have relaxed the ll restrictions in my local copy and can now import > > CHELSA and other for GRASS problematic ll datasets without getting e.g. a > > narrow N-S strip, or GRASS fixing a subtle rounding error that in fact is > > not an error. That means after each import I have to manually check if > > resolution and extents make sense, and if in doubt fix them with r.region. > > That's probably rather more a power user task than common user > knowledge...
Why a power user task? r.region is an easy to use module, as long as you know the correct grid geometry. And with my relaxed ll restrictions I get less errors and more usable results, in fact I need to use r.region less often than before. > Is there anything we could do at libgis level like > relaxing the ll restrictions along with appropriate user messages? Yes. The first points would be ll_scan.c, ll_format.c and adj_cellhd.c. That should also remove cryptic errors like "ERROR: Syntax error in cell header". > More and more global datasets are getting published, so the issue will > likely come up more frequently. Just to make it a bit easier :-) For a start, it would be nice if you can create a full SRTM mosaik (not so new data) in GRASS. Markus M > > markusN
_______________________________________________ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user