PostGIS uses in-memory trees to optimize its geodetic distance calculations (see related ticket). This could easily be exposed in the lwgeom package (see commit) except that it requires inclusion of a non-public header.
If the lwgeom package always uses its included copy of liblwgeom, there doesn't seem to be a problem with using this header, but a quick scan of the automake file leaves me with the impression that this package sometimes uses the system lwgeom instead of the bundled one.
The prototypes could most likely be added to the public liblwgeom.h header, though most users wouldn't see that until the next PostGIS release in ~ 1 year.
FWIW, the performance difference is roughly 50% on a quick point-line test, and obviously increases with the complexity of the input geometries, although this is subject to the caveat described in r-spatial/sf#885.
# master branch
> microbenchmark(st_geod_distance(coast, plants[1:4,]), times=10)
Unit: seconds
expr min lq mean median uq max neval
st_geod_distance(coast, plants[1:4, ]) 3.79407 3.799992 3.841222 3.805284 3.875724 3.967692 10
# distance-tree branch
> microbenchmark(st_geod_distance(coast, plants[1:4,]), times=10)
Unit: seconds
expr min lq mean median uq max neval
st_geod_distance(coast, plants[1:4, ]) 1.80738 1.817252 1.895973 1.838641 1.961336 2.118409 10
PostGIS uses in-memory trees to optimize its geodetic distance calculations (see related ticket). This could easily be exposed in the
lwgeompackage (see commit) except that it requires inclusion of a non-public header.If the
lwgeompackage always uses its included copy ofliblwgeom, there doesn't seem to be a problem with using this header, but a quick scan of the automake file leaves me with the impression that this package sometimes uses the systemlwgeominstead of the bundled one.The prototypes could most likely be added to the public
liblwgeom.hheader, though most users wouldn't see that until the next PostGIS release in ~ 1 year.FWIW, the performance difference is roughly 50% on a quick point-line test, and obviously increases with the complexity of the input geometries, although this is subject to the caveat described in r-spatial/sf#885.