Closed rsbivand closed 3 months ago
Yes, this is hardcoded here: https://github.com/r-spatial/lwgeom/blob/master/src/postgis_config.h.in#L25 , and is not being set (AFAICT) in the configure
script.
... on the positive side, it took over 6 years to surface!
Better late than never! Someone will manufacture a big-endian ARM sometime - I think this entered the code after the last SPARC test platform failed.
Someone with a bigendian machine needs to test whether this now works!
@barracuda156 could you please check the current state of lwgeom?
Someone with a bigendian machine needs to test whether this now works!
@edzer @rsbivand Will test today, sure.
That would be great; the last commit should have fixed this.
@edzer @rsbivand Looks like version from 304022fee6bc91e0641dabedfa631971b41a463f works:
> library(sf)
Linking to GEOS 3.12.1, GDAL 3.8.5, PROJ 9.4.0; sf_use_s2() is TRUE
> nc = st_read(system.file("shapes/sids.shp", package="spData")[1])
Reading layer `sids' from data source
`/opt/local/Library/Frameworks/R.framework/Versions/4.4/Resources/library/spData/shapes/sids.shp'
using driver `ESRI Shapefile'
Simple feature collection with 100 features and 22 fields
Geometry type: MULTIPOLYGON
Dimension: XY
Bounding box: xmin: -84.32385 ymin: 33.88199 xmax: -75.45698 ymax: 36.58965
CRS: NA
> st_crs(nc) <- "+proj=longlat +datum=NAD27"
> library(lwgeom)
Linking to liblwgeom 3.0.0beta1 r16016, GEOS 3.12.1, PROJ 9.4.0
Attaching package: ‘lwgeom’
The following object is masked from ‘package:sf’:
st_perimeter
> st_geod_area(nc)
Units: [m^2]
[1] 1137388604 611077263 1423489919 694546292 1520740530 967727952
[7] 615942210 903650119 1179347051 1232769242 1136287383 1524655447
[13] 1427072339 1085967384 718190417 1894045426 524418608 1986966652
[19] 812293946 626337436 439717946 640703090 863300187 1276536764
[25] 1084141138 1697937846 1109973986 1800646340 1036414044 770546970
[31] 1423171283 585232978 1311628320 1225109692 800263351 1186420419
[37] 2194592880 1179139746 1550312884 690606074 665152821 1457875905
[43] 1340538971 1005743617 988324117 1163892506 2019778925 1810512144
[49] 944425951 1350102629 1685154840 1068192109 1691487743 2082117118
[55] 1447094476 943881740 2045540782 1420919020 707671880 653368537
[61] 1471077596 1436135571 1550981080 1186028306 788535203 1265443511
[67] 1829439189 1447873644 918216585 1312723474 1043728456 961860121
[73] 781910957 1046066043 986730350 917752685 601326678 1321916259
[79] 2437929994 833538942 1210326313 1738550168 1228689798 1648412173
[85] 1400582685 995107225 1678077407 2071844302 1228274216 519198288
[91] 1784932020 808600209 1978619669 2439553215 1264050755 2288682896
[97] 2181174167 2450241815 430695499 2165843695
Thanks for fixing it!
Thanks for confirming!
@edzer Failure reported https://github.com/r-spatial/spdep/issues/154 by @barracuda156 on PowerPC, there causing a failure in an
spdep
vignette. It is triggered on PowerPC by:suggesting an incorrect conversion from WKB in liblwgeom on that platform.