<div dir="ltr"><br><br>On Sun, Nov 25, 2018 at 2:24 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br>><br>> On samedi 24 novembre 2018 23:09:34 CET Markus Metz wrote:<br>> > I have created a PR for this, but there are still issues:<br>> ><br>> > is<br>> > Pixel Size = (0.099999991285714,-0.100000004000000)<br>> > Corner Coordinates:<br>> > Upper Left  ( -25.0000122,  69.9999970)<br>> > Lower Left  ( -25.0000122,  29.9999954)<br>> > Upper Right (  44.9999817,  69.9999970)<br>> > Lower Right (  44.9999817,  29.9999954)<br>> > Center      (   9.9999847,  49.9999962)<br>> ><br>> > should be<br>> > Pixel Size = (0.100000000000000,-0.100000000000000)<br>> > Corner Coordinates:<br>> > Upper Left  ( -25.0000000,  70.0000000)<br>> > Lower Left  ( -25.0000000,  30.0000000)<br>> > Upper Right (  45.0000000,  70.0000000)<br>> > Lower Right (  45.0000000,  30.0000000)<br>> > Center      (  10.0000000,  50.0000000)<br>><br>> Yes, the issue is that the data type for the x variable in the .nc file is<br>> float32, so it has not enough precision. You could try to round the coodinates<br>> with some heuristics, like (untested !)<br>><br>> for the resolution:<br>><br>> double K = std::pow(10, 4 - std::round(std::log(res) / std::log(10)));<br>> if( std::fabs(K * res - std::round(K * res)) < 1 )<br>> {<br>>         res = std::round(K * res) / K;<br>> }<br>><br>> for the coordinates:<br>><br>> // Case where coordinates are aligned on a multiple of the resolution<br>> if ( std::fabs(x / res - std::round(x / res)) < 1e-3 )<br>> {<br>>     x = std::round(x / res) * res<br>> }<br>> // Case were they are aligned with a half-pixel shift<br>> else if (std::fabs((x - res/2)/res) - std::round((x - res/2)/res)) < 1e-3 )<br>> {<br>>     x = std::round((x - res/2)/res) * res + res/2;<br>> }<br><div><br></div><div>Many datasets with degrees as coordinate units have resolution and extents that can be expressed as integer or 0.5 seconds, e.g. SRTM at 1, 3, and 30 arc seconds. Some of these deviations caused by fp precision limits go away if you convert to arc seconds and then round to the nearest e.g. 1e-6 arc second. GRASS GIS is using this approach successfully.</div><div><br></div><div>About the PR: if the tested nc files are formally legal with their longitude jump at 359.95, 0.04998779, then this could be regarded as a bug fix, right?</div><div><br></div><div>Markus M<br></div></div>