<div dir="ltr"><div><div><div><br><br>On Fri, Feb 10, 2017 at 5:53 PM, Paulo van Breugel <<a href="mailto:p.vanbreugel@gmail.com">p.vanbreugel@gmail.com</a>> wrote:<br>><br>><br>><br>> On 10-02-17 17:15, Markus Metz wrote:<br>><br>><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>> 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>><br>><br>> Not sure that is what Markus meant, but "relaxed the restriction in my local copy" sounds definitely like a power user task to me. If this is something that can, and will, be done at the libgis level, great.<br><br></div>Fixing most of the ll wrap issues can be done at the libgis level. When I wrote "relaxed the restriction in my local copy", I meant I would like to commit by local changes, but would also like to know if it is ok to relax the -180, 180 restriction for W-E and the -90, 90 restriction for S-N in GRASS.<br><br></div>Issues as reported e.g. in tickets #352 and #2757 could easily be fixed with r.region, but it would be much more convenient if there would be no need to use r.region.<br><br></div>Markus M<br><div><div><div><br>> Otherwise, I would be interested to know how to do this.<br>><br>><br>> > Is there anything we could do at libgis level like<br>> > relaxing the ll restrictions along with appropriate user messages?<br>><br>> 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>><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>> For a start, it would be nice if you can create a full SRTM mosaik (not so new data) in GRASS.<br>><br>> Markus M<br>><br>> ><br>> > markusN<br>><br>><br>><br>> _______________________________________________<br>> grass-user mailing list<br>> <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>> <a href="https://lists.osgeo.org/mailman/listinfo/grass-user">https://lists.osgeo.org/mailman/listinfo/grass-user</a><br>><br>><br>><br>> _______________________________________________<br>> grass-user mailing list<br>> <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>> <a href="https://lists.osgeo.org/mailman/listinfo/grass-user">https://lists.osgeo.org/mailman/listinfo/grass-user</a><br><br></div></div></div></div>