Re: [R-sig-Geo] How to efficiently generate data of neighboring points
Thank you very much for your support. This gives me what I need and I must
say listw2sn() is really great.
Why do I need the data in the format as in dataout? I am trying to test
spatial dependence (or neighborhood effect) by running a regression model
that entails pop_size_it = beta_1*sum of pop_size of point i's neighbors
within a specified radius. So my plan is to get the neighbors for each
focal point
as per the specified bands and their attributes (eg pop_size) so I can can
add them (attribute) by the bands.
I am totally new to the area of spatial econometrics, so I am taking things
one step at a time. Some readings suggest I may need distance matrix or
weight matrix but for now I think I should try the current approach.
Thank you.
-
Lom
On Wed, Jun 3, 2020 at 8:18 AM Roger Bivand wrote:
> On Wed, 3 Jun 2020, Lom Navanyo wrote:
>
> > I had the errors with rtree using R 3.6.3. I have since changed to R
> 4.0.0
> > but I got the same error.
> >
> > And yes, for Roger's example, I have the objects wd1, ... wd4, all with
> > length 101. I think my difficulty is my inability to output the list
> > detailing the point IDs t50_fid.
>
> library(spData)
> library(sf)
> projdata<-st_transform(nz_height, 32759)
> pts <- st_coordinates(projdata)
> library(spdep)
> bufferR <- c(402.336, 1609.34, 3218.69, 4828.03, 6437.38)
> bds <- c(0, bufferR)
> wd1 <- dnearneigh(pts, bds[1], bds[2])
> wd2 <- dnearneigh(pts, bds[2], bds[3])
> wd3 <- dnearneigh(pts, bds[3], bds[4])
> wd4 <- dnearneigh(pts, bds[4], bds[5])
> sn_band1 <- listw2sn(nb2listw(wd1, style="B", zero.policy=TRUE))
> sn_band1$band <- paste(attr(wd1, "distances"), collapse="-")
> sn_band2 <- listw2sn(nb2listw(wd2, style="B", zero.policy=TRUE))
> sn_band2$band <- paste(attr(wd2, "distances"), collapse="-")
> sn_band3 <- listw2sn(nb2listw(wd3, style="B", zero.policy=TRUE))
> sn_band3$band <- paste(attr(wd3, "distances"), collapse="-")
> sn_band4 <- listw2sn(nb2listw(wd4, style="B", zero.policy=TRUE))
> sn_band4$band <- paste(attr(wd4, "distances"), collapse="-")
> data_out <- do.call("rbind", list(sn_band1, sn_band2, sn_band3, sn_band4))
> class(data_out) <- "data.frame"
> table(data_out$band)
> data_out$ID_from <- projdata$t50_fid[data_out$from]
> data_out$ID_to <- projdata$t50_fid[data_out$to]
> data_out$elev_from <- projdata$elevation[data_out$from]
> data_out$elev_to <- projdata$elevation[data_out$to]
> str(data_out)
>
> The "spatial.neighbour" representation was that used in the S-Plus
> SpatialStats module, with "from" and "to" columns, and here drops
> no-neighbour cases gracefully. So listw2sn() comes in useful
> for creating the output, and from there, just look-up in the
> input data.frame. Observations here cannot be their own neighbours.
>
> It would be relevant to know why you need these, are you looking at
> variogram clouds?
>
> Hope this clarifies,
>
> Roger
>
> >
> > -
> > Lom
> >
> > On Tue, Jun 2, 2020 at 8:02 PM Kent Johnson wrote:
> >
> >> Roger's example works for me and gives a list of length 101. I did have
> >> some issues that were resolved by updating packages. I'm using R 3.6.3
> on
> >> macOS 10.15.4. I also use rtree successfully on Windows 10 with R 3.6.3.
> >>
> >> Kent
> >>
> >> On Tue, Jun 2, 2020 at 12:29 PM Roger Bivand
> wrote:
> >>
> >>> On Tue, 2 Jun 2020, Kent Johnson wrote:
> >>>
> rtree uses Euclidean distance so the points should be in a coordinate
> system where this makes sense at least as a reasonable approximation.
> >>>
> >>> I tried the original example:
> >>>
> >>> remotes::install_github("hunzikp/rtree")
> >>> library(spData)
> >>> library(sf)
> >>> projdata<-st_transform(nz_height, 32759)
> >>> library(rtree)
> >>> pts <- st_coordinates(projdata)
> >>> rt <- RTree(st_coordinates(projdata))
> >>> bufferR <- c(402.336, 1609.34, 3218.69, 4828.03, 6437.38)
> >>> wd1 <- withinDistance(rt, pts, bufferR[1])
> >>>
> >>> but unfortunately failed (maybe newer Boost headers than yours?):
> >>>
> >>> Error in UseMethod("withinDistance", rTree) :
> >>>no applicable method for 'withinDistance' applied to an object of
> >>> class
> >>> "c('list', 'RTree')"
> >>>
>
> Kent
>
> On Tue, Jun 2, 2020 at 9:59 AM Roger Bivand
> >>> wrote:
>
> > On Tue, 2 Jun 2020, Kent Johnson wrote:
> >
> >>> Date: Tue, 2 Jun 2020 02:44:17 -0500
> >>> From: Lom Navanyo
> >>> To: r-sig-geo@r-project.org
> >>> Subject: [R-sig-Geo] How to efficiently generate data of
> neighboring
> >>> points within specified radii (distances) for each point
> in a
> > given
> >>> points data set.
> >>>
> >>
> >>
> >>> Hello,
> >>> I have data set of about 3400 location points with which I am
> trying
> >>> to
> >>> generate data of each point and their neighbors within defined
> radii
> > (eg,
> >>> 0.25, 1, and 3 miles).
> >>>
> >>
> >> The rtree package is very fast and memory-efficient for
> >>> wit
Re: [R-sig-Geo] rgdal: About the new gdal3 and proj >=6 condition
I was trying from source, but now installed the binary.
Thank you
On Wed, Jun 3, 2020 at 3:30 PM Roger Bivand wrote:
> On Wed, 3 Jun 2020, Abdoulaye Sarr wrote:
>
> > Have a problem with needed gdal version on mac
>
> Please be much more specific. CRAN has macOS binaries of rgdal 1.5-8. Are
> you trying to install all the external software dependencies then rgdal
> from source? If this is difficult, rely on the CRAN macOS binaries, even
> though the PROJ and GDAL versions do not yet support WKT2 CRS
> representation. If you have installed PROJ and GDAL successfully, and PROJ
> < 6 && GDAL < 3, or PROJ >= 6 && GDAL >= 3, you should be OK. If you have
> the pointless PROJ >= 6 && GDAL < 3, you need the 1.5-9 tarball from
> R-forge, download locally and run R CMD INSTALL
> --configure-args="--with-proj_api=proj_api.h" rgdal_1.5-9.tar.gz.
>
> Please report back on specifics, or simply use CRAN binaries and report
> that.
>
> We are actively looking for ways to prevent macOS users getting trapped
> into trying to install from source when such a choice is not appropriate.
> We have no control over the provenance of the installed software as we
> have for Windows, thanks to Jeroen's rwinlib/gdal3 collection.
>
> Roger
>
> >
> > On Tue, Jun 2, 2020 at 4:04 PM Robin Lovelace wrote:
> >
> >> Confirmed: this worked perfectly for me.
> >>
> >> Video evidence that this is fixed:
> >> https://asciinema.org/a/zPQFbI6Q01oqUy1HRauCjLUXY
> >>
> >> Thanks Roger!
> >>
> >> Robin
> >>
> >> On Tue, Jun 2, 2020 at 4:00 PM Roger Bivand
> wrote:
> >>
> >>> Brian Ripley (thanks!) provided a patch for rgdal's configure.ac, and
> >> the
> >>> R-forge build and check processes now succeed, so please try to install
> >>> either downloading
> >>> http://download.r-forge.r-project.org/src/contrib/rgdal_1.5-9.tar.gz
> and
> >>> installing from the command line (after running R CMD check), or
> >>> install.packages("rgdal", repos="http://R-Forge.R-project.org";).
> >>>
> >>> Remember that if GDAL is < 3, and PROJ >= 6, you need the configure
> >>> argument: --configure-args=--with-proj_api=proj_api.h.
> >>>
> >>> Roger
> >>>
> >>> On Sun, 31 May 2020, Roger Bivand wrote:
> >>>
> Fresh version of rgdal rev 995 on link and R-forge, with more tweaks
> to
> >>> the
> configure file. Please test.
>
> Roger
>
> On Fri, 29 May 2020, Roger Bivand wrote:
>
> > I have put a tarball, built without vignettes with GDAL 2.2.4 and
> >> PROJ
> > 7.0.1 that passes CMD check (with warnings for missing vignettes)
> on:
> >
> > http://spatial.nhh.no/R/rgdal/gdal_1.5-9.tar.gz
> >
> > It involves code copying to provide duplicated functions in three
> > settings:
> >
> > PROJ < 6 & GDAL < 3
> > PROJ > = 6 & GDAL >= 3
> > PROJ > = 6 & GDAL < 3 (your homebrew case)
> >
> > You need the configure argument:
> > --configure-args=--with-proj_api=proj_api.h.
> > Without the argument, you now get directed to use it.
> >
> > For now I've dropped the configure tests for sqlite3, curl and tiff;
> >>> works
> > for me but may not work for you.
> >
> > Please make the output of:
> >
> > R CMD check
> >>> --install-args="--configure-args=--with-proj_api=proj_api.h"
> > rgdal_1.5-9.tar.gz
> >
> > available ASAP. I count on an immediate response.
> >
> > Roger
> >
> > On Fri, 29 May 2020, Roger Bivand wrote:
> >
> >> On Fri, 29 May 2020, Patrick Schratz wrote:
> >>
> >>>The just released rgdal v1.5.8 requires gdal >= 3 when proj >= 6
> >> is
> >>>present. It does not even install the package if this condition
> >> is
> >>> not
> >>>met
> >>>but errors during linking.
> >>
> >> Please document with the output of 00install.out from R CMD check
> >> rgdal_1.5-8.tar.gz, and pkg-config proj --modversion, gdalinfo
> >>> --version
> >> with system details.
> >>
> >> Yes, PROJ >= 6 makes no sense without GDAL >= 3; GDAL 3 makes no
> >>> sense
> >> with PROJ < 6. GDAL 3 with PROJ < 6 uses the old proj_api.h API
> and
> >>> the
> >> old metadata structure with Proj4 string degradation; GDAL < 3
> with
> >>> PROJ
> >>> = 6 must use the deprecated API and the new metadata structure.
> >>
> >>>
> >>>I could not find any sources in the web or in the announcement
> >>> post of
> >>>v1.5.8 why this condition was enforced so strictly.
> >>>Does it cause unwanted results?
> >>
> >> Yes, definitely. GDAL 3 was released as 3, not 2.5, to stress the
> >> complete
> >> break between GDAL 2 (with PROJ <= 5) and GDAL >= 3 (with PROJ >=
> >> 6)
> >> after
> >> GDAL barnraising. So:
> >>
> >> PROJ
> >> < 6 >= 6
> >> GDAL < 3 OK NO
> >> > = 3 NO OK
> >>
> >>
> >>
> >>>If so, then there is a big
Re: [R-sig-Geo] Package lwgeom (0.2-4) fails to install on Shinyapps.io with an "upgrade GEOS to 3.6.0 or later" error
The documentation at https://docs.rstudio.com/shinyapps.io/getting-started.html#deploying-applications will help you figure it out. From a quick glance it seems you can either downgrade your local version of lwgeom or work to get the system dependencies installed as instructed at https://docs.rstudio.com/shinyapps.io/getting-started.html#system-packages Best, Ista On Wed, Jun 3, 2020 at 12:00 PM El Mechry El Koudouss wrote: > > Dear all, > I am building a Shiny app that works fine on my laptop (Windows 10). > However, it fails to deploy on Shinyapps.io because the package lwgeom > (0.2-4) fails to install on Shinyapps.io. I have the sf package installed > and loaded to the library on my laptop and it links to GEOS 3.8.0. I also > have the lwgeom package installed and loaded to the library in my laptop > and it also links to GOES 3.8.0. Yes the error I get is: > error: upgrade GEOS to 3.6.0 or later > ERROR: configuration failed for package ‘lwgeom’ > The full message I get up on trying to deploy my app is pasted below. For > more information, I am using the following packages and the following shiny > functions. I am hoping someone here can point me in the right direction. > Thanks. > > library(shiny) > library(shinythemes) > library(plotly) > library(tidyverse) > library(sf) > library(leaflet) > library(tmap) > library(lubridate) > renderLeaflet() > tm_shape() > tm_polygons() > tmap_leaflet() > > Full error message is below: > Building R package: lwgeom (0.2-4) > /mnt/packages/build /mnt > * installing to library ‘/opt/R/4.0.0/lib/R/library’ > * installing *source* package ‘lwgeom’ ... > ** package ‘lwgeom’ successfully unpacked and MD5 sums checked > ** using staged installation > configure: CC: gcc > configure: CXX: g++ -std=gnu++11 > configure: pkg-config proj exists, will use it > configure: PROJ: 4.9.2 > checking for pj_init_plus in -lproj... yes > checking PROJ: epsg found and readable... yes > configure: POSTGIS_PROJ_VERSION: 49 > checking for geos-config... /usr/bin/geos-config > checking geos-config usability... yes > configure: GEOS: 3.5.1 > checking GEOS version >= 3.6.0... no > configure: error: upgrade GEOS to 3.6.0 or later > ERROR: configuration failed for package ‘lwgeom’ > * removing ‘/opt/R/4.0.0/lib/R/library/lwgeom’ > # End Task Log > # > Error: Unhandled Exception: Child Task 741259659 failed: Error building > image: Error building lwgeom (0.2-4). Build exited with non-zero status: 1 > Execution halted > > -- > El Mechry, El Koudouss (Meshry) > Graduate Research Assistant > Center for International Policy Studies > Fordham University > Department of Economics > Website: www.meshry.com > > [[alternative HTML version deleted]] > > ___ > R-sig-Geo mailing list > R-sig-Geo@r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Re: [R-sig-Geo] Package lwgeom (0.2-4) fails to install on Shinyapps.io with an "upgrade GEOS to 3.6.0 or later" error
R package lwgeom had to upgrade to a newer version of liblwgeom (now a subdirectory in the PostGIS source tree, really) because of the new PROJ versions and deprecation of the old PROJ interface; PostGIS requires the newer GEOS version. I have no control over versions of GEOS that are run on the shinyapps.io machines, and don't know which OS at which version they run. I also have no clue how one could debug this issue. One could try to patch the install file, https://github.com/rstudio/shinyapps-package-dependencies/blob/master/packages/lwgeom/install such that it installs a newer GEOS (maybe binary from another ppa, otherwise from source). On 6/3/20 6:33 PM, Rich Shepard wrote: > On Wed, 3 Jun 2020, Erin Hodgess wrote: > >> Could this possibly be due to the upgrade for GDAL and PROJ libraries, >> please? > > Erin, > > I learned a while ago that when any of proj, geos, and gdal are upgraded I > need to rebuid tools higher in that chain. If you have a new geos version > then a new gdal build is in order. > > If this does not address your issue please excuse my responding. > > Regards, > > Rich > > ___ > R-sig-Geo mailing list > R-sig-Geo@r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo -- Edzer Pebesma Institute for Geoinformatics Heisenbergstrasse 2, 48149 Muenster, Germany Phone: +49 251 8333081 pEpkey.asc Description: application/pgp-keys ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Re: [R-sig-Geo] Package lwgeom (0.2-4) fails to install on Shinyapps.io with an "upgrade GEOS to 3.6.0 or later" error
On Wed, 3 Jun 2020, Erin Hodgess wrote: Could this possibly be due to the upgrade for GDAL and PROJ libraries, please? Erin, I learned a while ago that when any of proj, geos, and gdal are upgraded I need to rebuid tools higher in that chain. If you have a new geos version then a new gdal build is in order. If this does not address your issue please excuse my responding. Regards, Rich ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Re: [R-sig-Geo] Package lwgeom (0.2-4) fails to install on Shinyapps.io with an "upgrade GEOS to 3.6.0 or later" error
Hello! Could this possibly be due to the upgrade for GDAL and PROJ libraries, please? That might be something on the Shinyapps.io side. Just a thought. Thanks, Erin On Wed, Jun 3, 2020 at 10:00 AM El Mechry El Koudouss < eelkoudo...@fordham.edu> wrote: > Dear all, > I am building a Shiny app that works fine on my laptop (Windows 10). > However, it fails to deploy on Shinyapps.io because the package lwgeom > (0.2-4) fails to install on Shinyapps.io. I have the sf package installed > and loaded to the library on my laptop and it links to GEOS 3.8.0. I also > have the lwgeom package installed and loaded to the library in my laptop > and it also links to GOES 3.8.0. Yes the error I get is: > error: upgrade GEOS to 3.6.0 or later > ERROR: configuration failed for package ‘lwgeom’ > The full message I get up on trying to deploy my app is pasted below. For > more information, I am using the following packages and the following shiny > functions. I am hoping someone here can point me in the right direction. > Thanks. > > library(shiny) > library(shinythemes) > library(plotly) > library(tidyverse) > library(sf) > library(leaflet) > library(tmap) > library(lubridate) > renderLeaflet() > tm_shape() > tm_polygons() > tmap_leaflet() > > Full error message is below: > Building R package: lwgeom (0.2-4) > /mnt/packages/build /mnt > * installing to library ‘/opt/R/4.0.0/lib/R/library’ > * installing *source* package ‘lwgeom’ ... > ** package ‘lwgeom’ successfully unpacked and MD5 sums checked > ** using staged installation > configure: CC: gcc > configure: CXX: g++ -std=gnu++11 > configure: pkg-config proj exists, will use it > configure: PROJ: 4.9.2 > checking for pj_init_plus in -lproj... yes > checking PROJ: epsg found and readable... yes > configure: POSTGIS_PROJ_VERSION: 49 > checking for geos-config... /usr/bin/geos-config > checking geos-config usability... yes > configure: GEOS: 3.5.1 > checking GEOS version >= 3.6.0... no > configure: error: upgrade GEOS to 3.6.0 or later > ERROR: configuration failed for package ‘lwgeom’ > * removing ‘/opt/R/4.0.0/lib/R/library/lwgeom’ > # End Task Log > # > Error: Unhandled Exception: Child Task 741259659 failed: Error building > image: Error building lwgeom (0.2-4). Build exited with non-zero status: 1 > Execution halted > > -- > El Mechry, El Koudouss (Meshry) > Graduate Research Assistant > Center for International Policy Studies > Fordham University > Department of Economics > Website: www.meshry.com > > [[alternative HTML version deleted]] > > ___ > R-sig-Geo mailing list > R-sig-Geo@r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > -- Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com [[alternative HTML version deleted]] ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
[R-sig-Geo] Package lwgeom (0.2-4) fails to install on Shinyapps.io with an "upgrade GEOS to 3.6.0 or later" error
Dear all, I am building a Shiny app that works fine on my laptop (Windows 10). However, it fails to deploy on Shinyapps.io because the package lwgeom (0.2-4) fails to install on Shinyapps.io. I have the sf package installed and loaded to the library on my laptop and it links to GEOS 3.8.0. I also have the lwgeom package installed and loaded to the library in my laptop and it also links to GOES 3.8.0. Yes the error I get is: error: upgrade GEOS to 3.6.0 or later ERROR: configuration failed for package ‘lwgeom’ The full message I get up on trying to deploy my app is pasted below. For more information, I am using the following packages and the following shiny functions. I am hoping someone here can point me in the right direction. Thanks. library(shiny) library(shinythemes) library(plotly) library(tidyverse) library(sf) library(leaflet) library(tmap) library(lubridate) renderLeaflet() tm_shape() tm_polygons() tmap_leaflet() Full error message is below: Building R package: lwgeom (0.2-4) /mnt/packages/build /mnt * installing to library ‘/opt/R/4.0.0/lib/R/library’ * installing *source* package ‘lwgeom’ ... ** package ‘lwgeom’ successfully unpacked and MD5 sums checked ** using staged installation configure: CC: gcc configure: CXX: g++ -std=gnu++11 configure: pkg-config proj exists, will use it configure: PROJ: 4.9.2 checking for pj_init_plus in -lproj... yes checking PROJ: epsg found and readable... yes configure: POSTGIS_PROJ_VERSION: 49 checking for geos-config... /usr/bin/geos-config checking geos-config usability... yes configure: GEOS: 3.5.1 checking GEOS version >= 3.6.0... no configure: error: upgrade GEOS to 3.6.0 or later ERROR: configuration failed for package ‘lwgeom’ * removing ‘/opt/R/4.0.0/lib/R/library/lwgeom’ # End Task Log # Error: Unhandled Exception: Child Task 741259659 failed: Error building image: Error building lwgeom (0.2-4). Build exited with non-zero status: 1 Execution halted -- El Mechry, El Koudouss (Meshry) Graduate Research Assistant Center for International Policy Studies Fordham University Department of Economics Website: www.meshry.com [[alternative HTML version deleted]] ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Re: [R-sig-Geo] rgdal: About the new gdal3 and proj >=6 condition
On Wed, 3 Jun 2020, Abdoulaye Sarr wrote:
Have a problem with needed gdal version on mac
Please be much more specific. CRAN has macOS binaries of rgdal 1.5-8. Are
you trying to install all the external software dependencies then rgdal
from source? If this is difficult, rely on the CRAN macOS binaries, even
though the PROJ and GDAL versions do not yet support WKT2 CRS
representation. If you have installed PROJ and GDAL successfully, and PROJ
< 6 && GDAL < 3, or PROJ >= 6 && GDAL >= 3, you should be OK. If you have
the pointless PROJ >= 6 && GDAL < 3, you need the 1.5-9 tarball from
R-forge, download locally and run R CMD INSTALL
--configure-args="--with-proj_api=proj_api.h" rgdal_1.5-9.tar.gz.
Please report back on specifics, or simply use CRAN binaries and report
that.
We are actively looking for ways to prevent macOS users getting trapped
into trying to install from source when such a choice is not appropriate.
We have no control over the provenance of the installed software as we
have for Windows, thanks to Jeroen's rwinlib/gdal3 collection.
Roger
On Tue, Jun 2, 2020 at 4:04 PM Robin Lovelace wrote:
Confirmed: this worked perfectly for me.
Video evidence that this is fixed:
https://asciinema.org/a/zPQFbI6Q01oqUy1HRauCjLUXY
Thanks Roger!
Robin
On Tue, Jun 2, 2020 at 4:00 PM Roger Bivand wrote:
Brian Ripley (thanks!) provided a patch for rgdal's configure.ac, and
the
R-forge build and check processes now succeed, so please try to install
either downloading
http://download.r-forge.r-project.org/src/contrib/rgdal_1.5-9.tar.gz and
installing from the command line (after running R CMD check), or
install.packages("rgdal", repos="http://R-Forge.R-project.org";).
Remember that if GDAL is < 3, and PROJ >= 6, you need the configure
argument: --configure-args=--with-proj_api=proj_api.h.
Roger
On Sun, 31 May 2020, Roger Bivand wrote:
Fresh version of rgdal rev 995 on link and R-forge, with more tweaks to
the
configure file. Please test.
Roger
On Fri, 29 May 2020, Roger Bivand wrote:
I have put a tarball, built without vignettes with GDAL 2.2.4 and
PROJ
7.0.1 that passes CMD check (with warnings for missing vignettes) on:
http://spatial.nhh.no/R/rgdal/gdal_1.5-9.tar.gz
It involves code copying to provide duplicated functions in three
settings:
PROJ < 6 & GDAL < 3
PROJ > = 6 & GDAL >= 3
PROJ > = 6 & GDAL < 3 (your homebrew case)
You need the configure argument:
--configure-args=--with-proj_api=proj_api.h.
Without the argument, you now get directed to use it.
For now I've dropped the configure tests for sqlite3, curl and tiff;
works
for me but may not work for you.
Please make the output of:
R CMD check
--install-args="--configure-args=--with-proj_api=proj_api.h"
rgdal_1.5-9.tar.gz
available ASAP. I count on an immediate response.
Roger
On Fri, 29 May 2020, Roger Bivand wrote:
On Fri, 29 May 2020, Patrick Schratz wrote:
The just released rgdal v1.5.8 requires gdal >= 3 when proj >= 6
is
present. It does not even install the package if this condition
is
not
met
but errors during linking.
Please document with the output of 00install.out from R CMD check
rgdal_1.5-8.tar.gz, and pkg-config proj --modversion, gdalinfo
--version
with system details.
Yes, PROJ >= 6 makes no sense without GDAL >= 3; GDAL 3 makes no
sense
with PROJ < 6. GDAL 3 with PROJ < 6 uses the old proj_api.h API and
the
old metadata structure with Proj4 string degradation; GDAL < 3 with
PROJ
= 6 must use the deprecated API and the new metadata structure.
I could not find any sources in the web or in the announcement
post of
v1.5.8 why this condition was enforced so strictly.
Does it cause unwanted results?
Yes, definitely. GDAL 3 was released as 3, not 2.5, to stress the
complete
break between GDAL 2 (with PROJ <= 5) and GDAL >= 3 (with PROJ >=
6)
after
GDAL barnraising. So:
PROJ
< 6 >= 6
GDAL < 3 OK NO
> = 3 NO OK
If so, then there is a big issue since the “gdal2 and proj >= 6”
combination has been used by many people in the past already.
No good precedent, just binary packagers protecting slow downstream
adaptation.
I haven’t tracked down for how long this situation was on the
market
already.
Also the {sf} package is still installable with this combination
and I
am not aware of any warnings/issues that came up due to this so
far.
rgdal is a much older package and has much more older code that
needs
this
protection. It is possible to accommodate the no-go areas, but I'd
really
value patches to R-forge, as I cannot check multiple PROJ/GDAL
version
combinations just because someone isn't up to speed.
It further causes complete breakage for people relying on the
homebrew
package manager on macOS since current versions are gdal v2.2.4
and
proj
7.0.1.
They should never have gone beyond PR
Re: [R-sig-Geo] rgdal: About the new gdal3 and proj >=6 condition
Have a problem with needed gdal version on mac
On Tue, Jun 2, 2020 at 4:04 PM Robin Lovelace wrote:
> Confirmed: this worked perfectly for me.
>
> Video evidence that this is fixed:
> https://asciinema.org/a/zPQFbI6Q01oqUy1HRauCjLUXY
>
> Thanks Roger!
>
> Robin
>
> On Tue, Jun 2, 2020 at 4:00 PM Roger Bivand wrote:
>
> > Brian Ripley (thanks!) provided a patch for rgdal's configure.ac, and
> the
> > R-forge build and check processes now succeed, so please try to install
> > either downloading
> > http://download.r-forge.r-project.org/src/contrib/rgdal_1.5-9.tar.gz and
> > installing from the command line (after running R CMD check), or
> > install.packages("rgdal", repos="http://R-Forge.R-project.org";).
> >
> > Remember that if GDAL is < 3, and PROJ >= 6, you need the configure
> > argument: --configure-args=--with-proj_api=proj_api.h.
> >
> > Roger
> >
> > On Sun, 31 May 2020, Roger Bivand wrote:
> >
> > > Fresh version of rgdal rev 995 on link and R-forge, with more tweaks to
> > the
> > > configure file. Please test.
> > >
> > > Roger
> > >
> > > On Fri, 29 May 2020, Roger Bivand wrote:
> > >
> > >> I have put a tarball, built without vignettes with GDAL 2.2.4 and
> PROJ
> > >> 7.0.1 that passes CMD check (with warnings for missing vignettes) on:
> > >>
> > >> http://spatial.nhh.no/R/rgdal/gdal_1.5-9.tar.gz
> > >>
> > >> It involves code copying to provide duplicated functions in three
> > >> settings:
> > >>
> > >> PROJ < 6 & GDAL < 3
> > >> PROJ > = 6 & GDAL >= 3
> > >> PROJ > = 6 & GDAL < 3 (your homebrew case)
> > >>
> > >> You need the configure argument:
> > >> --configure-args=--with-proj_api=proj_api.h.
> > >> Without the argument, you now get directed to use it.
> > >>
> > >> For now I've dropped the configure tests for sqlite3, curl and tiff;
> > works
> > >> for me but may not work for you.
> > >>
> > >> Please make the output of:
> > >>
> > >> R CMD check
> > --install-args="--configure-args=--with-proj_api=proj_api.h"
> > >> rgdal_1.5-9.tar.gz
> > >>
> > >> available ASAP. I count on an immediate response.
> > >>
> > >> Roger
> > >>
> > >> On Fri, 29 May 2020, Roger Bivand wrote:
> > >>
> > >>> On Fri, 29 May 2020, Patrick Schratz wrote:
> > >>>
> > The just released rgdal v1.5.8 requires gdal >= 3 when proj >= 6
> is
> > present. It does not even install the package if this condition
> is
> > not
> > met
> > but errors during linking.
> > >>>
> > >>> Please document with the output of 00install.out from R CMD check
> > >>> rgdal_1.5-8.tar.gz, and pkg-config proj --modversion, gdalinfo
> > --version
> > >>> with system details.
> > >>>
> > >>> Yes, PROJ >= 6 makes no sense without GDAL >= 3; GDAL 3 makes no
> > sense
> > >>> with PROJ < 6. GDAL 3 with PROJ < 6 uses the old proj_api.h API and
> > the
> > >>> old metadata structure with Proj4 string degradation; GDAL < 3 with
> > PROJ
> > = 6 must use the deprecated API and the new metadata structure.
> > >>>
> >
> > I could not find any sources in the web or in the announcement
> > post of
> > v1.5.8 why this condition was enforced so strictly.
> > Does it cause unwanted results?
> > >>>
> > >>> Yes, definitely. GDAL 3 was released as 3, not 2.5, to stress the
> > >>> complete
> > >>> break between GDAL 2 (with PROJ <= 5) and GDAL >= 3 (with PROJ >=
> 6)
> > >>> after
> > >>> GDAL barnraising. So:
> > >>>
> > >>> PROJ
> > >>> < 6 >= 6
> > >>> GDAL < 3 OK NO
> > >>>> = 3 NO OK
> > >>>
> > >>>
> > >>>
> > If so, then there is a big issue since the “gdal2 and proj >= 6”
> > combination has been used by many people in the past already.
> > >>>
> > >>> No good precedent, just binary packagers protecting slow downstream
> > >>> adaptation.
> > >>>
> > I haven’t tracked down for how long this situation was on the
> > market
> > already.
> > Also the {sf} package is still installable with this combination
> > and I
> > am not aware of any warnings/issues that came up due to this so
> > far.
> >
> > >>>
> > >>> rgdal is a much older package and has much more older code that
> needs
> > >>> this
> > >>> protection. It is possible to accommodate the no-go areas, but I'd
> > >>> really
> > >>> value patches to R-forge, as I cannot check multiple PROJ/GDAL
> > version
> > >>> combinations just because someone isn't up to speed.
> > >>>
> > It further causes complete breakage for people relying on the
> > homebrew
> > package manager on macOS since current versions are gdal v2.2.4
> and
> > proj
> > 7.0.1.
> > >>>
> > >>> They should never have gone beyond PROJ 5 if they are stuck on
> GDAL.
> > >>> PROJ
> > >>> 7 is a very different animal.
> > >>>
> > The update to gdal3 is blocked since months due to an
> > incompatibility
> > with `liblas` (https://github.com/libLAS/libLAS/issu
Re: [R-sig-Geo] How to efficiently generate data of neighboring points
On Wed, 3 Jun 2020, Lom Navanyo wrote:
I had the errors with rtree using R 3.6.3. I have since changed to R 4.0.0
but I got the same error.
And yes, for Roger's example, I have the objects wd1, ... wd4, all with
length 101. I think my difficulty is my inability to output the list
detailing the point IDs t50_fid.
library(spData)
library(sf)
projdata<-st_transform(nz_height, 32759)
pts <- st_coordinates(projdata)
library(spdep)
bufferR <- c(402.336, 1609.34, 3218.69, 4828.03, 6437.38)
bds <- c(0, bufferR)
wd1 <- dnearneigh(pts, bds[1], bds[2])
wd2 <- dnearneigh(pts, bds[2], bds[3])
wd3 <- dnearneigh(pts, bds[3], bds[4])
wd4 <- dnearneigh(pts, bds[4], bds[5])
sn_band1 <- listw2sn(nb2listw(wd1, style="B", zero.policy=TRUE))
sn_band1$band <- paste(attr(wd1, "distances"), collapse="-")
sn_band2 <- listw2sn(nb2listw(wd2, style="B", zero.policy=TRUE))
sn_band2$band <- paste(attr(wd2, "distances"), collapse="-")
sn_band3 <- listw2sn(nb2listw(wd3, style="B", zero.policy=TRUE))
sn_band3$band <- paste(attr(wd3, "distances"), collapse="-")
sn_band4 <- listw2sn(nb2listw(wd4, style="B", zero.policy=TRUE))
sn_band4$band <- paste(attr(wd4, "distances"), collapse="-")
data_out <- do.call("rbind", list(sn_band1, sn_band2, sn_band3, sn_band4))
class(data_out) <- "data.frame"
table(data_out$band)
data_out$ID_from <- projdata$t50_fid[data_out$from]
data_out$ID_to <- projdata$t50_fid[data_out$to]
data_out$elev_from <- projdata$elevation[data_out$from]
data_out$elev_to <- projdata$elevation[data_out$to]
str(data_out)
The "spatial.neighbour" representation was that used in the S-Plus
SpatialStats module, with "from" and "to" columns, and here drops
no-neighbour cases gracefully. So listw2sn() comes in useful
for creating the output, and from there, just look-up in the
input data.frame. Observations here cannot be their own neighbours.
It would be relevant to know why you need these, are you looking at
variogram clouds?
Hope this clarifies,
Roger
-
Lom
On Tue, Jun 2, 2020 at 8:02 PM Kent Johnson wrote:
Roger's example works for me and gives a list of length 101. I did have
some issues that were resolved by updating packages. I'm using R 3.6.3 on
macOS 10.15.4. I also use rtree successfully on Windows 10 with R 3.6.3.
Kent
On Tue, Jun 2, 2020 at 12:29 PM Roger Bivand wrote:
On Tue, 2 Jun 2020, Kent Johnson wrote:
rtree uses Euclidean distance so the points should be in a coordinate
system where this makes sense at least as a reasonable approximation.
I tried the original example:
remotes::install_github("hunzikp/rtree")
library(spData)
library(sf)
projdata<-st_transform(nz_height, 32759)
library(rtree)
pts <- st_coordinates(projdata)
rt <- RTree(st_coordinates(projdata))
bufferR <- c(402.336, 1609.34, 3218.69, 4828.03, 6437.38)
wd1 <- withinDistance(rt, pts, bufferR[1])
but unfortunately failed (maybe newer Boost headers than yours?):
Error in UseMethod("withinDistance", rTree) :
no applicable method for 'withinDistance' applied to an object of
class
"c('list', 'RTree')"
Kent
On Tue, Jun 2, 2020 at 9:59 AM Roger Bivand
wrote:
On Tue, 2 Jun 2020, Kent Johnson wrote:
Date: Tue, 2 Jun 2020 02:44:17 -0500
From: Lom Navanyo
To: r-sig-geo@r-project.org
Subject: [R-sig-Geo] How to efficiently generate data of neighboring
points within specified radii (distances) for each point in a
given
points data set.
Hello,
I have data set of about 3400 location points with which I am trying
to
generate data of each point and their neighbors within defined radii
(eg,
0.25, 1, and 3 miles).
The rtree package is very fast and memory-efficient for
within-distance
calculations.
https://github.com/hunzikp/rtree
Thanks! Does this also apply when the input points are in geographical
coordinates?
Roger
Kent Johnson
Cambridge, MA
[[alternative HTML version deleted]]
___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: roger.biv...@nhh.no
https://orcid.org/-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0J&hl=en
--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: roger.biv...@nhh.no
https://orcid.org/-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0J&hl=en
--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: roger.biv...@nhh.no
https://orcid.org/-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0J&hl=en
___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
