Simon,
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 gdalinfo on x86 reports that for the block size of the three bands also. However, on ARM it reports the block sizes as 320x1.
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
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.
Yes likely a floating-point precision difference in OGRLineString::isClockwise() computations
Even -- http://www.spatialys.com My software is free, but my time generally not.
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
