Re: [R-sig-Geo] Maximum sparsity for spatial regression

[Josiah Parry]

Yes! This is perfect. Thank you so much.

On Mon, May 13, 2024 at 12:11 Roger Bivand  wrote:

> Is Tony Smith's "Estimation Bias in Spatial Models with Strongly Connected
> Weight Matrices" at https://doi.org/10./j.1538-4632.2009.00758.x
> helpful?
>
> Roger
>
> --
> Roger Bivand
> Emeritus Professor
> Norwegian School of Economics
> Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
> roger.biv...@nhh.no
>
> ________
> From: R-sig-Geo  on behalf of Josiah
> Parry 
> Sent: 13 May 2024 17:12
> To: r-sig-Geo@r-project.org
> Subject: [R-sig-Geo] Maximum sparsity for spatial regression
>
> As I'm reading through Modern Spatial Econometrics in Practice, we assume
> the spatial weights matrix to be sparse. At one point they note that the
> contiguity matrix  for the US counties is 0.18% non-zero. But what %
> non-zero is too dense?
>
> I am wondering if there is any research or papers that document what a
> recommended upper bound of sparsity should be for one of these models? Is
> 10% non-zero too much or sufficient? I suspect the answer is, like most
> things, "it depends."
>
> But, thinking of a situation where someone might use a distance band to
> specify neighbors they might create a bandwidth that can encompass 50% or
> more of points if using max(knn=1) to specify the distance. I suspect using
> a kernel or IDW could reduce the weights close to zero making the impact
> minimal.
>
> Nonetheless, I'm curious if others have thought about this or written about
> it!
>
> Thanks,
>
> Josiah
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[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] Maximum sparsity for spatial regression

[Josiah Parry]

As I'm reading through Modern Spatial Econometrics in Practice, we assume
the spatial weights matrix to be sparse. At one point they note that the
contiguity matrix  for the US counties is 0.18% non-zero. But what %
non-zero is too dense?

I am wondering if there is any research or papers that document what a
recommended upper bound of sparsity should be for one of these models? Is
10% non-zero too much or sufficient? I suspect the answer is, like most
things, "it depends."

But, thinking of a situation where someone might use a distance band to
specify neighbors they might create a bandwidth that can encompass 50% or
more of points if using max(knn=1) to specify the distance. I suspect using
a kernel or IDW could reduce the weights close to zero making the impact
minimal.

Nonetheless, I'm curious if others have thought about this or written about
it!

Thanks,

Josiah

[[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] Learning Resources Spatial Regression Models from the ground up

[Josiah Parry]

Thank you, Roger!

On Wed, Apr 24, 2024 at 12:25 PM Roger Bivand  wrote:

> Please also consider:
>
> @book{lesage+pace:09,
>author={James P. {LeSage} and R. Kelley Pace},
>title={Introduction to Spatial Econometrics},
>year={2009},
>publisher={Chapman and Hall/CRC},
>address={Boca Raton FL}
> }
>
> which provides the underpinnings to Golgher & Voss just suggested by
> Dexter. A good deal has been going on recently, both about spillovers, and
> very recent work by Bera & Koley on Rao score tests (aka Lagrange
> multiplier tests). I have some notes but no recording from recent lectures,
> so the notes are skeletal at best:
> https://rsbivand.github.io/PG_AGII_2sem/. In SDSr, my focus was on
> pointing up the topics areas where spatial econometrics could very well
> benefit from the much larger community in disease mapping and in ecology.
> In both of these broad communities, the dependent variable is often
> discrete, and both of these draw lots of maps. I haven't yet got Modelling
> Spatial and Spatial-Temporal Data: A Bayesian Approach by Haining & Li, and
> expect it to be useful.
>
> Hope this helps,
>
> Roger
>
> --
> Roger Bivand
> Emeritus Professor
> Norwegian School of Economics
> Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
> roger.biv...@nhh.no
>
> 
> From: R-sig-Geo  on behalf of Josiah
> Parry 
> Sent: 24 April 2024 17:58
> To: Christopher W. Ryan
> Cc: r-sig-geo@r-project.org
> Subject: Re: [R-sig-Geo]  Learning Resources Spatial Regression Models
> from the ground up
>
> [You don't often get email from josiah.pa...@gmail.com. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Thank you, Chris! I can take a look at the first resource. At the moment my
> interest is specifically in spatial econometric models and less so about
> point patterns (for the time being).
>
> On Wed, Apr 24, 2024 at 11:51 AM Christopher W. Ryan  >
> wrote:
>
> > Josiah--
> >
> > I've found the following very helpful over the years:
> >
> > Geographic Information Analysis, by David O'Sullivan and David Unwin
> >
> > Spatial Point Patterns, by Adrian Baddeley, Ege Rubak, and Rolf Turner
> >
> > Applied Spatial Data Analysis with R, by Roger Bivand, Edzer Pebesma,
> > and Virgilio Gomez-Rubio
> >
> > Statistical Analysis of Spatial and Spatio-Temporal Point Patterns
> >
> > The last 3 are, as the titles imply, focused specifically on spatial
> > point patterns. The first is a bit more general, including methods for
> > areal data.
> >
> > I listed them in increasing order (in my opinion) of mathemtical
> > complexity.
> >
> > --Chris Ryan
> >
> > In
> > Josiah Parry wrote:
> > > Hey folks,
> > >
> > > I'm hoping to build up my knowledge around spatial regression
> techniques
> > > from the ground up—e.g. I'm not interested in R-INLA or other
> > exceptionally
> > > complex techniques.
> > >
> > > I'm hoping this listserv has some recommendations for what readings /
> > > models I should prioritize learning about in, possibly, an opinionated
> > > order.
> > >
> > > At the moment I've purchased "Modern Spatial Econometrics in Practice"
> by
> > > Luc Anselin and Sergio Rey and will try to work through that. But if
> > there
> > > are additional resources that folks recommend that are friendly for the
> > > not-so-math-inclined, I'd love to have a look at them!
> > >
> > > The Spatial Regression section of the R-spatial book (
> > > https://r-spatial.org/book/16-SpatialRegression.html) is good but with
> > less
> > > handholding than I might need.
> > >
> > >   [[alternative HTML version deleted]]
> > >
> > > ___
> > > R-sig-Geo mailing list
> > > R-sig-Geo@r-project.org
> > > https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> > >
> >
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[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] Learning Resources Spatial Regression Models from the ground up

[Josiah Parry]

Thank you, Chris! I can take a look at the first resource. At the moment my
interest is specifically in spatial econometric models and less so about
point patterns (for the time being).

On Wed, Apr 24, 2024 at 11:51 AM Christopher W. Ryan 
wrote:

> Josiah--
>
> I've found the following very helpful over the years:
>
> Geographic Information Analysis, by David O'Sullivan and David Unwin
>
> Spatial Point Patterns, by Adrian Baddeley, Ege Rubak, and Rolf Turner
>
> Applied Spatial Data Analysis with R, by Roger Bivand, Edzer Pebesma,
> and Virgilio Gomez-Rubio
>
> Statistical Analysis of Spatial and Spatio-Temporal Point Patterns
>
> The last 3 are, as the titles imply, focused specifically on spatial
> point patterns. The first is a bit more general, including methods for
> areal data.
>
> I listed them in increasing order (in my opinion) of mathemtical
> complexity.
>
> --Chris Ryan
>
> In
> Josiah Parry wrote:
> > Hey folks,
> >
> > I'm hoping to build up my knowledge around spatial regression techniques
> > from the ground up—e.g. I'm not interested in R-INLA or other
> exceptionally
> > complex techniques.
> >
> > I'm hoping this listserv has some recommendations for what readings /
> > models I should prioritize learning about in, possibly, an opinionated
> > order.
> >
> > At the moment I've purchased "Modern Spatial Econometrics in Practice" by
> > Luc Anselin and Sergio Rey and will try to work through that. But if
> there
> > are additional resources that folks recommend that are friendly for the
> > not-so-math-inclined, I'd love to have a look at them!
> >
> > The Spatial Regression section of the R-spatial book (
> > https://r-spatial.org/book/16-SpatialRegression.html) is good but with
> less
> > handholding than I might need.
> >
> >   [[alternative HTML version deleted]]
> >
> > ___
> > R-sig-Geo mailing list
> > R-sig-Geo@r-project.org
> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >
>

[[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] Learning Resources Spatial Regression Models from the ground up

[Josiah Parry]

Hey folks,

I'm hoping to build up my knowledge around spatial regression techniques
from the ground up—e.g. I'm not interested in R-INLA or other exceptionally
complex techniques.

I'm hoping this listserv has some recommendations for what readings /
models I should prioritize learning about in, possibly, an opinionated
order.

At the moment I've purchased "Modern Spatial Econometrics in Practice" by
Luc Anselin and Sergio Rey and will try to work through that. But if there
are additional resources that folks recommend that are friendly for the
not-so-math-inclined, I'd love to have a look at them!

The Spatial Regression section of the R-spatial book (
https://r-spatial.org/book/16-SpatialRegression.html) is good but with less
handholding than I might need.

[[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] Attempt to set index in SET_STRING_ELT

[Josiah Parry]

It sounds as if you might be using integers to index some vector. Integers
in R are 32 bit which are limited to a maximum value of 214783647 which is
actually reserved for NA values. Anything larger than that will overflow.

On Mon, Feb 26, 2024 at 19:41 Jochen Albrecht 
wrote:

> I am getting the same kind of error working with stplanr (using function
> route_dodgr) as well as osmdata (using function osmdata_sf), which lets me
> assume that the latter is the culprit. The error is "attempt to set index
> 2786142150/2786142150 in SET_STRING_ELT". The index number is a little
> different, although in both instances, we are talking about a value in the
> 2 billion range.
> The error message is not terribly illuminating. Does anyone know what is
> causing it, and even better, how to work around it?
>
> In the case of the osmdata function, I tried to download a road dataset for
> a four-county region in the (SanFran) Bay Area. I have previously
> successfully downloaded the OSM road network for a larger extent of the
> same geography (albeit directly rather than using the osmdata package).
>
> Dr. Jochen Albrecht, GISP (he/him/his)
>
> Professor for Computational and Theoretical Geography
>
> Department of Geography and Environmental Science
> 
>
> Hunter College CUNY
>
> 695 Park Avenue
>
> New York, NY 10065 Just published: GIS and Housing: Principles and
> Practices
> 
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[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] New maintainer needed {sfdep}

[Josiah Parry]

Thank you very much Roger! And thank you to the handful of folks who have
reached out.

For further context, I am happy to help out providing guidance and pull
request reviews but I am not able to actively contribute. I won’t leave you
all on your own! 

On Mon, Feb 5, 2024 at 14:03 Roger Bivand  wrote:

> I would encourage someone committed to raising their package maintenance
> skills to take over from Josiah.
>
> I've created a PR https://github.com/JosiahParry/sfdep/pull/43 bringing
> the github repo into submittable shape, so if Josiah could check my updates
> and if OK submit, the person taking on maintenance would not have an
> immediate fire to extinguish - the PR contains check logs for R released
> and development passing OK now.
>
> So if you (single, plural) feel curious, please give sfdep consideration.
> Josiah does have plenty of other R-relevant work in his current role, and
> does have a conflict of interest, as he said.
>
> Roger
>
> --
> Roger Bivand
> Emeritus Professor
> Norwegian School of Economics
> Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
> roger.biv...@nhh.no
>
> ________
> From: R-sig-Geo  on behalf of Josiah
> Parry 
> Sent: 04 February 2024 23:30
> To: r-sig-Geo@r-project.org
> Subject: [R-sig-Geo] New maintainer needed {sfdep}
>
> [You don't often get email from josiah.pa...@gmail.com. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> The R package {sfdep} which is a humble attempt at a "tidy" interface to
> the mighty {spdep} needs a new maintainer. It is currently scheduled to be
> archived on Feb 19th due to some notes
> https://cran.r-project.org/web/checks/check_results_sfdep.html.
>
> I am no longer able to maintain the package due to a conflict of interest.
> I would greatly appreciate it if someone else would be willing to take over
> the package.
>
> If you are interested, please do let me know!
>
> Thank you,
>
> Josiah
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[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] New maintainer needed {sfdep}

[Josiah Parry]

The R package {sfdep} which is a humble attempt at a "tidy" interface to
the mighty {spdep} needs a new maintainer. It is currently scheduled to be
archived on Feb 19th due to some notes
https://cran.r-project.org/web/checks/check_results_sfdep.html.

I am no longer able to maintain the package due to a conflict of interest.
I would greatly appreciate it if someone else would be willing to take over
the package.

If you are interested, please do let me know!

Thank you,

Josiah

[[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] spdep: new zero.policy attribute

[Josiah Parry]

My take is generally that less is more. In the case of an isolated node, I
think the best thing to do is to return NA rather than 0. For example
consider administrative boundaries where the lagged variable is median
household income. If we returned a 0 in that case, we'd likely be
introducing quite the outlier!

My preference would be to _always_ default to NA lagged values when no
neighbors are present. Additionally, it would be quite nice to instruct
users on how to impute these values with other lagged variables. Say we
have an isolated node, but we don't want an NA value. We can impute that
missing value with the spatial lag of the variable using a different
neighborhood construction—e.g. using KNN with k = 3 to *ensure* that the
node always has values to lag.

Here is an example gist imputing k=3 lag
https://gist.github.com/JosiahParry/eb7878fc375fb931ddd6675a2c591a2b

Another option could be to use the focal feature's value *as* the lag
itself. If a location has no neighborhood could we argue that the location *is
*its own neighborhood?

I'm not too familiar with the models to comment on them, though. I do see
this more as a pre-processing / data imputation issue. I suspect that's
more of a machine learning paradigm though!


On Sun, Nov 5, 2023 at 10:31 AM Roger Bivand  wrote:

> And a question: in nb2listw() and similar functions creating spatial
> weights listw objects, would it be sensible to guess that the presence of
> no-neighbour observations in the input nb neighbour implies the choice of a
> spatially lagged value of zero (zero.policy=TRUE), lx = Wx, rather than NA
> (zero.policy=FALSE)?
>
> That is, use by default zero.policy=any(card(nb) == 0L) rather than
> zero.policy=NULL and look in the spdep option set by default on package
> load to FALSE but settable by the user?
>
> Would this be taking trying to be helpful too far, given that the analyst
> is creating the neighbour object and presumably should take responsibility
> for choices made?
>
> Context: polygons not sharing boundaries with other polygons do exist
> legitimately in data sources, but setting spatially lagged values to zero
> for those polygons is quite an invasive imputation. It may be better to
> oblige the user to make the choice when the spatial weights listw object is
> created.
>
> Little is known about the problem, for a recent treatment for CAR models
> see: https://arxiv.org/abs/1705.04854, published as
> https://doi.org/10.1016/j.sste.2018.04.002, where: "The specification of
> a CAR model on a disconnected graph is undefined ... [t]here are
> essentially two types of disconnected graphs: first, a graph containing an
> island (a singleton node with no neighbours), second, a graph split in
> different sub-graphs (each of them being a connected graph)".
>
> This question concerns the former, singleton, case, but adding sub-graph
> counts if greater than unity to summary.nb and print.nb address the second
> . Very possibly, functions creating nb neighbour objects should themselves
> report that an output object (graph) is not connected, bigDM CARBayes
> CARBayesST geostan spatialreg stampr do call spdep::n.comp.nb themselves to
> check the subgraph count.
>
> Interested in feedback,
>
> Roger
>
> --
> Roger Bivand
> Emeritus Professor
> Norwegian School of Economics
> Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
> roger.biv...@nhh.no
>
> 
> From: R-sig-Geo  on behalf of Roger
> Bivand 
> Sent: 04 November 2023 18:53
> To: r-sig-geo@r-project.org
> Subject: [R-sig-Geo] spdep: new zero.policy attribute
>
> In forthcoming spdep 1.3-1, spatial weight listw objects get a new
> zero.policy attribute. The attribute is added as objects are created to
> record the status of the zero.policy argument in the function creating the
> object, see:
> https://github.com/r-spatial/spdep/commit/e159de922c61713529a4075b0dfc2966eb8f9ad6
> .
>
> Reverse dependency checks only show problems from over-eager unit testing
> in SpatialFeatureExperiment, a Bioconductor package, but other workflows
> may be impacted. The new attribute is used in tests for spatial
> autocorrelation to set the zero.policy argument in those tests (the
> arguments were zero.policy=NULL, are now zero.policy=attr(listw,
> "zero.policy") where listw is the spatial weights object argument to the
> test function.
>
> This will be extended to spatialreg and friends if nobody reports negative
> impacts here soon. I'll wait before releasing 1.3-1 for a few days to see
> if any feedback is forthcoming.
>
> Hope this long-overdue change is helpful,
>
> Roger
>
> --
> Roger Bivand
> Emeritus Professor
> Norwegian School of Economics
> Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
> roger.biv...@nhh.no
> ___
> 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
> 

Re: [R-sig-Geo] maptools, rgdal, rgeos and rgrass7 retiring Monday, October 16

[Josiah Parry]

Congratulations and thank you so much for your hard work here!

On Mon, Oct 16, 2023 at 4:53 AM Roger Bivand  wrote:

> As previously announced, maptools, rgdal, rgeos and rgrass7 have been
> archived by CRAN at my request. Some turbulence may be expected as about
> 80 packages with remaining strong dependencies on the archived packages
> also are archived. I'm very grateful to many maintainers who have
> responded to requests to update in time.
>
> Going forward, sp 2.1-1 will be submitted shortly removing on-load
> messages, and about 70 non-updated packages with remaining weak
> dependencies on the archived packages will be warned to update.
>
> Any issues arising from the evolution process should be reported here or
> at https://github.com/r-spatial/evolution/issues.
>
> Roger
>
> On Tue, 3 Oct 2023, Roger Bivand wrote:
>
> > The legacy R spatial infrastructure packages maptools, rgdal and rgeos
> > will be archived by CRAN on Monday, October 16, 2023; rgrass7 has
> > already been replaced by rgrass and will be archived with the retiring
> > packages.
> >
> > The choice of date matches the previously announced archiving during
> > October 2023, and the specific date matches the release schedule of
> > Bioconductor 3.18 (some Bioconductor packages depend on retiring
> > packages).
> >
> > sp_2.1-0 was published October 2, 2023, dropping all dependencies on the
> > retiring packages. sp will continue to be available and maintained, but
> > not developed further. Users of sp classes may continue to make use of
> > them, but will have to use sf or terra to read, write or manipulate
> > objects with coercion (for a guide to coercion, see
> > https://cran.r-project.org/web/packages/rgrass/vignettes/coerce.html).
> >
> > Information about the evolution project may be found in reports and
> > resources at
> > https://r-spatial.github.io/evolution/;
> > a recent blog by Jakub Nowosad may also be useful as an overview of what
> > has been going on:
> > https://geocompx.org/post/2023/rgdal-retirement/.
> > For more detail, see
> > https://r-spatial.github.io/evolution/ogh23_bivand.html
> > and a video recording of this presentation
> > https://av.tib.eu/media/63141
> > (August 28).
> >
> > All directly affected package maintainers have been alerted to the
> > impending changes, some in December 2022, most others in March-April
> > 2023. Many have already updated their packages on CRAN - thank you for
> > your understanding! The remainder received github issue comments and
> > email reminders in the last ten days, and will receive final notices to
> > update by October 9.
> >
> > On R-universe, builds of packages archived on CRAN are dropped
> > automatically
> > (https://github.com/r-universe-org/help/issues/286).
> > Read-only github mirrors of archived packages will remain available in
> > principle while github exists
> > (https://github.com/r-hub/rhub/issues/568),
> > for example
> > https://github.com/cran/rgdal.
> > Other binary builds (Debian, Fedora, Ubuntu) have been alerted; support
> > at Anaconda has been alerted.
> >
> > On CRAN, the retired packages will continue to be available as source
> > packages on
> > https://cran.r-project.org/src/contrib/Archive.
> > maptools, rgdal and rgeos also retain their R-forge repositories, which
> > may be used to retrieve functions for adding to other packages.
> >
> > A snapshot of Windows and macOS binary packages may be found on
> > https://github.com/r-spatial/evolution/tree/main/backstore.
> >
> > Please raise questions by replying to this post, or as issues on
> > https://github.com/r-spatial/evolution.
> >
> >
> > --
> > Roger Bivand
> > Emeritus Professor
> > Norwegian School of Economics
> > Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
> > roger.biv...@nhh.no
> > ___
> > R-sig-Geo mailing list
> > R-sig-Geo@r-project.org
> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >
>
> --
> Roger Bivand
> Emeritus Professor
> Department of Economics, Norwegian School of Economics,
> Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway.
> e-mail: roger.biv...@nhh.no
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[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] Using duckdb spatial module from R (with sf)?

[Josiah Parry]

Quick note on the contains: a polygon has 5 points! The first has to be the
same as the last. And they shuold be going in Counter clock wise order if
memory serves ! :)

On Tue, Aug 15, 2023 at 8:34 PM Carl Boettiger  wrote:

> Hi list,
>
> One more go at this and I'll stop for other ideas.  Below is a
> slightly modified example using dbplyr::sql_render() to construct the
> query, which works and to me feels a little cleaner, though maybe is
> ill-advised.  Then I try to construct a spatial filter (for points in
> a polygon) this way with ST_Contains, but my effort comes back empty.
> Not sure where I went wrong.  Any ideas?
>
>
> ## boilerplate setup
> library(duckdb)
> conn <- DBI::dbConnect(duckdb::duckdb())
> status <- DBI::dbExecute(conn, "INSTALL 'spatial';")
> status <- DBI::dbExecute(conn, "LOAD 'spatial';")
> test <- data.frame(site = letters[1:10], latitude = 1:10, longitude = 1:10)
> DBI::dbWriteTable(conn, "test", test)
>
> ## Here we go, works!
> sql <- tbl(con, "test") |>
>   mutate(geom = ST_AsHEXWKB(ST_Point(longitude, latitude))) |>
>   dbplyr::sql_render()
> ex <- st_read(conn, query=sql, geometry_column = "geom", EWKB=FALSE)
> ex
>
> ## a trivial search polygon to filter:
> p2 <- rbind(c(1,1), c(1,2), c(2,2), c(1,1))
> pol <-st_polygon(list(p2))
> txt <- st_as_text(pol)
>
> ## Can we use this to filter duckdb?
> sql <- tbl(conn, "test") |>
>   mutate(geometry = ST_Point(longitude, latitude),
>  geom = ST_AsHEXWKB(geometry)) |>
>   filter(ST_Contains(geometry, ST_GeomFromText({txt}))) |>
>   dbplyr::sql_render()
> sql
> ex <- st_read(conn, query=sql, geometry_column = "geom", EWKB=FALSE)
> ex
> ## oh no! our result comes back empty?  did I need CRS on this?  Or do
> I missunderstand "ST_Contains()"?
>
> ## Here's what the desired result would be from pure sf:
> sf <- st_as_sf(test, coords = c(3,2))
> filter <- st_as_sf(tibble(sites = "A", geometry = list(pol)))
> sf |> st_filter(filter)
>
>
>
>
> ---
> Carl Boettiger
> http://carlboettiger.info/
>
> On Tue, Aug 15, 2023 at 4:42 PM Carl Boettiger  wrote:
> >
> > Ah ha.  if we ask duckdb to coerce it's geometry format to hex, it
> > appears sf can understand it just fine!
> >
> > replacing the above query with the following we are good to go.
> >
> >
> >
> > query <- paste(
> >   'SELECT *, ST_AsHEXWKB(ST_Point(longitude, latitude)) AS geom',
> >   'FROM "test"'
> > )
> > ex <- st_read(con, query=query, geometry_column = "geom", EWKB=FALSE)
> > ex
> >
> >
> > I'll experiment further.  I'm terrible at SQL, and to my eyes it looks
> > needlessly verbose.  I'm keen to understand how I can better leverage
> > sf's notation to compose the sql queries to duckdb  but it seems
> > to work!   I'm also still trying to determine if duckdb is using EWKB
> > or vanilla WKB
> >
> > ---
> > Carl Boettiger
> > http://carlboettiger.info/
> >
> > On Tue, Aug 15, 2023 at 4:02 PM Carl Boettiger 
> wrote:
> > >
> > > Hi folks,
> > >
> > >
> > > I'm curious if anyone has explored the relatively new spatial
> > > extension in duckdb (https://duckdb.org/docs/extensions/spatial.html)
> > > or has any pointers/tutorials regarding its use from R?
> > >
> > > Consider the following minimal example that seeks to use the sf
> > > library to speak to duckdb:
> > >
> > >   library(duckdb)
> > >   library(sf)
> > >   conn <- DBI::dbConnect(duckdb::duckdb())
> > >   status <- DBI::dbExecute(conn, "INSTALL 'spatial';")
> > >   status <- DBI::dbExecute(conn, "LOAD 'spatial';")
> > >
> > >   test <- data.frame(site = letters[1:10], latitude = 1:10, longitude
> = 1:10)
> > >   DBI::dbWriteTable(conn, "test", test)
> > >
> > > # Ok, let's try and make a geometry column
> > >   query <- paste(
> > > 'SELECT *, ST_Point(longitude, latitude) AS geom',
> > > 'FROM "test"'
> > >   )
> > >
> > >   ex <- st_read(con, query=query, geometry_column = "geom")
> > >   ## error: reading wkb type 0 is not supported
> > >
> > >
> > >   ex <- st_read(con, query=query, geometry_column = "geom", EWKB =
> FALSE)
> > >   ## prints: wkbType: 1572864
> > >   ## Error in CPL_read_wkb(x, EWKB, spatialite) : unsupported wkbType
> > > dim in switch
> > >
> > >  We seem to get closer than I might have hoped (sf doesn't just insist
> > > that conn isn't postgresgis), but is getting stuck on the encoding of
> > > the wkb.  Is this something we can work around?  The queries seem to
> > > run successfully, I just seem to be getting some unsupported ecoding
> > > of the WKB geometry column
> > >
> > > ---
> > > Carl Boettiger
> > > http://carlboettiger.info/
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[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] Using duckdb spatial module from R (with sf)?

[Josiah Parry]

Hey Carl, this is super cool! Is there a way to get the query result as wkb
and read the wkb using {wk}? That’s where I might start—validating the wkb
output :)

On Tue, Aug 15, 2023 at 19:02 Carl Boettiger  wrote:

> Hi folks,
>
>
> I'm curious if anyone has explored the relatively new spatial
> extension in duckdb (https://duckdb.org/docs/extensions/spatial.html)
> or has any pointers/tutorials regarding its use from R?
>
> Consider the following minimal example that seeks to use the sf
> library to speak to duckdb:
>
>   library(duckdb)
>   library(sf)
>   conn <- DBI::dbConnect(duckdb::duckdb())
>   status <- DBI::dbExecute(conn, "INSTALL 'spatial';")
>   status <- DBI::dbExecute(conn, "LOAD 'spatial';")
>
>   test <- data.frame(site = letters[1:10], latitude = 1:10, longitude =
> 1:10)
>   DBI::dbWriteTable(conn, "test", test)
>
> # Ok, let's try and make a geometry column
>   query <- paste(
> 'SELECT *, ST_Point(longitude, latitude) AS geom',
> 'FROM "test"'
>   )
>
>   ex <- st_read(con, query=query, geometry_column = "geom")
>   ## error: reading wkb type 0 is not supported
>
>
>   ex <- st_read(con, query=query, geometry_column = "geom", EWKB = FALSE)
>   ## prints: wkbType: 1572864
>   ## Error in CPL_read_wkb(x, EWKB, spatialite) : unsupported wkbType
> dim in switch
>
>  We seem to get closer than I might have hoped (sf doesn't just insist
> that conn isn't postgresgis), but is getting stuck on the encoding of
> the wkb.  Is this something we can work around?  The queries seem to
> run successfully, I just seem to be getting some unsupported ecoding
> of the WKB geometry column
>
> ---
> Carl Boettiger
> http://carlboettiger.info/
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[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] Calculating median age for a group of US census blocks?

[Josiah Parry]

Hey Kevin, I don't think you're going to be able to get individual level
data from the US Census Bureau. The closest you may be able to get is the
current population survey (CPS) which I believe is also available via
tidycensus. Regarding your first question, I'm not sure I follow what your
objective is with it. I would use a geography of census block groups as the
measure of median for census block groups. Otherwise it is unclear how you
are defining what a "group of blocks" is.

On Mon, Aug 7, 2023 at 2:34 PM Kevin Zembower via R-sig-Geo <
r-sig-geo@r-project.org> wrote:

> Hello, all,
>
> I'd like to obtain the median age for a population in a specific group
> of US Decennial census blocks. Here's an example of the problem:
>
> ## Example of calculating median age of population in census blocks.
> library(tidyverse)
> library(tidycensus)
>
> counts <- get_decennial(
>  geography = "block",
>  state = "MD",
>  county = "Baltimore city",
>  table = "P1",
>  year = 2020,
>  sumfile = "dhc") %>%
>  mutate(NAME = NULL) %>%
>  filter(substr(GEOID, 6, 11) == "271101" &
> substr(GEOID, 12, 15) %in% c(3000, 3001, 3002)
> )
>
> ages <- get_decennial(
>  geography = "block",
>  state = "MD",
>  county = "Baltimore city",
>  table = "P13",
>  year = 2020,
>  sumfile = "dhc") %>%
>  mutate(NAME = NULL) %>%
>  filter(substr(GEOID, 6, 11) == "271101" &
> substr(GEOID, 12, 15) %in% c(3000, 3001, 3002)
> )
>
> I have two questions:
>
> 1. Is it mathematically valid to multiply the population of a block by
> the median age of that block (in other words, assign the median age to
> each member of a block), then calculate the median of those numbers for
> a group of blocks?
>
> 2. Is raw data on the ages of individuals available anywhere else in the
> census data? I can find tables such as P12, that breaks down the
> population by age ranges or bins, but can't find specific data of counts
> per age in years.
>
> Thanks for your advice and help.
>
> -Kevin
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[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] Issues with spatial package "sits" on CRAN

[Josiah Parry]

This looks like a result of the R CMD Check hard that I think is a
newer-ish check from CRAN. I’ve encountered this before. I encountered it
from using a function in an example that used a suggested package. Since
the package is suggested it’s not available in the hard check. Only
imported packages are available in the hard check.

That may or may not be the case here. But might be worth exploring.

On Sat, Jun 24, 2023 at 17:22 Gilberto Camara 
wrote:

> Dear all
>
> I am the maintainer of the “sits” package on CRAN. I found an odd status
> message regarding “sits” check results on flavors
> "r-devel-linux-x86_64-debian-clang” and "r-devel-linux-x86_64-debian-gcc”,
> as follows:
> ===
> Version: 1.4.1
> Check: package dependencies
> Result: ERROR
> Package required but not available: ‘terra’
>
> Packages suggested but not available for checking:
>  'exactextractr', 'leafem', 'leaflet', 'supercells', ‘tmap'
> 
>
> No such error is reported for “sits” in the other flavors. As an aside,
> the check report for package “terra” also reports errors in the same
> flavors. Any hints on what actions can be done from my side to fix the
> problem will be most welcome.
>
> Best
> Gilberto
> 
> Prof Dr Gilberto Camara
> Senior Researcher
> National Institute for Space Research (INPE), Brazil
> https://gilbertocamara.org/
> =
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[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] Estimate impacts from a spgm - spatial panel regression model

[Josiah Parry]

Jose have you built the model that you want impacts for using the
spatialreg package? Additionally, it would be great if you provided a
reproducible example for folks to try and replicate the behavior you are
experiencing.

On Fri, May 26, 2023 at 12:26 PM Jose Funes  wrote:

> Hi,
> I would like to estimate the impacts of a spatial lag model output. It used
> to work, but it does not work anymore. I used to work fine with the impacts
> function in the spdep package, but it seems the function does not work any
> longer. The second option was to load the spatialreg library and use the
> impacts function, but I get an error message "object type not recognized".
> Please advise.
>
> Jose Funes
> Economic geographer
> DC Office of Planning
> 1100 4th Street SW, 20024
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[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] st_intersection produce Geometry type: GEOMETRY instead of Geometry type: POLYGON

[Josiah Parry]

Manuel, I think you're looking for an intersect*s* rather than the
intersection. Is the following what you're after?


nc = st_read(system.file("shape/nc.shp", package="sf"))
nc <- st_transform(nc, 3857)
g_5 <- st_make_grid(nc, cellsize = 5) |> st_as_sf()
g_5 <- g_5[nc, ]
g_5_d <- st_union(g_5)
g_25000 = st_make_grid(g_5_d, cellsize = 25000) |> st_as_sf()
g_25000 # Geometry type: POLYGON

index <- which(lengths(st_intersects(g_5, nc)) > 0)
plot(st_union(g_5[index,]))

On Fri, Feb 10, 2023 at 12:53 PM Bede-Fazekas Ákos 
wrote:

> Dear Manuel,
>
> technically, the result of st_intersection(x, y), where both x and y are
> POLYGONs, can be POINT, LINESTRING, POLGYON and GEOMETRY as well. The
> result is GEOMETRY if the type of the different features is not the same
> (e.g. POLYGON+POINT).
> You can subset the result in this way:
> g_25000_c_polygons_only <- g_25000_c[st_is(x = g_25000_c, type =
> "POLYGON")]
>
> HTH,
> Ákos
> ___
> Ákos Bede-Fazekas
> Centre for Ecological Research, Hungary
>
> 2023.02.10. 18:32 keltezéssel, Manuel Spínola írta:
> > Dear list members,
> >
> > I am trying to "crop" a polygon (grid) with a polygon, but the result is
> an
> > sf object Geometry type: GEOMETRY, instead of an sf object Geometry type:
> > POLYGON.
> >
> > How can I obtain an sf POLYGON?
> >
> > nc = st_read(system.file("shape/nc.shp", package="sf"))
> >
> >
> >
> > nc <- st_transform(nc, 3857)
> >
> >
> >
> > g_5 <- st_make_grid(nc, cellsize = 5) |> st_as_sf()
> >
> >
> >
> > g_5 <- g_5[nc, ]
> >
> >
> >
> > g_5_d <- st_union(g_5)
> >
> >
> >
> > g_25000 = st_make_grid(g_5_d, cellsize = 25000) |> st_as_sf()
> >
> >
> >
> > g_25000 # Geometry type: POLYGON
> >
> >
> >
> > g_25000_c <- st_intersection(g_25000, g_5_d)
> >
> >
> >
> > g_25000_c # Geometry type: GEOMETRY
> >
> >
> >
> >
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[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] Re-scale units of coordinates in sf geometry?

[Josiah Parry]

While the package interface isn't the friendliest, I think the crsuggest
package may be of interest for you. It's helpful for finding an appropriate
CRS in the units you need given an input CRS.

https://github.com/walkerke/crsuggest

I've used this to find an appropriate CRS and then transform based on the
top suggestion.

On Tue, Jan 31, 2023 at 8:48 AM Andrea Gilardi 
wrote:

> Thank you very much for your example! I briefly checked the examples
> reported in ?st_transform and the docs at the PROJ website around
> "Unit conversion"
> (https://proj.org/operations/conversions/unitconvert.html) and I found
> that the following code also seems to work (although with a warning
> message that I'm not sure I understand):
>
> library(sp)
> demo(meuse, echo = FALSE, ask = FALSE)
> library(sf)
> #> Linking to GEOS 3.10.2, GDAL 3.4.1, PROJ 7.2.1; sf_use_s2() is TRUE
> sf_proj_network(TRUE)
> #> [1] "https://cdn.proj.org;
> st_as_sf(meuse) |> st_bbox()
> #>   xmin   ymin   xmax   ymax
> #> 178605 329714 181390 333611
> meuse2 <- st_as_sf(meuse) |>
>   st_transform(pipeline = "+proj=pipeline +step +proj=unitconvert
> +xy_in=m +xy_out=km")
> #> Warning in st_transform.sfc(st_geometry(x), crs, ...): pipeline not
> found in
> #> PROJ-suggested candidate transformations
> st_bbox(meuse2)
> #>xminyminxmaxymax
> #> 178.605 329.714 181.390 333.611
>
> I think this might be easier than manually adjusting the WKT
> representation of the CRS, but I'm not sure that this is really a
> recommended way to transform units since, for some reason, it does not
> modify the CRS of the objects which makes any analysis very difficult:
>
> all.equal(st_crs(meuse), st_crs(meuse2))
> #> [1] TRUE
> library(mapview)
> mapview(meuse) # seems right
> mapview(meuse2) # completely off
>
> Andrea
>
> Il giorno mar 31 gen 2023 alle ore 12:33 Edzer Pebesma
>  ha scritto:
> >
> >
> >
> > On 31/01/2023 12:12, Andrea Gilardi wrote:
> > >>   st_transform can do transformations and conversions between
> different CRSs, unit conversions is a special case of that.
> > >
> > > Dear all, I'm sorry if this is a trivial or stupid question but I was
> > > wondering if you could provide an example of using st_transform to
> > > apply a unit conversion transformation. For example, if I define
> > > something like
> > >
> > > library(sf)
> > > pt <- st_sfc(st_point(c(150, 500)), crs = 3003) # some place
> > > in North Italy
> > > st_crs(3003) # units are expressed in metres
> > >
> > > can I use st_transform to convert the unit measurement of pt from
> > > metres to km and preserve that information in the CRS?
> >
> > It seems so, using proj4strings (not recommended, but simple):
> >
> > library(sp)
> > demo(meuse, echo = FALSE, ask = FALSE)
> > library(sf)
> > # Linking to GEOS 3.11.1, GDAL 3.6.2, PROJ 9.1.1; sf_use_s2() is TRUE
> > st_as_sf(meuse) |> st_bbox()
> > #   xmin   ymin   xmax   ymax
> > # 178605 329714 181390 333611
> > st_crs(meuse)$proj4string
> > # [1] "+proj=sterea +lat_0=52.156160556 +lon_0=5.387639
> > +k=0.079 +x_0=155000 +y_0=463000 +ellps=bessel +units=m +no_defs"
> > st_as_sf(meuse) |>
> >st_transform("+proj=sterea +lat_0=52.156160556
> > +lon_0=5.387639 +k=0.079 +x_0=155000 +y_0=463000
> > +ellps=bessel +units=km +no_defs") |>
> >st_bbox()
> > #xminyminxmaxymax
> > # 178.605 329.714 181.390 333.611
> >
> > The better way would be to modify WKT representations of CRSs.
> >
> > >
> > > Thanks
> > > Andrea
> > >
> > >
> > > Il giorno mer 25 gen 2023 alle ore 18:58 Edzer Pebesma
> > >  ha scritto:
> > >>
> > >>
> > >>
> > >> On 25/01/2023 18:42, Josiah Parry wrote:
> > >>> I wonder if `units::set_units()` is a better fit for the job
> > >>>
> https://r-quantities.github.io/units/articles/measurement_units_in_R.html
> > >>
> > >> It could definitely tell you which number to choose when going from,
> > >> say, US feet to km. Coordinates in sf geometries are not stored as
> units
> > >> objects, unit info is encoded in the CRS. st_transform can do
> > >> transformations and conversions between different CRSs, unit
> conversions
> > >> is a special case of that.
> > >>
> > >>>
> > >>> On W

Re: [R-sig-Geo] Re-scale units of coordinates in sf geometry?

[Josiah Parry]

I wonder if `units::set_units()` is a better fit for the job
https://r-quantities.github.io/units/articles/measurement_units_in_R.html

On Wed, Jan 25, 2023 at 12:37 PM Steve Gutreuter 
wrote:

> Is it safe to re-scale sf geometry coordinates from meters to
> kilometers using, for example:
>
> sfobj$geometry <- sfobj$geometry / 1000
>
> It seems to work, but I understand too little about spatial data to
> know whether that practice is actually safe.  I am working with spatial
> data in a continental-scale equidistant conic projection, and the units
> are meters.  It seems that kilometers would be better suited stochastic
> partial differential equation modeling on a finite-element mesh, but
> maybe that is a moot point.
>
> Any and all advice will be much appreciated.
>
> Thanks!
> --
> Steve Gutreuter
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[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] Convert geojson file to R

[Josiah Parry]

You're going to want to read the file with sf.

Try object <- sf::st_read("~countrymasks.geojson")

On Mon, Nov 28, 2022 at 7:09 AM Miluji Sb  wrote:

> Greetings everyone,
>
> I would like to convert the geojson file (
>
> https://drive.google.com/file/d/18h3sOjZg5jp5euLTWRi5mC40Sja8TZDN/view?usp=sharing
> )
> to a dataframe - essentially obtain which has coordinates matched to a
> country.
>
> I have tried the following;
>
> ###
> states <- geojsonsf::geojson_sf("~/countrymasks.geojson")
> geo <- geojsonsf::sf_geojson(states)
> sf <- sf::st_read(geo, quiet = T )
> df <- as.data.frame(sf::st_coordinates(sf) )
> ##
>
> But I get the following output, I am a bit lost. Any help will be highly
> appreciated.
>
> Best,
>
>   structure(list(X = c(-67.3804401, -67.36091, -67.38058,
> -67.339709998, -67.3780199, -67.32211), Y =
> c(-55.565569996,
> -55.584009899, -55.600410001, -55.614969997, -55.63521,
> -55.640089997), L1 = c(1, 1, 1, 1, 1, 1), L2 = c(1, 1, 1,
> 1, 1, 1), L3 = c(1, 1, 1, 1, 1, 1)), row.names = c(NA, 6L), class =
> "data.frame")
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[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] Data recommendation

[Josiah Parry]

Hey Erin,

You could download 10 years of US census data at the county level. That
will be about 32k observations. Do you have any more constraints than the
number of observations?

On Fri, Oct 28, 2022 at 4:15 PM Erin Hodgess 
wrote:

> Hello!
>
> How are you?
>
> Could someone recommend a spatial data set with about 3 observations,
> please?  I'm hoping for one that can be easily downloaded.
>
> Thank you,
> Sincerely,
> Erin
>
> 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
>

[[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] df with embedded wkt lists to sf

[Josiah Parry]

Yeah, of course. I wouldn’t necessarily call it “convoluted!” It’s a pretty
standard data cleaning flow.

As a note, I was last and specified the coordinate columns by position. You
should provide a vector of the column names eg c(“x”, “y”). Check out the
help documentation for that function. It should be useful!

The process, if it’s not necessarily clear, separates each point to a row,
those points then are combined to multipoint and then cast as a line
string.

On Fri, Jun 10, 2022 at 07:16 Howard, Tim G (DEC) 
wrote:

> Josiah,
> Interesting, thanks for working out and posting this approach. It may be
> just as complex and convoluted as what I've come up with! Dis-associating
> the line strings to points and then re-aggregating them to lines using
> group-by seems iffy to me, but it works (and for polygons as well).
>
> Of course I've got a much larger attribute table than just a "comments"
> column so the spot where you define 'coords=c(2,3)' doesn't work. But I've
> come up with a work-around to that by finding the location of the lon/lat
> columns before starting. And the attribute table is lost so it needs to be
> joined back in a step not needed in my approach.
>
> I guess this confirms that there isn't already a part of  st_as_sf​ I was
> missing!
> Thanks again,
> Tim
>
>
> From: Josiah Parry 
> Sent: Thursday, June 9, 2022 4:39 PM
> To: Howard, Tim G (DEC) 
> Cc: r-sig-geo@r-project.org 
> Subject: Re: [R-sig-Geo] df with embedded wkt lists to sf
>
> ATTENTION: This email came from an external source. Do not open
> attachments or click on links from unknown senders or unexpected emails.
>
> Furthermore, if you want to get these points into a linstring you can
> combine the points by group (comment) and then cast them to a line like so
> below.
>
> This is an interesting use case! Thanks for introducing me to it.
>
> dat_sf |>
>   dplyr::group_by(comment) |>
>   dplyr::summarise(geometry = sf::st_cast(
> sf::st_combine(geometry), "LINESTRING"
> ))
>
> On Thu, Jun 9, 2022 at 4:34 PM Josiah Parry 
> wrote:
> Hey Tim,
>
> The key thing here is to separate the long / lat points into elements in a
> vector. You can do this with a string split. Afterwards, separate these
> into their own rows like I've done below.
>
> I think this should get you on the right path!
>
>
> dat <- dget(textConnection(txtString))
>
> dat |>
>   tidyr::unnest(c(longitude, latitude)) |>
>   dplyr::mutate(longitude = strsplit(longitude, "; "),
> latitude = strsplit(latitude, "; ")) |>
>   tidyr::unnest(c(longitude, latitude)) |>
>   sf::st_as_sf(coords = c(2, 3), crs = 4326)
>
> On Thu, Jun 9, 2022 at 3:48 PM Howard, Tim G (DEC) via R-sig-Geo <
> r-sig-geo@r-project.org> wrote:
> Howdy all -
> There's probably a way to do this much​ more simply than I've figured it
> out, so it's a bit embarrassing but here goes. I'm getting data out of a
> shiny app that looks like the following, with lists of coordinates within
> separate longitude and latitude columns.
>
> Is there more efficient way to get an `sf` collection than what I've got?
> Perhaps an `apply` replacement for the for() loop? Using a tibble because
> that's how `googlesheets4` gives it to me.
>
> # set up a couple of lines strings. lists within data.frame/tibble
> txtString <- 'structure(list(comment = c("line one", "line two"),
> longitude = list("-115.138577; -114.942454; -114.170219", "-118.411382;
> -118.153971; -117.83527; -117.246901; -117.026262; -117.185613"),
> latitude = list("37.527588; 38.234088; 38.368805", "41.296472; 41.645606;
> 41.819467; 41.837741; 41.590604; 41.12")),
> row.names = c(NA, -2L), class = c("tbl_df", "tbl", "data.frame"))'
>
> dat <- dget(textConnection(txtString))
>
> # function for parsing the text strings
> getWKT <- function(x){
>   st_linestring(matrix(
> c(as.numeric(unlist(strsplit(x$longitude[[1]],";"))),
>   as.numeric(unlist(strsplit(x$latitude[[1]],";",
> byrow = FALSE, ncol = 2)
>   )
> }
>
> # populate dataframe/tibble by going back to sf text
> dat$wkt <- NA
> for(i in 1:nrow(dat)){
>   dat$wkt[[i]] <- st_as_text(getWKT(dat[i,]))
> }
>
> # finally make the sf collection
> dat_sf <- st_as_sf(dat, wkt = "wkt", crs = 4326)
>
>
> Thanks in advance for any tips.
> Tim
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo

[[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] writing a leaflet object to a KML file

[Josiah Parry]

Hey Erin,

Leaflet is a JavaScript library to make interactive maps. So necessarily,
the output is html and JavaScript. Can you clarify what you mean by output?
Perhaps a more specific example can help inform the question.

I do think, however, st_write() is the proper tool. But maybe you need
subsets of data from an interactive map?

On Fri, Jun 3, 2022 at 21:07 Erin Hodgess  wrote:

> Hello!
>
> Is there a way to write a leaflet object to a KML instead of an HTML file,
> please?
>
> I did see st_write for the sf object, but I really need the output from
> leaflet.
>
> Thanks so much!
>
> Sincerely,
> Erin
>
>
> 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
>

[[alternative HTML version deleted]]

___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo