liblwgeom support on macOS
pat-s opened this issue · 17 comments
I did brew install liblwgeom && brew link --force liblwgeom and during sf source install liblwgeom is found. However, lwgeom_version in -llwgeom is not found.
checking liblwgeom.h usability... yes
checking liblwgeom.h presence... yes
checking for liblwgeom.h... yes
checking for lwgeom_version in -llwgeom... no
sf v0.4.3
Any ideas where to look here? I do not know where -llwgeom is referring to..
My guess is that the version of lwgeom is too old, but I haven't tried or looked into.
- brew: 2.1.5_3 (Dec 2013)
- latest postgis: 2.3.2
- Debian 9: 2.3.1 (Sep 2016)
It seems patching the brew formula might not be that easy -> brew edit liblwgeom 10-13:
Strip all the PostgreSQL functions from PostGIS configure.ac, to allow
building liblwgeom.dylib without needing PostgreSQL
NOTE: this will need to be maintained per postgis version
Somehow, this still works for 2.1.5, which is awesome!
I see, on ubuntu 16.04:
> library(sf)
Linking to GEOS 3.5.1, GDAL 2.1.3, proj.4 4.9.2, lwgeom 2.3.2 r15302(seems that lwgeom versions follow postgis version)
(seems that lwgeom versions follow postgis version)
jep, its dev repository is within the postgis one: https://github.com/postgis/postgis/tree/svn-trunk/liblwgeom
So we can close this one, right?
I would like to leave it open until there is a working solution for the liblwgeom install - the current brew version does not work (probably its too old as you suggested). I will later try to install from source / patch the brew formula.
ping @bhaskarvk
I like to see open issues as issues that need work on the side of sf. As this is an issue with brew and MacOS, I'm closing here, but would welcome it if you report back here when you've settled that.
brew install postgis solves the problem as it does the linking to -llwgeom
checking liblwgeom.h usability... yes
checking liblwgeom.h presence... yes
checking for liblwgeom.h... yes
checking for lwgeom_version in -llwgeom... yes
I also checked that st_make_valid() is working.
It would be good if a message could be thrown that it depends on brew install postgis if one tries to use st_make_valid() on macOS. Currently it looks likes this:
st_make_valid(poly) -> poly_V
Error in CPL_make_valid(x) :
st_make_valid requires compilation against liblwgeom
and if one does brew install liblwgeom it will not work. So the current message is right in terms of dependency but misleading when one wants to solve the issue -> see PR #350
I successfully installed using brew install postgis, but I still generate the Error in CPL_make_valid(x) : st_make_valid requires compilation against liblwgeom error. I have confirmed that I have liblwgeom installed and have reinstalled sf, nothing seems to be working. Any suggestions here?
Works for me. Do you have different settings?
devtools::session_info("sf")
Session info ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
setting value
version R version 3.4.1 (2017-06-30)
system x86_64, darwin16.7.0
ui RStudio (1.1.362)
language (EN)
collate en_US.UTF-8
tz Europe/Berlin
date 2017-09-15
Packages -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
package * version date source
DBI 0.7 2017-06-18 CRAN (R 3.4.0)
graphics * 3.4.1 2017-08-18 local
grDevices * 3.4.1 2017-08-18 local
grid 3.4.1 2017-08-18 local
magrittr 1.5 2014-11-22 CRAN (R 3.3.2)
methods * 3.4.1 2017-08-18 local
Rcpp 0.12.12 2017-07-15 CRAN (R 3.4.1)
sf * 0.5-4 2017-08-28 CRAN (R 3.4.1)
stats * 3.4.1 2017-08-18 local
tools 3.4.1 2017-08-18 local
udunits2 0.13 2016-11-17 CRAN (R 3.3.2)
units 0.4-6 2017-08-27 CRAN (R 3.4.1)
utils * 3.4.1 2017-08-18 local Linking to GEOS 3.6.2, GDAL 2.2.1, proj.4 4.9.3, lwgeom 2.3.2 r15302
x = st_sfc(st_polygon(list(rbind(c(0,0),c(0.5,0),c(0.5,0.5),c(0.5,0),c(1,0),c(1,1),c(0,1),c(0,0)))))
st_make_valid(x)
Geometry set for 1 feature
geometry type: GEOMETRYCOLLECTION
dimension: XY
bbox: xmin: 0 ymin: 0 xmax: 1 ymax: 1
epsg (SRID): NA
proj4string: NA
GEOMETRYCOLLECTION (POLYGON ((0.5 0, 0 0, 0 1, ...Using your example I generate the same Error in CPL_make_valid(x) : st_make_valid requires compilation against liblwgeom. My devtools::session_info("sf") shows the same information:
setting value
version R version 3.4.1 (2017-06-30)
system x86_64, darwin15.6.0
ui RStudio (1.0.143)
language (EN)
collate en_US.UTF-8
tz America/Denver
date 2017-09-15
Packages -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
package * version date source
DBI 0.7 2017-06-18 CRAN (R 3.4.0)
graphics * 3.4.1 2017-07-07 local
grDevices * 3.4.1 2017-07-07 local
grid 3.4.1 2017-07-07 local
magrittr 1.5 2014-11-22 CRAN (R 3.4.0)
methods * 3.4.1 2017-07-07 local
Rcpp 0.12.12 2017-07-15 CRAN (R 3.4.1)
sf 0.5-4 2017-08-28 CRAN (R 3.4.1)
stats * 3.4.1 2017-07-07 local
tools 3.4.1 2017-07-07 local
udunits2 0.13 2016-11-17 CRAN (R 3.4.0)
units 0.4-6 2017-08-27 CRAN (R 3.4.1)
utils * 3.4.1 2017-07-07 local
A possible error source could be that you are not running macOS Sierra but El Capitan as far as I can see?
Did sf successfully compile against liblwgeomduring installation?
install.packages("sf")
[...]
checking liblwgeom.h usability... yes
checking liblwgeom.h presence... yes
checking for liblwgeom.h... yes
checking for lwgeom_version in -llwgeom... yes
Doesn't look that way - it seems to be searching for an el-capitan folder. I didn't think OS Sierra would have made a difference! I'll just use a docker container until Sierra is compatible with sf. Thanks!
Installing package into ‘/Users/nami1114/Library/R/3.4/library’
(as ‘lib’ is unspecified)
Warning in install.packages :
cannot open URL 'https://cran.rstudio.com/bin/macosx/el-capitan/contrib/3.4/PACKAGES.rds': HTTP status was '404 Not Found'
trying URL 'https://cran.rstudio.com/bin/macosx/el-capitan/contrib/3.4/sf_0.5-4.tgz'
Content type 'application/x-gzip' length 35969512 bytes (34.3 MB)
==================================================
downloaded 34.3 MB
The downloaded binary packages are in
/var/folders/jw/l23y3f2j7m7b5mchg3mdg8g87kc8gr/T//RtmpYl7luO/downloaded_packages
I'll just use a docker container until Sierra is compatible with sf.
Don't understand what you mean. sf is compatible with Sierra. However, there are problems on El Capitan obviously.
Try to explicitly install from source and not use the binary: install.packages("sf", type="source")
Sorry. Misunderstood. I am using macOS Sierra, NOT El Captain. The install from the source does not work, thanks for the suggestion.
I have been using a docker container in the meantime to get around this issue.
Did you update your system since your last post? Your sessionInfo() output tells that you are running ElCapitan:
system x86_64, darwin15.6.0
Sierra has darwin16.x.x.
Also, the logs of the source installation (install.packages(sf)) would be helpful here.
its not about liblwgeomat all but your gdal config is not properly setup.
Follow the instructions of the README:
brew unlink gdal
brew tap osgeo/osgeo4mac && brew tap --repair
brew install proj
brew install geos
brew install udunits
brew install gdal2 --with-armadillo --with-complete --with-libkml --with-unsupported
brew link --force gdal2