<!DOCTYPE html>

<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

  </head>

  <body>

    <p>Simon,<br>

    </p>

    <br>

    <blockquote type="cite"

cite="mid:CAJf0KTTRpsGZE4_6gy2J33FjHiburA586FYBTi_8TcoJLX8M5Q@mail.gmail.com">

      <div dir="ltr">

        <div>

          <div>One is the declared block size of a simple RGB PNG image,

            which we use for some raster import tests. The image is

            320x225 and <font face="monospace">gdalinfo</font> on x86

            reports that for the block size of the three bands also.

            However, on ARM it reports the block sizes as 320x1.</div>

        </div>

      </div>

    </blockquote>

    <p>Yes, this is expected, as on x86_64, on byte images <= 512x512

      pixels, there's a SSE2 optimization when decoding the whole image,

      which causes the size of the image to be set as the block size.

      You may disable this optimization by setting the

      GDAL_PNG_WHOLE_IMAGE_OPTIM=OFF config option, and you'll get a

      block height of 1, but I would recommend against it, unless this

      is for the purpose of having reproducible tests<br>

    </p>

    <blockquote type="cite"

cite="mid:CAJf0KTTRpsGZE4_6gy2J33FjHiburA586FYBTi_8TcoJLX8M5Q@mail.gmail.com">

      <div dir="ltr">

        <div>

          <div>The second difference is the point order of the (single,

            outer) ring of a MULTIPOLYGON when exported and re-imported

            as GeoJSONL. In either the export or the import (haven't

            looked that deeply yet) the ring is getting reversed. Note

            that the ring data is actually very bogus (lots of repeated

            points and no avoidance of self-intersection). We simplified

            it to topologically valid data and then there are no

            differences between platforms. So it's possible that the

            CW/CCW auto-detection/reversal is getting confused by some

            floating-point precision differences (which we have also

            encountered in other places). We are not worried about this

            one, having simplified the test so that it now passes, but

            the difference is still slightly concerning.</div>

        </div>

      </div>

    </blockquote>

    <p>Yes likely a floating-point precision difference in

      OGRLineString::isClockwise() computations</p>

    <p>Even<br>

    </p>

    <span style="white-space: pre-wrap">

</span>

    <pre class="moz-signature" cols="72">-- 

<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>

My software is free, but my time generally not.</pre>

  </body>

</html>