<div dir="ltr"><div><br><br>On Tue, Feb 7, 2017 at 3:43 PM, Markus Neteler <<a href="mailto:neteler@osgeo.org">neteler@osgeo.org</a>> wrote:<br>><br>> On Tue, Feb 7, 2017 at 3:32 PM, Markus Metz<br>> <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>> wrote:<br>> [...]<br>> > Unfortunately it changes East from 179.9998611 to 179.9998597 and north<br>> > from 83.9998611 to 83.9998604.<br>> ><br>> > The more serious problem is that GRASS can not handle ll coordinates like<br>> > 180:0:0.50W or 90:0:0.5S.<br>> ><br>> > I have relaxed the ll restrictions in my local copy and can now import<br>> > CHELSA and other for GRASS problematic ll datasets without getting e.g. a<br>> > narrow N-S strip, or GRASS fixing a subtle rounding error that in fact is<br>> > not an error. That means after each import I have to manually check if<br>> > resolution and extents make sense, and if in doubt fix them with r.region.<br>><br>> That's probably rather more a power user task than common user<br>> knowledge...<br><br></div>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.<br><div><br>> Is there anything we could do at libgis level like<br>> relaxing the ll restrictions along with appropriate user messages?<br><br></div><div>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".<br></div><div><br>> More and more global datasets are getting published, so the issue will<br>> likely come up more frequently. Just to make it a bit easier :-)<br><br></div><div>For a start, it would be nice if you can create a full SRTM mosaik (not so new data) in GRASS.<br><br></div><div>Markus M<br></div><div><br>><br>> markusN<br><br></div></div>