Subscribe to R-sig-geo feed
This is an archive for R-sig-geo, not a forum. It is not possible to post through Nabble - you may not start a new thread nor follow up an existing thread. If you wish to post, but are not subscribed to the list through the list homepage, subscribe first (through the list homepage, not via Nabble) and post from your subscribed email address. Until 2015-06-20, subscribers could post through Nabble, but policy has been changed as too many non-subscribers misunderstood the interface.
Updated: 19 min 28 sec ago

Re: sp

Thu, 05/16/2019 - 08:43
 Thanks a lot for the reply Prof. Bivand. It works fine now.
Yes I did not use R since few months.I was wondering why this piece of coding left is not working:
neighbors.knn1 <- knn2nb(knearneigh(coord, 1, longlat=F), sym=F)## Global G   
dlwknn1.B <- nb2listw(neighbors.knn1, style="B", zero.policy=TRUE)
globalG.test(CRIME, dlwknn1.B, zero.policy=F)

Error: object 'CRIME' not found
Thanks again for your help.Francesco

    Il giovedì 16 maggio 2019, 15:07:37 CEST, Roger Bivand <[hidden email]> ha scritto:  
 
 Please post in plain text to avoid code mangling. You have not noticed
that a lot has been happening. First, data sets from spdep have mostly
been moved to spData. Next, spData mostly uses sf to read and format data.
Finally you may also see changes as spdep model fitting functions are in
spatialreg and will shortly be dropped from spdep. In your case:

> library(sp)
> library(spdep)
Loading required package: spData
Loading required package: sf
Linking to GEOS 3.7.2, GDAL 3.0.0, PROJ 6.1.0
> example(columbus)

colmbs> columbus <- st_read(system.file("shapes/columbus.shp",
package="spData")[1], quiet=TRUE)

colmbs> col.gal.nb <- read.gal(system.file("weights/columbus.gal",
package="spData")[1])
> coord <- coordinates(columbus)
Error in (function (classes, fdef, mtable)  :
  unable to find an inherited method for function ‘coordinates’ for
signature ‘"sf"’
> columbus <- as(columbus, "Spatial")
> coord <- coordinates(columbus)

Giving the full output, you can see that example(columbus) reads in the
data and neighbours from spData, using sf. Consequently, you'd need to
coerce columbus to an sp class if you do not want to upgrade your
workflow to sf compatability.

Hope this clarifies,

Roger

On Thu, 16 May 2019, Francesco Perugini via R-sig-Geo wrote:

> Dear all,I'm not very familiar with R.
> I'm tying to use this code I've written months ago. At that time it was
> working but now it is not.
>> library(sp)
>> library(spdep)
>> example(columbus)
>> coord <- coordinates(columbus)and get this message
> Error in (function (classes, fdef, mtable)  : unable to find an
> inherited method for function ‘coordinates’ for signature ‘"sf"’
> I've tried to also calllibrary(sf)but got the same error.I was wondering
> why?
> Thanks a lot.Francesco
>
>
>
>     [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> 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: [hidden email]
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en 
        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: sp

Thu, 05/16/2019 - 08:07
Please post in plain text to avoid code mangling. You have not noticed
that a lot has been happening. First, data sets from spdep have mostly
been moved to spData. Next, spData mostly uses sf to read and format data.
Finally you may also see changes as spdep model fitting functions are in
spatialreg and will shortly be dropped from spdep. In your case:

> library(sp)
> library(spdep)
Loading required package: spData
Loading required package: sf
Linking to GEOS 3.7.2, GDAL 3.0.0, PROJ 6.1.0
> example(columbus)

colmbs> columbus <- st_read(system.file("shapes/columbus.shp",
package="spData")[1], quiet=TRUE)

colmbs> col.gal.nb <- read.gal(system.file("weights/columbus.gal",
package="spData")[1])
> coord <- coordinates(columbus)
Error in (function (classes, fdef, mtable)  :
   unable to find an inherited method for function ‘coordinates’ for
signature ‘"sf"’
> columbus <- as(columbus, "Spatial")
> coord <- coordinates(columbus)

Giving the full output, you can see that example(columbus) reads in the
data and neighbours from spData, using sf. Consequently, you'd need to
coerce columbus to an sp class if you do not want to upgrade your
workflow to sf compatability.

Hope this clarifies,

Roger

On Thu, 16 May 2019, Francesco Perugini via R-sig-Geo wrote:

> Dear all,I'm not very familiar with R.
> I'm tying to use this code I've written months ago. At that time it was
> working but now it is not.
>> library(sp)
>> library(spdep)
>> example(columbus)
>> coord <- coordinates(columbus)and get this message
> Error in (function (classes, fdef, mtable)  : unable to find an
> inherited method for function ‘coordinates’ for signature ‘"sf"’
> I've tried to also calllibrary(sf)but got the same error.I was wondering
> why?
> Thanks a lot.Francesco
>
>
>
> [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> 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: [hidden email]
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Roger Bivand
Department of Economics
Norwegian School of Economics
Helleveien 30
N-5045 Bergen, Norway

sp

Thu, 05/16/2019 - 07:55
Dear all,I'm not very familiar with R.
I'm tying to use this code I've written months ago. At that time it was working but now it is not.
library(sp)library(spdep)example(columbus)
coord <- coordinates(columbus)and get this messageError in (function (classes, fdef, mtable)  :
  unable to find an inherited method for function ‘coordinates’ for signature ‘"sf"’I've tried to also calllibrary(sf)but got the same error.I was wondering why?Thanks a lot.Francesco



        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: Mark variograms: 3D(xyt) points + 1D marks

Sun, 05/12/2019 - 17:43
They have made spatial and temporal mark variograms (xy space with time as a mark, or 1D time with xy 2D marks, respectively) available via their mvstpp package.
The current problem is that I've just got many cases(points) who share the same location because they come from the same household. That's not so bad as marked pont processes can have coincident space coordinates, just not coincident spacetime coordinates.

However additionally I want to give a time mark not just to their onset but all the time they are infectious for until treatment (since infectivity probably rises during the infection). This would make the xyt space far too crowded. I want to avoid spatial jittering as I fear this will pollute the microscale semivariance which is of interest to me. The way I am trying is aggregating individuals into household units and introducing a fourth dimension C_i to represent total numbers of active cases at that time in hhld_i. My goal is a space-time variogram style plot but as a space-time marked variogram instead: by producing a spatial marked variograms stratified by time lag.

Sent from my mobile

________________________________
From: Edzer Pebesma <[hidden email]>
Sent: Sunday, May 12, 2019 9:04:39 PM
To: Tim Pollington; [hidden email]
Subject: Re: [R-sig-Geo] Mark variograms: 3D(xyt) points + 1D marks



On 5/11/19 6:11 PM, Tim Pollington wrote:
> Thank you Edzer for your suggestion however I'm trying to avoid
> geostatistical methods because my data is disease cases recorded at
> household locations. Therefore strictly speaking there is not a random
> field that pervades the space between the households and so I must treat
> it as a spatiotemporal marked point process instead. I attemping to
> extend Stoyan et al's mark variograms for ST
> processes https://www.sciencedirect.com/science/article/pii/S2211675317300696 to
> my data.

Regrettably (an ironically, as an associate editor) I have no longer
access to that journal. Did you contact the authors of the paper whether
they have software they're willing to share?

>
> Hopefully I'll have gotten a bit further by July so perhaps I can show
> you more if you're attending Spatial Statistics in Sitges.

[[elided Hotmail spam]]

>
> Kind regards,
>
> Tim.
> ------------------------------------------------------------------------
> *From:* Edzer Pebesma <[hidden email]>
> *Sent:* 10 May 2019 13:18
> *To:* [hidden email]
> *Subject:* Re: [R-sig-Geo] Mark variograms: 3D(xyt) points + 1D marks
>
> No, but you can model them as a function of space and time, see e.g.
> https://journal.r-project.org/archive/2016/RJ-2016-014/index.html
>
> On 5/10/19 12:53 PM, Tim Pollington wrote:
>> On reflection please ignore my question. One can't construct an xyt variogram with additional marks as one can't define a proper distance in an xyt space as different units are involved.
>>
>>        [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> [hidden email]
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>
> --
> Edzer Pebesma
> Institute for Geoinformatics
> Heisenbergstrasse 2, 48151 Muenster, Germany
> Phone: +49 251 8333081
--
Edzer Pebesma
Institute for Geoinformatics
Heisenbergstrasse 2, 48151 Muenster, Germany
Phone: +49 251 8333081

        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: Mark variograms: 3D(xyt) points + 1D marks

Sun, 05/12/2019 - 15:04


On 5/11/19 6:11 PM, Tim Pollington wrote:
> Thank you Edzer for your suggestion however I'm trying to avoid
> geostatistical methods because my data is disease cases recorded at
> household locations. Therefore strictly speaking there is not a random
> field that pervades the space between the households and so I must treat
> it as a spatiotemporal marked point process instead. I attemping to
> extend Stoyan et al's mark variograms for ST
> processes https://www.sciencedirect.com/science/article/pii/S2211675317300696 to
> my data. 

Regrettably (an ironically, as an associate editor) I have no longer
access to that journal. Did you contact the authors of the paper whether
they have software they're willing to share?

>
> Hopefully I'll have gotten a bit further by July so perhaps I can show
> you more if you're attending Spatial Statistics in Sitges.

Looking forward to that!

>
> Kind regards,
>
> Tim.
> ------------------------------------------------------------------------
> *From:* Edzer Pebesma <[hidden email]>
> *Sent:* 10 May 2019 13:18
> *To:* [hidden email]
> *Subject:* Re: [R-sig-Geo] Mark variograms: 3D(xyt) points + 1D marks
>  
> No, but you can model them as a function of space and time, see e.g.
> https://journal.r-project.org/archive/2016/RJ-2016-014/index.html
>
> On 5/10/19 12:53 PM, Tim Pollington wrote:
>> On reflection please ignore my question. One can't construct an xyt variogram with additional marks as one can't define a proper distance in an xyt space as different units are involved.
>>
>>        [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> [hidden email]
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>
> --
> Edzer Pebesma
> Institute for Geoinformatics
> Heisenbergstrasse 2, 48151 Muenster, Germany
> Phone: +49 251 8333081 --
Edzer Pebesma
Institute for Geoinformatics
Heisenbergstrasse 2, 48151 Muenster, Germany
Phone: +49 251 8333081

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

pEpkey.asc (2K) Download Attachment

Re: Mark variograms: 3D(xyt) points + 1D marks

Sat, 05/11/2019 - 11:11
Thank you Edzer for your suggestion however I'm trying to avoid geostatistical methods because my data is disease cases recorded at household locations. Therefore strictly speaking there is not a random field that pervades the space between the households and so I must treat it as a spatiotemporal marked point process instead. I attemping to extend Stoyan et al's mark variograms for ST processes https://www.sciencedirect.com/science/article/pii/S2211675317300696 to my data.

Hopefully I'll have gotten a bit further by July so perhaps I can show you more if you're attending Spatial Statistics in Sitges.

Kind regards,

Tim.
________________________________
From: Edzer Pebesma <[hidden email]>
Sent: 10 May 2019 13:18
To: [hidden email]
Subject: Re: [R-sig-Geo] Mark variograms: 3D(xyt) points + 1D marks

No, but you can model them as a function of space and time, see e.g.
https://journal.r-project.org/archive/2016/RJ-2016-014/index.html

On 5/10/19 12:53 PM, Tim Pollington wrote:
> On reflection please ignore my question. One can't construct an xyt variogram with additional marks as one can't define a proper distance in an xyt space as different units are involved.
>
>        [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

--
Edzer Pebesma
Institute for Geoinformatics
Heisenbergstrasse 2, 48151 Muenster, Germany
Phone: +49 251 8333081

        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: Mark variograms: 3D(xyt) points + 1D marks

Fri, 05/10/2019 - 07:18
No, but you can model them as a function of space and time, see e.g.
https://journal.r-project.org/archive/2016/RJ-2016-014/index.html

On 5/10/19 12:53 PM, Tim Pollington wrote:
> On reflection please ignore my question. One can't construct an xyt variogram with additional marks as one can't define a proper distance in an xyt space as different units are involved.
>
> [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

--
Edzer Pebesma
Institute for Geoinformatics
Heisenbergstrasse 2, 48151 Muenster, Germany
Phone: +49 251 8333081

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

pEpkey.asc (2K) Download Attachment

Re: Mark variograms: 3D(xyt) points + 1D marks

Fri, 05/10/2019 - 05:53
On reflection please ignore my question. One can't construct an xyt variogram with additional marks as one can't define a proper distance in an xyt space as different units are involved.

        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: add a field to sf object and point shape in kml

Wed, 05/08/2019 - 09:35
Thank you, Barry!  Your explanation of how all these various
packages/libraries work is very helpful.  And so is your justification
(explanation?) of styling using extra column vs writeOGR options.
Appreciatively,
Vijay.

On Tue, May 7, 2019 at 3:23 PM Barry Rowlingson <[hidden email]>
wrote:

>
>
> On Tue, May 7, 2019 at 6:11 PM Vijay Lulla <[hidden email]> wrote:
>
>> Good one Barry!  As far as I'm aware sf uses rgdal to write various file
>> formats and writeOGR has options called dataset_options and layer_options
>> which are considered experimental.
>>
>
> Not quite - `sf` uses the underlying C/C++ GDAL/OGR library directly. The
> `rgdal` package does the same. One doesn't use the other.
>
> To write KML the GDAL/OGR library uses either its "kml" or its "libkml"
> driver which is documented here:
>
> https://www.gdal.org/drv_libkml.html
>
> dataset_options and layer_options tend to be single value options per
> dataset and per layer - to set something per *feature* is going to need a
> lot more information, and having an extra attribute in the feature table
> (spatial data frame) seems reasonable.
>
> I've not quite understood all the libkml creation options relating to
> styles so there may be an easy way to do it but I don't think the overhead
> of an extra column is too much trouble.
>
> Barry
>
>
>
>> Do you know if either of these options can be used instead of creating a
>> new field/attribute for the sf dataframe?  More importantly, I would like
>> to know your opinion of using these options vs creating an attribute.
>> Thanks in advance,
>> Vijay.
>>
>> On Tue, May 7, 2019 at 11:07 AM Barry Rowlingson <[hidden email]>
>> wrote:
>>
>>> On Tue, May 7, 2019 at 12:54 PM Marta Rufino <[hidden email]>
>>> wrote:
>>>
>>> > Hi,
>>> >
>>> > Two very simple question:
>>> >
>>> > 2)
>>> > Can we change the polygon col/fill and point shape/col when exporting
>>> sf
>>> > obejcts to kml, using the function:
>>> > st_write(sf.object, " sf.object  .kml", driver='kml')
>>> >
>>> >
>>> Setting styles for writing KML using GDAL/OGR is described here:
>>>
>>>
>>> https://gis.stackexchange.com/questions/297494/how-to-style-kml-through-libkml-layer-creation-options
>>>
>>> For example I have an sf data frame of Osprey tracking data (as points),
>>> and if I create a new field:
>>>
>>>
>>> osp$OGR_STYLE="PEN(c:#128020,w:5px)"
>>>
>>> and then:
>>>
>>> st_write(osp, "/tmp/osp.kml",driver="libkml")
>>>
>>> then the features in the KML get written with:
>>>
>>>          <LineStyle>
>>>             <color>ff208012</color>
>>>             <width>5</width>
>>>           </LineStyle>
>>>
>>> I realise now that "PEN" is probably wrong for point features, but it
>>> should all be explained in the google OGR style docs:
>>>
>>> https://www.gdal.org/ogr_feature_style.html
>>>
>>> and in the links in that GIS stack exchange question...
>>>
>>> Barry
>>>
>>>         [[alternative HTML version deleted]]
>>>
>>> _______________________________________________
>>> R-sig-Geo mailing list
>>> [hidden email]
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>
>>
>>
>>
        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: Semi-join?

Tue, 05/07/2019 - 15:43
Thanks. Works now. It was an issue with map projections.

THK

On Tue, May 7, 2019 at 3:18 PM Tim Keitt <[hidden email]> wrote:

>
>
> On Tue, May 7, 2019 at 1:39 PM Edzer Pebesma <
> [hidden email]> wrote:
>
>>
>>
>> On 5/7/19 8:29 PM, Tim Keitt wrote:
>> > I keep finding things that are trivial in sql are not so in R, so
>> perhaps
>> > you can help me out.
>> >
>> > What would be the way in the 'sf' package to retain only polygons from
>> one
>> > coverage that intersect points in another coverage? I think that's a
>> > semi-join.
>> >
>> > Roughly: 'select a.* from polys a, points b where st_intersects(a.geom,
>> > b.geom)'
>>
>> a[b,]
>>
>> # or
>>
>> st_join(a, b, left = FALSE) # no left join gives you inner join
>>
>
> Hmm... tried this and for some reasons it was not giving me what I wanted.
> I will investigate.
>
> THK
>
>
>>
>> >
>> > Thanks.
>> >
>> > THK
>> >
>>
>> --
>> Edzer Pebesma
>> Institute for Geoinformatics
>> Heisenbergstrasse 2, 48151 Muenster, Germany
>> Phone: +49 251 8333081
>> _______________________________________________
>> R-sig-Geo mailing list
>> [hidden email]
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>> >> This message is from an external sender. Learn more about why this <<
>> >> matters at https://links.utexas.edu/rtyclf.                        <<
>>
>
>
> --
> Timothy H. Keitt
> Professor of Integrative Biology and
> Associate Chair for Undergraduate Education
> http://www.keittlab.org/
>

--
Timothy H. Keitt
Professor of Integrative Biology and
Associate Chair for Undergraduate Education
http://www.keittlab.org/

        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: Semi-join?

Tue, 05/07/2019 - 15:18
On Tue, May 7, 2019 at 1:39 PM Edzer Pebesma <[hidden email]>
wrote:

>
>
> On 5/7/19 8:29 PM, Tim Keitt wrote:
> > I keep finding things that are trivial in sql are not so in R, so perhaps
> > you can help me out.
> >
> > What would be the way in the 'sf' package to retain only polygons from
> one
> > coverage that intersect points in another coverage? I think that's a
> > semi-join.
> >
> > Roughly: 'select a.* from polys a, points b where st_intersects(a.geom,
> > b.geom)'
>
> a[b,]
>
> # or
>
> st_join(a, b, left = FALSE) # no left join gives you inner join
>
Hmm... tried this and for some reasons it was not giving me what I wanted.
I will investigate.

THK


>
> >
> > Thanks.
> >
> > THK
> >
>
> --
> Edzer Pebesma
> Institute for Geoinformatics
> Heisenbergstrasse 2, 48151 Muenster, Germany
> Phone: +49 251 8333081
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >> This message is from an external sender. Learn more about why this <<
> >> matters at https://links.utexas.edu/rtyclf.                        <<
>

--
Timothy H. Keitt
Professor of Integrative Biology and
Associate Chair for Undergraduate Education
http://www.keittlab.org/

        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: add a field to sf object and point shape in kml

Tue, 05/07/2019 - 14:23
On Tue, May 7, 2019 at 6:11 PM Vijay Lulla <[hidden email]> wrote:

> Good one Barry!  As far as I'm aware sf uses rgdal to write various file
> formats and writeOGR has options called dataset_options and layer_options
> which are considered experimental.
>

Not quite - `sf` uses the underlying C/C++ GDAL/OGR library directly. The
`rgdal` package does the same. One doesn't use the other.

To write KML the GDAL/OGR library uses either its "kml" or its "libkml"
driver which is documented here:

https://www.gdal.org/drv_libkml.html

dataset_options and layer_options tend to be single value options per
dataset and per layer - to set something per *feature* is going to need a
lot more information, and having an extra attribute in the feature table
(spatial data frame) seems reasonable.

I've not quite understood all the libkml creation options relating to
styles so there may be an easy way to do it but I don't think the overhead
of an extra column is too much trouble.

Barry



> Do you know if either of these options can be used instead of creating a
> new field/attribute for the sf dataframe?  More importantly, I would like
> to know your opinion of using these options vs creating an attribute.
> Thanks in advance,
> Vijay.
>
> On Tue, May 7, 2019 at 11:07 AM Barry Rowlingson <[hidden email]>
> wrote:
>
>> On Tue, May 7, 2019 at 12:54 PM Marta Rufino <[hidden email]>
>> wrote:
>>
>> > Hi,
>> >
>> > Two very simple question:
>> >
>> > 2)
>> > Can we change the polygon col/fill and point shape/col when exporting sf
>> > obejcts to kml, using the function:
>> > st_write(sf.object, " sf.object  .kml", driver='kml')
>> >
>> >
>> Setting styles for writing KML using GDAL/OGR is described here:
>>
>>
>> https://gis.stackexchange.com/questions/297494/how-to-style-kml-through-libkml-layer-creation-options
>>
>> For example I have an sf data frame of Osprey tracking data (as points),
>> and if I create a new field:
>>
>>
>> osp$OGR_STYLE="PEN(c:#128020,w:5px)"
>>
>> and then:
>>
>> st_write(osp, "/tmp/osp.kml",driver="libkml")
>>
>> then the features in the KML get written with:
>>
>>          <LineStyle>
>>             <color>ff208012</color>
>>             <width>5</width>
>>           </LineStyle>
>>
>> I realise now that "PEN" is probably wrong for point features, but it
>> should all be explained in the google OGR style docs:
>>
>> https://www.gdal.org/ogr_feature_style.html
>>
>> and in the links in that GIS stack exchange question...
>>
>> Barry
>>
>>         [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> [hidden email]
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>
>
>
        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: Semi-join?

Tue, 05/07/2019 - 13:39


On 5/7/19 8:29 PM, Tim Keitt wrote:
> I keep finding things that are trivial in sql are not so in R, so perhaps
> you can help me out.
>
> What would be the way in the 'sf' package to retain only polygons from one
> coverage that intersect points in another coverage? I think that's a
> semi-join.
>
> Roughly: 'select a.* from polys a, points b where st_intersects(a.geom,
> b.geom)'

a[b,]

# or

st_join(a, b, left = FALSE) # no left join gives you inner join

>
> Thanks.
>
> THK
>

--
Edzer Pebesma
Institute for Geoinformatics
Heisenbergstrasse 2, 48151 Muenster, Germany
Phone: +49 251 8333081

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

pEpkey.asc (2K) Download Attachment

Semi-join?

Tue, 05/07/2019 - 13:29
I keep finding things that are trivial in sql are not so in R, so perhaps
you can help me out.

What would be the way in the 'sf' package to retain only polygons from one
coverage that intersect points in another coverage? I think that's a
semi-join.

Roughly: 'select a.* from polys a, points b where st_intersects(a.geom,
b.geom)'

Thanks.

THK

--
Timothy H. Keitt
Professor of Integrative Biology and
Associate Chair for Undergraduate Education
http://www.keittlab.org/

        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: add a field to sf object and point shape in kml

Tue, 05/07/2019 - 12:37
Hi,

Cool! Thank you for the very quick and efficient reply.

Just remembered an alternative for the kml challenge... using plotKML after
converting it to spatial.

library(plotKML)
plotKML(as(my.sf.file, "Spatial"), colour_scale=SAGA_pal[[1]]) # this
function has a very detailed help with many easy options. This is just an
example...

It is a pity that it still does not work directly with sf objects (hehehe -
Edzer? Tom?) - but this way it is fine.

I am trying to retrieve the issues I found previously with adding fields
this way... if I find it I will report those.

Cheers,
M.


Vijay Lulla <[hidden email]> escreveu no dia terça, 7/05/2019 à(s)
18:11:

> Good one Barry!  As far as I'm aware sf uses rgdal to write various file
> formats and writeOGR has options called dataset_options and layer_options
> which are considered experimental.  Do you know if either of these options
> can be used instead of creating a new field/attribute for the sf
> dataframe?  More importantly, I would like to know your opinion of using
> these options vs creating an attribute.
> Thanks in advance,
> Vijay.
>
> On Tue, May 7, 2019 at 11:07 AM Barry Rowlingson <[hidden email]>
> wrote:
>
>> On Tue, May 7, 2019 at 12:54 PM Marta Rufino <[hidden email]>
>> wrote:
>>
>> > Hi,
>> >
>> > Two very simple question:
>> >
>> > 2)
>> > Can we change the polygon col/fill and point shape/col when exporting sf
>> > obejcts to kml, using the function:
>> > st_write(sf.object, " sf.object  .kml", driver='kml')
>> >
>> >
>> Setting styles for writing KML using GDAL/OGR is described here:
>>
>>
>> https://gis.stackexchange.com/questions/297494/how-to-style-kml-through-libkml-layer-creation-options
>>
>> For example I have an sf data frame of Osprey tracking data (as points),
>> and if I create a new field:
>>
>>
>> osp$OGR_STYLE="PEN(c:#128020,w:5px)"
>>
>> and then:
>>
>> st_write(osp, "/tmp/osp.kml",driver="libkml")
>>
>> then the features in the KML get written with:
>>
>>          <LineStyle>
>>             <color>ff208012</color>
>>             <width>5</width>
>>           </LineStyle>
>>
>> I realise now that "PEN" is probably wrong for point features, but it
>> should all be explained in the google OGR style docs:
>>
>> https://www.gdal.org/ogr_feature_style.html
>>
>> and in the links in that GIS stack exchange question...
>>
>> Barry
>>
>>         [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> [hidden email]
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>
>
>
--
Marta M. Rufino (auxiliary researcher)

*____________________________________________________*MARE - Marine and
Environmental Sciences Centre
Faculty of Sciences, University of Lisbon
Campo Grande, 1749-016 Lisboa,
Portugal
Tel: + 351 21 750 00 00, extension: 22576

        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: add a field to sf object and point shape in kml

Tue, 05/07/2019 - 12:11
Good one Barry!  As far as I'm aware sf uses rgdal to write various file
formats and writeOGR has options called dataset_options and layer_options
which are considered experimental.  Do you know if either of these options
can be used instead of creating a new field/attribute for the sf
dataframe?  More importantly, I would like to know your opinion of using
these options vs creating an attribute.
Thanks in advance,
Vijay.

On Tue, May 7, 2019 at 11:07 AM Barry Rowlingson <[hidden email]>
wrote:

> On Tue, May 7, 2019 at 12:54 PM Marta Rufino <[hidden email]>
> wrote:
>
> > Hi,
> >
> > Two very simple question:
> >
> > 2)
> > Can we change the polygon col/fill and point shape/col when exporting sf
> > obejcts to kml, using the function:
> > st_write(sf.object, " sf.object  .kml", driver='kml')
> >
> >
> Setting styles for writing KML using GDAL/OGR is described here:
>
>
> https://gis.stackexchange.com/questions/297494/how-to-style-kml-through-libkml-layer-creation-options
>
> For example I have an sf data frame of Osprey tracking data (as points),
> and if I create a new field:
>
>
> osp$OGR_STYLE="PEN(c:#128020,w:5px)"
>
> and then:
>
> st_write(osp, "/tmp/osp.kml",driver="libkml")
>
> then the features in the KML get written with:
>
>          <LineStyle>
>             <color>ff208012</color>
>             <width>5</width>
>           </LineStyle>
>
> I realise now that "PEN" is probably wrong for point features, but it
> should all be explained in the google OGR style docs:
>
> https://www.gdal.org/ogr_feature_style.html
>
> and in the links in that GIS stack exchange question...
>
> Barry
>
>         [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: add a field to sf object and point shape in kml

Tue, 05/07/2019 - 10:06
On Tue, May 7, 2019 at 12:54 PM Marta Rufino <[hidden email]>
wrote:

> Hi,
>
> Two very simple question:
>
> 2)
> Can we change the polygon col/fill and point shape/col when exporting sf
> obejcts to kml, using the function:
> st_write(sf.object, " sf.object  .kml", driver='kml')
>
> Setting styles for writing KML using GDAL/OGR is described here:

https://gis.stackexchange.com/questions/297494/how-to-style-kml-through-libkml-layer-creation-options

For example I have an sf data frame of Osprey tracking data (as points),
and if I create a new field:


osp$OGR_STYLE="PEN(c:#128020,w:5px)"

and then:

st_write(osp, "/tmp/osp.kml",driver="libkml")

then the features in the KML get written with:

         <LineStyle>
            <color>ff208012</color>
            <width>5</width>
          </LineStyle>

I realise now that "PEN" is probably wrong for point features, but it
should all be explained in the google OGR style docs:

https://www.gdal.org/ogr_feature_style.html

and in the links in that GIS stack exchange question...

Barry

        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: add a field to sf object and point shape in kml

Tue, 05/07/2019 - 09:53
On Tue, May 7, 2019 at 12:54 PM Marta Rufino <[hidden email]>
wrote:

> Hi,
>
> Two very simple question:
>
> 1)
> What is the best way to add a variable (field) to an sf object?
>
> # For example, if I do:
> (a = st_sf(a=1, geom = st_sfc(st_point(0:1))))
> # I would expect this would work, and it does, but then it makes some kind
> of a nested structure which I cannot work with properly.
>
What you've got there is an "sf data frame":

 > a = st_sf(a=1, geom = st_sfc(st_point(0:1)))
 > class(a)
 [1] "sf"         "data.frame"

 I'm not sure why you think its a "nested structure" - it mostly works like
a data frame but with a special column (called `geom`) that stores geometry
objects.


# Is this the proper way to add fields or there s another one?
> a$b = 2
>

that's how you add columns to a plain data frame, so that's how you add
columns to an sf data frame!


> a
> # you can see that the second field is after the geometry, which shows it
> is nested.
>
>  column order is irrelevant in plain data frames, so its irrelevant in sf
data frames!  The geometry can come first if you want:

 > a[,c("geom","a")]

is an equally valid sf data frame.

Strictly you should use the `st_geometry` function to get the geometry
column of an sf data frame, since it could be called `geom`, `geometry`,
`the_geom`, or anything really. For example:

copy the geom column to a new column (standard data frame ops)

a$foo = a$geom

tell `a` its geometry is in the `foo` column:

st_geometry(a) = "foo"

delete the `geom` column (standard data frame op)

a$geom=NULL

and now:

> a
Simple feature collection with 1 feature and 1 field
geometry type:  POINT
dimension:      XY
bbox:           xmin: 0 ymin: 1 xmax: 0 ymax: 1
epsg (SRID):    NA
proj4string:    NA
  a         foo
1 1 POINT (0 1)

now `a` is an sf data frame with a geometry column called `foo`.



> 2)
> Can we change the polygon col/fill and point shape/col when exporting sf
> obejcts to kml, using the function:
> st_write(sf.object, " sf.object  .kml", driver='kml')
>
>
Hmmm not sure. What do you get if you try and read a KML with those
attributes set?



>
> Thank you very much in advance,
> Best wishes,
> M.
>
> ------
> My first steps in sf: https://rpubs.com/MRufino/488297
>
>         [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: add a field to sf object and point shape in kml

Tue, 05/07/2019 - 07:16
Dear Marta,

I have answer only to your first question.
The way you created the new column (a$b = 2) is correct.
The order of the columns and the place of the geometry column are
usually not so important, but if you want to rearrange the columns, just
use one of the following lines:
a <- a[, c(colnames(a)[!(colnames(a) %in% attr(a, "sf_column"))],
attr(a, "sf_column"))]
a <- st_sf(cbind(st_set_geometry(a, NULL), st_geometry(a)))

HTH,
Ákos Bede-Fazekas
Hungarian Academy of Sciences


2019.05.07. 13:54 keltezéssel, Marta Rufino írta:
> Hi,
>
> Two very simple question:
>
> 1)
> What is the best way to add a variable (field) to an sf object?
>
> # For example, if I do:
> (a = st_sf(a=1, geom = st_sfc(st_point(0:1))))
> # I would expect this would work, and it does, but then it makes some kind
> of a nested structure which I cannot work with properly.
> # Is this the proper way to add fields or there s another one?
> a$b = 2
> a
> # you can see that the second field is after the geometry, which shows it
> is nested.
>
> 2)
> Can we change the polygon col/fill and point shape/col when exporting sf
> obejcts to kml, using the function:
> st_write(sf.object, " sf.object  .kml", driver='kml')
>
>
> Thank you very much in advance,
> Best wishes,
> M.
>
> ------
> My first steps in sf: https://rpubs.com/MRufino/488297
>
> [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

add a field to sf object and point shape in kml

Tue, 05/07/2019 - 06:54
Hi,

Two very simple question:

1)
What is the best way to add a variable (field) to an sf object?

# For example, if I do:
(a = st_sf(a=1, geom = st_sfc(st_point(0:1))))
# I would expect this would work, and it does, but then it makes some kind
of a nested structure which I cannot work with properly.
# Is this the proper way to add fields or there s another one?
a$b = 2
a
# you can see that the second field is after the geometry, which shows it
is nested.

2)
Can we change the polygon col/fill and point shape/col when exporting sf
obejcts to kml, using the function:
st_write(sf.object, " sf.object  .kml", driver='kml')


Thank you very much in advance,
Best wishes,
M.

------
My first steps in sf: https://rpubs.com/MRufino/488297

        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Pages