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: 2 min 21 sec ago

Re: Question about HSAR package

Thu, 09/27/2018 - 14:57
This code tells nothing, the problem is in your construction of W, M and/or Delta. Pleaseng show this code too, best as a reproducible example. Tip: sometimes running traceback() after an error shows where it happens.

Roger Bivand
Norwegian School of Economics
Bergen, Norway

Fra: Justin Schon
Sendt: torsdag 27. september, 21.36
Emne: [R-sig-Geo] Question about HSAR package
Til: [hidden email]


Dear all, I am receiving the error "not an S4 object" when I attempt to estimate the hierarchal spatial auto-regressive model from the HSAR package. I have attempted several ways of creating the lower level matrix and higher level matrix. Rather than asking if members of this list can help with the code, I am first wondering if anyone can explain why this error would appear. I am including the code that estimates the model, as well as the error, below: > HSAR.model1

        [[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

Question about HSAR package

Thu, 09/27/2018 - 14:35
Dear all,

I am receiving the error "not an S4 object" when I attempt to estimate the
hierarchal spatial auto-regressive model from the HSAR package. I have
attempted several ways of creating the lower level matrix and higher level
matrix. Rather than asking if members of this list can help with the code,
I am first wondering if anyone can explain why this error would appear.

I am including the code that estimates the model, as well as the error,
below:

> HSAR.model1<- hsar(Count_ ~ ndc_pres_3
+                    + volatility + turnout_21
+                    + volatili_1 + X20160526_6
+                    + DENSITY_RD + Count_3
+                    + MEAN + pov_p_2008
+                    + gini_2008 + ferat_2008
+                    + Count_4 + literacy
+                    + grid_perCa, data=constit, W=W.constit,
+                    M=W.dist, Delta = Delta.mat,
+                    burnin = 5000, Nsim = 10000,
+                    thinning = 1, parameters.start = NULL)
Error in hsar(Count_ ~ ndc_pres_3 + volatility + turnout_21 + volatili_1 +
:
  not an S4 object


Again, I am not looking for advice with the code right now. I am wondering
what kinds of problems could cause this error message.

As a note, I receive the same error message when I try to estimate an sar
model and when I simplify the model down to one independent variable.

I greatly appreciate any ideas that members of this list might have.

Thank you,

Justin





--
Justin Schon
Post-Doctoral Researcher on Environmental Change and Migration
MURI Migration Research Team: http://murimigration.org/
University of Florida
Fellow, Initiative for Sustainable Energy Policy (ISEP)

        [[alternative HTML version deleted]]

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

Subsample (and or aggregation) of spatio temporal data (by using spatio temporal grid)

Thu, 09/27/2018 - 13:09
Hi,
I would like to know of it exists some function or method to subsumple (by
which I mean define a spatio temporal or a general 3D grid and substitute
all data which fall in one grid cell (in this case one grid cube, with
defined dimensions), with a reference data from the ones which fall in the
cube itself or with their mean,...)
Is it be possible to do such process?
If yes, it could be useful use a spatio temporal or a general 3D grid or
also other methods can be used?

Kind regards.

        [[alternative HTML version deleted]]

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

Re: Create Kernel image results in *tif format

Thu, 09/27/2018 - 07:22
Thank you very much Florian,

Solve my problem!!

Best wishes,

Alexandre

--
======================================================================
Alexandre dos Santos
Proteção Florestal
IFMT - Instituto Federal de Educação, Ciência e Tecnologia de Mato Grosso
Campus Cáceres
Caixa Postal 244
Avenida dos Ramires, s/n
Bairro: Distrito Industrial
Cáceres - MT                      CEP: 78.200-000
Fone: (+55) 65 99686-6970 (VIVO) (+55) 65 3221-2674 (FIXO)

         [hidden email]
Lattes: http://lattes.cnpq.br/1360403201088680
OrcID: orcid.org/0000-0001-8232-6722
Researchgate: www.researchgate.net/profile/Alexandre_Santos10
LinkedIn: br.linkedin.com/in/alexandre-dos-santos-87961635
Mendeley:www.mendeley.com/profiles/alexandre-dos-santos6/
======================================================================

Em 27/09/2018 04:01, Florian Betz escreveu:
> Dear Alexandre,
>
> instead of converting the image to a SpatialPixelDataFrame converting
> to a raster object might be an alternative.
>
> r_pines<-raster(d_pines)
> writeRaster(r_pines, "Pines.tif")
>
> Regards,
> Florian
>
> Am 26.09.2018 um 22:25 schrieb ASANTOS via R-sig-Geo:
>> Dear R-sig-geo Members,
>>
>>       I've like to create Kernel image results as *tif using an
>> object of
>> density() function output in spatstat package. But in my example,
>> doesn't work when I try:
>>
>> #Packages
>> library(spatstat)
>> library(raster)
>> library(rgdal)
>>
>>
>> #Swedishpines's data set in spatstat package
>> data(swedishpines)
>> plot(swedishpines)
>>
>> #CSR with K-Ripley test
>> csr_pines <- envelope(swedishpines, Kest, nsim=99)
>> plot(csr_pines)
>> # r=0.75 is outside CSR
>>
>> #Kernel representation using 0.75 as bandwidth
>> d_pines<-density(swedishpines, bw=0.75)
>> plot(d_pines)
>>
>> #Create TIFF image
>> r_pines <- as(d_pines, "SpatialPixelsDataFrame")
>> writeGDAL(r_pines, "Pines.tif")
>> #
>>
>>> r_pines <- as(d_pines, "SpatialPixelsDataFrame") Error in as(d_pines,
>> "SpatialPixelsDataFrame") : no method or default for coercing “im” to
>> “SpatialPixelsDataFrame”
>>
>> Please any ideas for corrected this?
>>
>> Thanks in advanced,
>>
>> Alexandre
>>
>
_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: Create Kernel image results in *tif format

Thu, 09/27/2018 - 03:51
Dear Alexandre,

Indeed the solution by Florian below is very nice. If you really want to
go the other direction you can use `as.SpatialGridDataFrame.im()` from
the `maptools` package.

By the way, based on what you write, I think you mean to use the value
7.5 (=0.75m) rather than 0.75 (=0.075 m) for your kernel bandwidth.
Furthermore, the argument to set the standard deviation of the
(isotropic Gaussian) smoothing kernel in `density.ppp()` is `sigma`, so
you probably want:
     d_pines <- density(swedishpines, sigma = 7.5)

If you like to work in meters rather than decimeters you can rescale the
point pattern:
     pines <- rescale(swedishpines, s = 10, unitname = "m")
     d_pines <- density(pines, sigma = 0.75)

Regards,
Ege


On 09/27/2018 10:01 AM, Florian Betz wrote:
> Dear Alexandre,
>
> instead of converting the image to a SpatialPixelDataFrame converting to
> a raster object might be an alternative.
>
> r_pines<-raster(d_pines)
> writeRaster(r_pines, "Pines.tif")
>
> Regards,
> Florian
>
> Am 26.09.2018 um 22:25 schrieb ASANTOS via R-sig-Geo:
>> Dear R-sig-geo Members,
>>
>>       I've like to create Kernel image results as *tif using an object of
>> density() function output in spatstat package. But in my example,
>> doesn't work when I try:
>>
>> #Packages
>> library(spatstat)
>> library(raster)
>> library(rgdal)
>>
>>
>> #Swedishpines's data set in spatstat package
>> data(swedishpines)
>> plot(swedishpines)
>>
>> #CSR with K-Ripley test
>> csr_pines <- envelope(swedishpines, Kest, nsim=99)
>> plot(csr_pines)
>> # r=0.75 is outside CSR
>>
>> #Kernel representation using 0.75 as bandwidth
>> d_pines<-density(swedishpines, bw=0.75)
>> plot(d_pines)
>>
>> #Create TIFF image
>> r_pines <- as(d_pines, "SpatialPixelsDataFrame")
>> writeGDAL(r_pines, "Pines.tif")
>> #
>>
>>> r_pines <- as(d_pines, "SpatialPixelsDataFrame") Error in as(d_pines,
>> "SpatialPixelsDataFrame") : no method or default for coercing “im” to
>> “SpatialPixelsDataFrame”
>>
>> Please any ideas for corrected this?
>>
>> Thanks in advanced,
>>
>> Alexandre
>>
>
_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: Create Kernel image results in *tif format

Thu, 09/27/2018 - 03:01
Dear Alexandre,

instead of converting the image to a SpatialPixelDataFrame converting to
a raster object might be an alternative.

r_pines<-raster(d_pines)
writeRaster(r_pines, "Pines.tif")

Regards,
Florian

Am 26.09.2018 um 22:25 schrieb ASANTOS via R-sig-Geo:
> Dear R-sig-geo Members,
>
>       I've like to create Kernel image results as *tif using an object of
> density() function output in spatstat package. But in my example,
> doesn't work when I try:
>
> #Packages
> library(spatstat)
> library(raster)
> library(rgdal)
>
>
> #Swedishpines's data set in spatstat package
> data(swedishpines)
> plot(swedishpines)
>
> #CSR with K-Ripley test
> csr_pines <- envelope(swedishpines, Kest, nsim=99)
> plot(csr_pines)
> # r=0.75 is outside CSR
>
> #Kernel representation using 0.75 as bandwidth
> d_pines<-density(swedishpines, bw=0.75)
> plot(d_pines)
>
> #Create TIFF image
> r_pines <- as(d_pines, "SpatialPixelsDataFrame")
> writeGDAL(r_pines, "Pines.tif")
> #
>
>> r_pines <- as(d_pines, "SpatialPixelsDataFrame") Error in as(d_pines,
> "SpatialPixelsDataFrame") : no method or default for coercing “im” to
> “SpatialPixelsDataFrame”
>
> Please any ideas for corrected this?
>
> Thanks in advanced,
>
> Alexandre
>
--
Florian Betz
Gartenstraße 13
86152 Augsburg, Deutschland

Tel.: 0176 20344096
Mail: [hidden email]

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

Create Kernel image results in *tif format

Wed, 09/26/2018 - 15:25
Dear R-sig-geo Members,

     I've like to create Kernel image results as *tif using an object of
density() function output in spatstat package. But in my example,
doesn't work when I try:

#Packages
library(spatstat)
library(raster)
library(rgdal)


#Swedishpines's data set in spatstat package
data(swedishpines)
plot(swedishpines)

#CSR with K-Ripley test
csr_pines <- envelope(swedishpines, Kest, nsim=99)
plot(csr_pines)
# r=0.75 is outside CSR

#Kernel representation using 0.75 as bandwidth
d_pines<-density(swedishpines, bw=0.75)
plot(d_pines)

#Create TIFF image
r_pines <- as(d_pines, "SpatialPixelsDataFrame")
writeGDAL(r_pines, "Pines.tif")
#

> r_pines <- as(d_pines, "SpatialPixelsDataFrame") Error in as(d_pines,
"SpatialPixelsDataFrame") : no method or default for coercing “im” to
“SpatialPixelsDataFrame”

Please any ideas for corrected this?

Thanks in advanced,

Alexandre

--
======================================================================
Alexandre dos Santos
Proteção Florestal
IFMT - Instituto Federal de Educação, Ciência e Tecnologia de Mato Grosso
Campus Cáceres
Caixa Postal 244
Avenida dos Ramires, s/n
Bairro: Distrito Industrial
Cáceres - MT                      CEP: 78.200-000
Fone: (+55) 65 99686-6970 (VIVO) (+55) 65 3221-2674 (FIXO)

         [hidden email]
Lattes: http://lattes.cnpq.br/1360403201088680
OrcID: orcid.org/0000-0001-8232-6722
Researchgate: www.researchgate.net/profile/Alexandre_Santos10
LinkedIn: br.linkedin.com/in/alexandre-dos-santos-87961635
Mendeley:www.mendeley.com/profiles/alexandre-dos-santos6/
======================================================================


        [[alternative HTML version deleted]]

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

Re: SPDE book for Bayesian spatio-temporal modeling

Wed, 09/26/2018 - 11:39
On Wed, 26 Sep 2018, Virgilio Gomez Rubio wrote:

> I am happy to announce the forthcoming book “Advanced Spatial Modeling
> with Stochastic Partial Differential Equations Using R and INLA”. We have
> a web page at  http://www.r-inla.org/spde-book with more information, R
> code and datasets, and a online (free) Gitbook version. We hope that this
> will be a useful resource to those of you interested in Bayesian spatial
> and spatio-temporal modeling. We’d like to thank CRC for agreeing to have
> a free version of the book on-line.

Virgilio,

   Looks interesting. Perhaps I can afford the dead tree edition when it
comes out. :-)

Best regards,

Rich

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

SPDE book for Bayesian spatio-temporal modeling

Wed, 09/26/2018 - 11:30
Dear all,

I am happy to announce the forthcoming book “Advanced Spatial Modeling with Stochastic Partial Differential Equations Using R and INLA”. We have a web page at  http://www.r-inla.org/spde-book with more information, R code and datasets, and a online (free) Gitbook version. We hope that this will be a useful resource to those of you interested in Bayesian spatial and spatio-temporal modeling. We’d like to thank CRC for agreeing to have a free version of the book on-line.

Best,

Virgilio

        [[alternative HTML version deleted]]

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

Re: spatial temporal data

Wed, 09/26/2018 - 01:35
Hi!

I’m testing out a faster Kriging function that I developed.

Location doesn’t matter.  I need it to be “regular”, in the sense of having
n locations with m observations and a total size of n*m.

Thanks,
Erin

On Tue, Sep 25, 2018 at 11:26 PM Thomas Adams <[hidden email]> wrote:

> Hi Erin,
>
> Are you interested in point or gridded data and does location or variable
> type matter? What are you doing?
>
> Tom
>
> On Tue, Sep 25, 2018 at 11:03 PM Erin Hodgess <[hidden email]>
> wrote:
>
>> Hello everyone:
>>
>> Could someone recommend a good source for spatial temporal data from the
>> "real world", please?
>>
>> I have been using the Irish wind data for something that I'm working on,
>> and would like to have a nice data set for extra practice.
>>
>> Thanks,
>> Erin
>>
>>
>> Erin Hodgess, PhD
>> mailto: [hidden email]
>>
>>         [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> [hidden email]
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>
>
>
> -- Erin Hodgess, PhD
mailto: [hidden email]

        [[alternative HTML version deleted]]

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

Re: spatial temporal data

Wed, 09/26/2018 - 00:25
Hi Erin,

Are you interested in point or gridded data and does location or variable
type matter? What are you doing?

Tom

On Tue, Sep 25, 2018 at 11:03 PM Erin Hodgess <[hidden email]>
wrote:

> Hello everyone:
>
> Could someone recommend a good source for spatial temporal data from the
> "real world", please?
>
> I have been using the Irish wind data for something that I'm working on,
> and would like to have a nice data set for extra practice.
>
> Thanks,
> Erin
>
>
> Erin Hodgess, PhD
> mailto: [hidden email]
>
>         [[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

spatial temporal data

Tue, 09/25/2018 - 22:02
Hello everyone:

Could someone recommend a good source for spatial temporal data from the
"real world", please?

I have been using the Irish wind data for something that I'm working on,
and would like to have a nice data set for extra practice.

Thanks,
Erin


Erin Hodgess, PhD
mailto: [hidden email]

        [[alternative HTML version deleted]]

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

Identify hotspots (centroid/geometric center when CSR distance is not satisfied) using K-Ripley approach

Tue, 09/25/2018 - 20:49
Dear R-sig-geo Members,

         I've like to identify hotspots points (centroid/geometric
center of distances(r) when CSR is not satisfied), in my study case,
centroids with points around 0.75 radius. This thinking in the map
representation, for this objective I make:

#Package
library(spatstat)
library(sp)
library(cluster)
library(lattice)

#Swedishpines's data set in spatstat package
data(swedishpines)
plot(swedishpines)

#CSR with K-Ripley test
csr_pines <- envelope(swedishpines, Kest, nsim=99)
plot(csr_pines)
# r=0.75 is outside CSR assumption, than:

##Create matrix distance of all points
coords<-cbind(swedishpines$x,swedishpines$y)
res<-spDists(coords)
res <- data.frame(res)

# Cluster 0.75m distances
clusters <- as.hclust(agnes(res, diss = T))
coords$group <- cutree(clusters, h=0.75) ## Radius 0.75
#

#Visualization of centroids with points around 0.75 radius
xyplot(x~y, group = group, data = coords)
points(swedishpines$x,swedishpines$y, pch=16)
#

Doesn't work, please any ideas or new approaches?

Thanks in advanced,

Alexandre

--
======================================================================
Alexandre dos Santos
Proteção Florestal
IFMT - Instituto Federal de Educação, Ciência e Tecnologia de Mato Grosso
Campus Cáceres
Caixa Postal 244
Avenida dos Ramires, s/n
Bairro: Distrito Industrial
Cáceres - MT                      CEP: 78.200-000
Fone: (+55) 65 99686-6970 (VIVO) (+55) 65 3221-2674 (FIXO)

         [hidden email]
Lattes: http://lattes.cnpq.br/1360403201088680
OrcID: orcid.org/0000-0001-8232-6722
Researchgate: www.researchgate.net/profile/Alexandre_Santos10
LinkedIn: br.linkedin.com/in/alexandre-dos-santos-87961635
Mendeley:www.mendeley.com/profiles/alexandre-dos-santos6/

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

Re: Adding colour to polylines in Leaflet

Tue, 09/25/2018 - 00:50
@Kent Johnson <[hidden email]> thank you so much for this. It does take
a bit of time to compute, but works nonetheless. Thanks again, appreciate!
Regards

Dhiraj Khanna
Mob:09873263331


On Sun, Sep 23, 2018 at 7:12 PM Kent Johnson <[hidden email]> wrote:

> Another approach is to draw individual line segments instead of polylines.
> Here is one way; maybe there is a more elegant way to construct the
> segments but this works...
>
> library(tidyverse)
> library(sf)
> x = x %>% mutate(lat2=lead(lat, default=tail(lat, 1)),
>                  lon2=lead(lon, default=tail(lon, 1))) %>%
>   mutate(segment = st_sfc(crs=4326,
>               pmap(.,
>                  function(lat, lon, lat2, lon2, ...)
>                    st_linestring(matrix(c(lon, lat, lon2, lat2),
>                                         byrow=TRUE, ncol=2)))))
>
> leaflet(x$segment) %>%
>   addTiles() %>%
>   addPolylines(color=x$Color)
>
> Kent
>
> On Sat, Sep 22, 2018 at 2:00 PM Kent Johnson <[hidden email]> wrote:
>
>> Your problem is not really a leaflet problem, it is about identifying
>> runs in your data. This should help:
>> https://stackoverflow.com/q/43875716/80626
>>
>> Kent
>>
>> On Sat, Sep 22, 2018 at 12:22 PM Dhiraj Khanna <[hidden email]>
>> wrote:
>>
>>> @Kent Johnson <[hidden email]> guess I jumped the gun!
>>>
>>> Your code worked like a charm as long as the colours were all in order,
>>> ie, none of them are repeating.
>>> Like I mentioned, I am working with shipping data and the Color
>>> variable is dependent on the ship’s speed. The code that you provided joins
>>> all the line segments which have the same color.
>>> So if red represents a speed less than 3 knots, then it will join all
>>> the points irrespective of the timeline wherever the color is red.
>>>
>>> What I am looking for is one continuous path where the same color might
>>> repeat. Here’s a reproducible example:
>>>
>>> library(leaflet)
>>> x <- structure(list(lat = c(51.88783, 51.8878441, 51.887825, 51.88659,  51.8866959, 51.8874931, 51.89359, 51.8941269, 51.8977051, 51.8994331,  51.90773, 51.91324, 51.91604, 51.9216652, 51.93353, 51.9419365 ),
>>>                      lon = c(4.28763342, 4.287635, 4.28765154, 4.29007339, 4.29562664,  4.29917, 4.30641174, 4.30561829, 4.29263353, 4.284498, 4.261132,  4.24711847, 4.241075, 4.23262, 4.21523666, 4.1927),
>>>                      rateOfTurn = c(0L,  0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L),
>>>                      sogKts = c(0, 0, 0, 2.1, 3.4, 4.6, 3.5, 3.8, 7.4, 7.9, 8.8,9.1, 9.2, 9.2, 0.3, 0.4),
>>>                      cog = c(15, 15, 15, 122.2, 70.4,      70, 323.2, 315.3, 289.3, 290.9, 303.8, 303.7, 308.9, 324.5, 304.9, 301.4),
>>>                      heading = c(163, 162, 163, 106, 71, 71, 303,      298, 289, 294, 303, 303, 310, 324, 304, 302),
>>>                      timestamp = c("2018-07-19T05:27:34","2018-07-19T05:39:35", "2018-07-19T05:45:34", "2018-07-19T05:57:37",
>>>                                    "2018-07-19T06:02:48", "2018-07-19T06:04:49", "2018-07-19T06:12:51", "2018-07-19T06:13:32",
>>>                                    "2018-07-19T06:19:08", "2018-07-19T06:21:41",      "2018-07-19T06:28:42", "2018-07-19T06:32:50",
>>>                                    "2018-07-19T06:34:37",      "2018-07-19T06:37:41", "2018-07-19T06:43:49", "2018-07-19T06:50:09"),
>>>                      Color = c("red", "red", "red", "red", "orange", "orange","orange", "orange", "orange", "orange", "yellow", "yellow",
>>>                                "yellow", "yellow", "red", "red")), row.names = 32:47, class = "data.frame")
>>>
>>> #Kent's code
>>>
>>> x$lastColor = dplyr::lag(x$Color)
>>> map <-  leaflet(x)
>>> map <- addTiles(map)
>>> for( Color in
>>>      levels(as.factor(x$Color))){
>>>   map <- addPolylines(map,lng=~lon,lat=~lat,data=x[x$Color==Color | x$lastColor==Color,], color=~Color) }
>>> map
>>>
>>> As you can see, the last two observations are again in red color. But
>>> when the map renders, it joins the last two observations with the first
>>> three.
>>>
>>> I am not sure what to do here? Inserting a row of NAs would help? But I
>>> am also using another javascript plugin (polylineDecorator) for adding
>>> arrows to the direction of travel and that is intolerant to NAs.
>>> Appreciate some help here.
>>>
>>>
>>> Regards
>>> Dhiraj Khanna
>>> Mob:09873263331
>>>
>>> On Sat, Sep 1, 2018 at 8:06 PM Dhiraj Khanna <[hidden email]>
>>> wrote:
>>>
>>>> Thank you Kent, that worked like a charm!
>>>> Regards
>>>>
>>>> Dhiraj Khanna
>>>> Mob:09873263331
>>>>
>>>>
>>>> On Sat, Sep 1, 2018 at 7:59 PM Kent Johnson <[hidden email]> wrote:
>>>>
>>>>> You have to include the points where the colors change in both
>>>>> polylines. Here is one way:
>>>>>
>>>>> x$lastColor = dplyr::lag(x$Color)
>>>>> map <-  leaflet(x)
>>>>> map <- addTiles(map)
>>>>> for( Color in
>>>>> levels(as.factor(x$Color))){
>>>>>   map <- addPolylines(map,lng=~lon,lat=~lat,data=x[x$Color==Color |
>>>>> x$lastColor==Color,], color=~Color) }
>>>>> map
>>>>>
>>>>> Kent
>>>>>
>>>>> On Sat, Sep 1, 2018 at 8:56 AM, Dhiraj Khanna <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> @Kent they are appearing as three separate lines. I am hoping to see
>>>>>> them joint with no gaps. The transition from row 4 to row 5 is where the
>>>>>> speed has changed from 2.1 knots to 3.4 knots. I am hoping to see another
>>>>>> line from row 4 to row 5 in red colour. Similarly for the other disjoint
>>>>>> points.
>>>>>> Regards
>>>>>>
>>>>>> Dhiraj Khanna
>>>>>> Mob:09873263331
>>>>>>
>>>>>>
>>>>>> On Sat, Sep 1, 2018 at 6:17 PM Kent Johnson <[hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>>> Message: 5
>>>>>>>> Date: Sat, 1 Sep 2018 08:28:24 +0530
>>>>>>>> From: Dhiraj Khanna <[hidden email]>
>>>>>>>> To: [hidden email]
>>>>>>>> Subject: [R-sig-Geo] Adding colour to polylines in Leaflet
>>>>>>>> Message-ID:
>>>>>>>>         <
>>>>>>>> [hidden email]>
>>>>>>>> Content-Type: text/plain; charset="utf-8"
>>>>>>>>
>>>>>>>> I am working with shipping data where I get the dynamic parameters
>>>>>>>> of a
>>>>>>>> ship like its position, speed, heading and rate of turn. I am then
>>>>>>>> trying
>>>>>>>> to plot this on a leaflet map and trying to colour the polylines
>>>>>>>> based on
>>>>>>>> the speed, but it always shows up in the same colour. Here’s some
>>>>>>>> sample
>>>>>>>> data:
>>>>>>>>
>>>>>>>> <snip>
>>>>>>>> This is the code I have tried which doesn’t work:-
>>>>>>>>
>>>>>>>> map <-  leaflet(x) map <- addTiles(map) for( Color in
>>>>>>>> levels(as.factor(x$Color))){   map <- addPolylines(map,
>>>>>>>> lng=~lon,lat=~lat,data=x[x$Color==Color,], color=~Color) } map
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Dhiraj Khanna
>>>>>>>> Mob:09873263331
>>>>>>>
>>>>>>>
>>>>>>> What are you expecting to see? When I run your code I get a map with
>>>>>>> three lines, one red, one orange and one yellow.
>>>>>>>
>>>>>>> Kent
>>>>>>>
>>>>>>>
>>>>>
        [[alternative HTML version deleted]]

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

Re: Adding colour to polylines in Leaflet

Sun, 09/23/2018 - 08:42
Another approach is to draw individual line segments instead of polylines.
Here is one way; maybe there is a more elegant way to construct the
segments but this works...

library(tidyverse)
library(sf)
x = x %>% mutate(lat2=lead(lat, default=tail(lat, 1)),
                 lon2=lead(lon, default=tail(lon, 1))) %>%
  mutate(segment = st_sfc(crs=4326,
              pmap(.,
                 function(lat, lon, lat2, lon2, ...)
                   st_linestring(matrix(c(lon, lat, lon2, lat2),
                                        byrow=TRUE, ncol=2)))))

leaflet(x$segment) %>%
  addTiles() %>%
  addPolylines(color=x$Color)

Kent

On Sat, Sep 22, 2018 at 2:00 PM Kent Johnson <[hidden email]> wrote:

> Your problem is not really a leaflet problem, it is about identifying runs
> in your data. This should help: https://stackoverflow.com/q/43875716/80626
>
> Kent
>
> On Sat, Sep 22, 2018 at 12:22 PM Dhiraj Khanna <[hidden email]>
> wrote:
>
>> @Kent Johnson <[hidden email]> guess I jumped the gun!
>>
>> Your code worked like a charm as long as the colours were all in order,
>> ie, none of them are repeating.
>> Like I mentioned, I am working with shipping data and the Color variable
>> is dependent on the ship’s speed. The code that you provided joins all the
>> line segments which have the same color.
>> So if red represents a speed less than 3 knots, then it will join all the
>> points irrespective of the timeline wherever the color is red.
>>
>> What I am looking for is one continuous path where the same color might
>> repeat. Here’s a reproducible example:
>>
>> library(leaflet)
>> x <- structure(list(lat = c(51.88783, 51.8878441, 51.887825, 51.88659,  51.8866959, 51.8874931, 51.89359, 51.8941269, 51.8977051, 51.8994331,  51.90773, 51.91324, 51.91604, 51.9216652, 51.93353, 51.9419365 ),
>>                      lon = c(4.28763342, 4.287635, 4.28765154, 4.29007339, 4.29562664,  4.29917, 4.30641174, 4.30561829, 4.29263353, 4.284498, 4.261132,  4.24711847, 4.241075, 4.23262, 4.21523666, 4.1927),
>>                      rateOfTurn = c(0L,  0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L),
>>                      sogKts = c(0, 0, 0, 2.1, 3.4, 4.6, 3.5, 3.8, 7.4, 7.9, 8.8,9.1, 9.2, 9.2, 0.3, 0.4),
>>                      cog = c(15, 15, 15, 122.2, 70.4,      70, 323.2, 315.3, 289.3, 290.9, 303.8, 303.7, 308.9, 324.5, 304.9, 301.4),
>>                      heading = c(163, 162, 163, 106, 71, 71, 303,      298, 289, 294, 303, 303, 310, 324, 304, 302),
>>                      timestamp = c("2018-07-19T05:27:34","2018-07-19T05:39:35", "2018-07-19T05:45:34", "2018-07-19T05:57:37",
>>                                    "2018-07-19T06:02:48", "2018-07-19T06:04:49", "2018-07-19T06:12:51", "2018-07-19T06:13:32",
>>                                    "2018-07-19T06:19:08", "2018-07-19T06:21:41",      "2018-07-19T06:28:42", "2018-07-19T06:32:50",
>>                                    "2018-07-19T06:34:37",      "2018-07-19T06:37:41", "2018-07-19T06:43:49", "2018-07-19T06:50:09"),
>>                      Color = c("red", "red", "red", "red", "orange", "orange","orange", "orange", "orange", "orange", "yellow", "yellow",
>>                                "yellow", "yellow", "red", "red")), row.names = 32:47, class = "data.frame")
>>
>> #Kent's code
>>
>> x$lastColor = dplyr::lag(x$Color)
>> map <-  leaflet(x)
>> map <- addTiles(map)
>> for( Color in
>>      levels(as.factor(x$Color))){
>>   map <- addPolylines(map,lng=~lon,lat=~lat,data=x[x$Color==Color | x$lastColor==Color,], color=~Color) }
>> map
>>
>> As you can see, the last two observations are again in red color. But
>> when the map renders, it joins the last two observations with the first
>> three.
>>
>> I am not sure what to do here? Inserting a row of NAs would help? But I
>> am also using another javascript plugin (polylineDecorator) for adding
>> arrows to the direction of travel and that is intolerant to NAs.
>> Appreciate some help here.
>>
>>
>> Regards
>> Dhiraj Khanna
>> Mob:09873263331
>>
>> On Sat, Sep 1, 2018 at 8:06 PM Dhiraj Khanna <[hidden email]>
>> wrote:
>>
>>> Thank you Kent, that worked like a charm!
>>> Regards
>>>
>>> Dhiraj Khanna
>>> Mob:09873263331
>>>
>>>
>>> On Sat, Sep 1, 2018 at 7:59 PM Kent Johnson <[hidden email]> wrote:
>>>
>>>> You have to include the points where the colors change in both
>>>> polylines. Here is one way:
>>>>
>>>> x$lastColor = dplyr::lag(x$Color)
>>>> map <-  leaflet(x)
>>>> map <- addTiles(map)
>>>> for( Color in
>>>> levels(as.factor(x$Color))){
>>>>   map <- addPolylines(map,lng=~lon,lat=~lat,data=x[x$Color==Color |
>>>> x$lastColor==Color,], color=~Color) }
>>>> map
>>>>
>>>> Kent
>>>>
>>>> On Sat, Sep 1, 2018 at 8:56 AM, Dhiraj Khanna <[hidden email]>
>>>> wrote:
>>>>
>>>>> @Kent they are appearing as three separate lines. I am hoping to see
>>>>> them joint with no gaps. The transition from row 4 to row 5 is where the
>>>>> speed has changed from 2.1 knots to 3.4 knots. I am hoping to see another
>>>>> line from row 4 to row 5 in red colour. Similarly for the other disjoint
>>>>> points.
>>>>> Regards
>>>>>
>>>>> Dhiraj Khanna
>>>>> Mob:09873263331
>>>>>
>>>>>
>>>>> On Sat, Sep 1, 2018 at 6:17 PM Kent Johnson <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> Message: 5
>>>>>>> Date: Sat, 1 Sep 2018 08:28:24 +0530
>>>>>>> From: Dhiraj Khanna <[hidden email]>
>>>>>>> To: [hidden email]
>>>>>>> Subject: [R-sig-Geo] Adding colour to polylines in Leaflet
>>>>>>> Message-ID:
>>>>>>>         <
>>>>>>> [hidden email]>
>>>>>>> Content-Type: text/plain; charset="utf-8"
>>>>>>>
>>>>>>> I am working with shipping data where I get the dynamic parameters
>>>>>>> of a
>>>>>>> ship like its position, speed, heading and rate of turn. I am then
>>>>>>> trying
>>>>>>> to plot this on a leaflet map and trying to colour the polylines
>>>>>>> based on
>>>>>>> the speed, but it always shows up in the same colour. Here’s some
>>>>>>> sample
>>>>>>> data:
>>>>>>>
>>>>>>> <snip>
>>>>>>> This is the code I have tried which doesn’t work:-
>>>>>>>
>>>>>>> map <-  leaflet(x) map <- addTiles(map) for( Color in
>>>>>>> levels(as.factor(x$Color))){   map <- addPolylines(map,
>>>>>>> lng=~lon,lat=~lat,data=x[x$Color==Color,], color=~Color) } map
>>>>>>>
>>>>>>> Regards
>>>>>>> Dhiraj Khanna
>>>>>>> Mob:09873263331
>>>>>>
>>>>>>
>>>>>> What are you expecting to see? When I run your code I get a map with
>>>>>> three lines, one red, one orange and one yellow.
>>>>>>
>>>>>> Kent
>>>>>>
>>>>>>
>>>>
        [[alternative HTML version deleted]]

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

Re: Adding colour to polylines in Leaflet

Sat, 09/22/2018 - 13:00
Your problem is not really a leaflet problem, it is about identifying runs
in your data. This should help: https://stackoverflow.com/q/43875716/80626

Kent

On Sat, Sep 22, 2018 at 12:22 PM Dhiraj Khanna <[hidden email]>
wrote:

> @Kent Johnson <[hidden email]> guess I jumped the gun!
>
> Your code worked like a charm as long as the colours were all in order,
> ie, none of them are repeating.
> Like I mentioned, I am working with shipping data and the Color variable
> is dependent on the ship’s speed. The code that you provided joins all the
> line segments which have the same color.
> So if red represents a speed less than 3 knots, then it will join all the
> points irrespective of the timeline wherever the color is red.
>
> What I am looking for is one continuous path where the same color might
> repeat. Here’s a reproducible example:
>
> library(leaflet)
> x <- structure(list(lat = c(51.88783, 51.8878441, 51.887825, 51.88659,  51.8866959, 51.8874931, 51.89359, 51.8941269, 51.8977051, 51.8994331,  51.90773, 51.91324, 51.91604, 51.9216652, 51.93353, 51.9419365 ),
>                      lon = c(4.28763342, 4.287635, 4.28765154, 4.29007339, 4.29562664,  4.29917, 4.30641174, 4.30561829, 4.29263353, 4.284498, 4.261132,  4.24711847, 4.241075, 4.23262, 4.21523666, 4.1927),
>                      rateOfTurn = c(0L,  0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L),
>                      sogKts = c(0, 0, 0, 2.1, 3.4, 4.6, 3.5, 3.8, 7.4, 7.9, 8.8,9.1, 9.2, 9.2, 0.3, 0.4),
>                      cog = c(15, 15, 15, 122.2, 70.4,      70, 323.2, 315.3, 289.3, 290.9, 303.8, 303.7, 308.9, 324.5, 304.9, 301.4),
>                      heading = c(163, 162, 163, 106, 71, 71, 303,      298, 289, 294, 303, 303, 310, 324, 304, 302),
>                      timestamp = c("2018-07-19T05:27:34","2018-07-19T05:39:35", "2018-07-19T05:45:34", "2018-07-19T05:57:37",
>                                    "2018-07-19T06:02:48", "2018-07-19T06:04:49", "2018-07-19T06:12:51", "2018-07-19T06:13:32",
>                                    "2018-07-19T06:19:08", "2018-07-19T06:21:41",      "2018-07-19T06:28:42", "2018-07-19T06:32:50",
>                                    "2018-07-19T06:34:37",      "2018-07-19T06:37:41", "2018-07-19T06:43:49", "2018-07-19T06:50:09"),
>                      Color = c("red", "red", "red", "red", "orange", "orange","orange", "orange", "orange", "orange", "yellow", "yellow",
>                                "yellow", "yellow", "red", "red")), row.names = 32:47, class = "data.frame")
>
> #Kent's code
>
> x$lastColor = dplyr::lag(x$Color)
> map <-  leaflet(x)
> map <- addTiles(map)
> for( Color in
>      levels(as.factor(x$Color))){
>   map <- addPolylines(map,lng=~lon,lat=~lat,data=x[x$Color==Color | x$lastColor==Color,], color=~Color) }
> map
>
> As you can see, the last two observations are again in red color. But when
> the map renders, it joins the last two observations with the first three.
>
> I am not sure what to do here? Inserting a row of NAs would help? But I am
> also using another javascript plugin (polylineDecorator) for adding
> arrows to the direction of travel and that is intolerant to NAs.
> Appreciate some help here.
>
>
> Regards
> Dhiraj Khanna
> Mob:09873263331
>
> On Sat, Sep 1, 2018 at 8:06 PM Dhiraj Khanna <[hidden email]>
> wrote:
>
>> Thank you Kent, that worked like a charm!
>> Regards
>>
>> Dhiraj Khanna
>> Mob:09873263331
>>
>>
>> On Sat, Sep 1, 2018 at 7:59 PM Kent Johnson <[hidden email]> wrote:
>>
>>> You have to include the points where the colors change in both
>>> polylines. Here is one way:
>>>
>>> x$lastColor = dplyr::lag(x$Color)
>>> map <-  leaflet(x)
>>> map <- addTiles(map)
>>> for( Color in
>>> levels(as.factor(x$Color))){
>>>   map <- addPolylines(map,lng=~lon,lat=~lat,data=x[x$Color==Color |
>>> x$lastColor==Color,], color=~Color) }
>>> map
>>>
>>> Kent
>>>
>>> On Sat, Sep 1, 2018 at 8:56 AM, Dhiraj Khanna <[hidden email]>
>>> wrote:
>>>
>>>> @Kent they are appearing as three separate lines. I am hoping to see
>>>> them joint with no gaps. The transition from row 4 to row 5 is where the
>>>> speed has changed from 2.1 knots to 3.4 knots. I am hoping to see another
>>>> line from row 4 to row 5 in red colour. Similarly for the other disjoint
>>>> points.
>>>> Regards
>>>>
>>>> Dhiraj Khanna
>>>> Mob:09873263331
>>>>
>>>>
>>>> On Sat, Sep 1, 2018 at 6:17 PM Kent Johnson <[hidden email]> wrote:
>>>>
>>>>> Message: 5
>>>>>> Date: Sat, 1 Sep 2018 08:28:24 +0530
>>>>>> From: Dhiraj Khanna <[hidden email]>
>>>>>> To: [hidden email]
>>>>>> Subject: [R-sig-Geo] Adding colour to polylines in Leaflet
>>>>>> Message-ID:
>>>>>>         <
>>>>>> [hidden email]>
>>>>>> Content-Type: text/plain; charset="utf-8"
>>>>>>
>>>>>> I am working with shipping data where I get the dynamic parameters of
>>>>>> a
>>>>>> ship like its position, speed, heading and rate of turn. I am then
>>>>>> trying
>>>>>> to plot this on a leaflet map and trying to colour the polylines
>>>>>> based on
>>>>>> the speed, but it always shows up in the same colour. Here’s some
>>>>>> sample
>>>>>> data:
>>>>>>
>>>>>> <snip>
>>>>>> This is the code I have tried which doesn’t work:-
>>>>>>
>>>>>> map <-  leaflet(x) map <- addTiles(map) for( Color in
>>>>>> levels(as.factor(x$Color))){   map <- addPolylines(map,
>>>>>> lng=~lon,lat=~lat,data=x[x$Color==Color,], color=~Color) } map
>>>>>>
>>>>>> Regards
>>>>>> Dhiraj Khanna
>>>>>> Mob:09873263331
>>>>>
>>>>>
>>>>> What are you expecting to see? When I run your code I get a map with
>>>>> three lines, one red, one orange and one yellow.
>>>>>
>>>>> Kent
>>>>>
>>>>>
>>>
        [[alternative HTML version deleted]]

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

Re: Consolidated SRS database/list?

Sat, 09/22/2018 - 12:08
Though it requires Internet what about hitting the epsg.io API described
on https://github.com/klokantech/epsg.io

Thanks,
Alex

On 09/22/2018 05:23 AM, Vijay Lulla wrote:
> Alex,
> Thanks for QGIS's srs.db!  I wasn't aware of it.
>
> I currently use the spatial_ref_sys from PostGIS to create a SRS data frame
> but plan to use rgdal::make_EPSG more often.  The reason I brought this up
> is because on the lab computers (cannot install stuff on it) where I teach
> there is no PostGIS and I didn't know how to lookup EPSG codes for various
> SRS definitions from within R.  I hadn't thought of Spatialite metadata as
> a viable alternative.  So, thanks for that.  I will look into it and most
> likely use it in conjunction with make_EPSG!
>
> Finally, I am really looking forward to the consolidated SRS database from
> the gdal barn-raising effort!  This consolidated database will be
> invaluable, and of great aid/service, to the geospatial community, IMO.
> Thanks,
> Vijay.
>
> On Sat, Sep 22, 2018 at 1:22 AM Alex Mandel <[hidden email]>
> wrote:
>
>> QGIS makes one
>> https://github.com/qgis/QGIS/blob/master/resources/srs.db
>> There's some script in the build that updates it also, not without issue:
>> https://issues.qgis.org/issues/17993
>>
>> I suppose you could also dump out how PostGIS does it to Sqlite, or use
>> the Spatialite metadata table.
>> https://www.gaia-gis.it/gaia-sins/spatialite-cookbook/html/metadata.html
>>
>> But the thread mentioned that goes back to the MetaCRS mailing list is
>> probably the right place in the community to revive the discussion.
>>
>> Seems like something to encourage, and a good topic for an OSGeo
>> sponsored sprint.
>>
>> Thanks,
>> Alex
>>
>> On 09/21/2018 12:32 AM, Roger Bivand wrote:
>>> On Thu, 20 Sep 2018, Vijay Lulla wrote:
>>>
>>>> Ok, thanks!  While the page provided information about the project and
>>>> its
>>>> funding status I couldn't find the SQLite database.  Do you happen to
>>>> know
>>>> when this will be available?
>>>
>>> No more than is on that page, plus the time needed to re-write plenty of
>>> sf, lwgeom, rgdal and sp. At that stage, contributions welcome!
>>>
>>> Roger
>>>
>>>>
>>>> On Thu, Sep 20, 2018 at 1:02 PM Roger Bivand <[hidden email]>
>> wrote:
>>>>
>>>>> On Thu, 20 Sep 2018, Vijay Lulla wrote:
>>>>>
>>>>>> Dear list members,
>>>>>> A few years ago Roger Bivand posted a discussion (
>>>>>> https://stat.ethz.ch/pipermail/r-sig-geo/2015-August/023204.html )
>>>>>> about
>>>>>> consolidating SRS definitions into a SQLite database and I am
>> wondering
>>>>> if
>>>>>> there has been any development along those lines.
>>>>>
>>>>> Rather than trying this just within R, we're hoping that the GDAL
>>>>> barn-raising effort:
>>>>>
>>>>> https://gdalbarn.com/
>>>>>
>>>>> will take us there and further, and be much better than having a
>>>>> non-standard implementation.
>>>>>
>>>>> When that effort is done, we'll be open for ideas about interfacing it
>>>>> through PROJ and GDAL, which now ship with CSV files that we copy into
>>>>> Windows and MacOS binary packages (rgdal, sf, lwgeom).
>>>>>
>>>>> For now, if it helps, rgdal::make_EPSG() reads the EPSG CSV file
>> shipped
>>>>> with PROJ into the R workspace as a data.frame.
>>>>>
>>>>> Roger
>>>>>
>>>>>> Specifically, is there any consolidated collection of SRS
>>>>>> definitions in
>>>>>> R (either a data.frame or tibble or SQLite backed) that are being used
>>>>>> by geospatial packages that users can use too?  If so, can you please
>>>>>> point me to it?  If not, would it be worthwhile to have this
>>>>>> consolidated list/dataframe, maybe as part of data for one of the core
>>>>>> geospatial packages? Thanks in advance, Vijay
>>>>>>
>>>>>>       [[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]
>>>>> http://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

Re: Adding colour to polylines in Leaflet

Sat, 09/22/2018 - 11:21
@Kent Johnson <[hidden email]> guess I jumped the gun!

Your code worked like a charm as long as the colours were all in order, ie,
none of them are repeating.
Like I mentioned, I am working with shipping data and the Color variable is
dependent on the ship’s speed. The code that you provided joins all the
line segments which have the same color.
So if red represents a speed less than 3 knots, then it will join all the
points irrespective of the timeline wherever the color is red.

What I am looking for is one continuous path where the same color might
repeat. Here’s a reproducible example:

library(leaflet)
x <- structure(list(lat = c(51.88783, 51.8878441, 51.887825, 51.88659,
 51.8866959, 51.8874931, 51.89359, 51.8941269, 51.8977051, 51.8994331,
 51.90773, 51.91324, 51.91604, 51.9216652, 51.93353, 51.9419365 ),
                     lon = c(4.28763342, 4.287635, 4.28765154,
4.29007339, 4.29562664,  4.29917, 4.30641174, 4.30561829, 4.29263353,
4.284498, 4.261132,  4.24711847, 4.241075, 4.23262, 4.21523666,
4.1927),
                     rateOfTurn = c(0L,  0L, 0L, 0L, 0L, 0L, 0L, 0L,
0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L),
                     sogKts = c(0, 0, 0, 2.1, 3.4, 4.6, 3.5, 3.8, 7.4,
7.9, 8.8,9.1, 9.2, 9.2, 0.3, 0.4),
                     cog = c(15, 15, 15, 122.2, 70.4,      70, 323.2,
315.3, 289.3, 290.9, 303.8, 303.7, 308.9, 324.5, 304.9, 301.4),
                     heading = c(163, 162, 163, 106, 71, 71, 303,
298, 289, 294, 303, 303, 310, 324, 304, 302),
                     timestamp =
c("2018-07-19T05:27:34","2018-07-19T05:39:35", "2018-07-19T05:45:34",
"2018-07-19T05:57:37",
                                   "2018-07-19T06:02:48",
"2018-07-19T06:04:49", "2018-07-19T06:12:51", "2018-07-19T06:13:32",
                                   "2018-07-19T06:19:08",
"2018-07-19T06:21:41",      "2018-07-19T06:28:42",
"2018-07-19T06:32:50",
                                   "2018-07-19T06:34:37",
"2018-07-19T06:37:41", "2018-07-19T06:43:49", "2018-07-19T06:50:09"),
                     Color = c("red", "red", "red", "red", "orange",
"orange","orange", "orange", "orange", "orange", "yellow", "yellow",
                               "yellow", "yellow", "red", "red")),
row.names = 32:47, class = "data.frame")

#Kent's code

x$lastColor = dplyr::lag(x$Color)
map <-  leaflet(x)
map <- addTiles(map)
for( Color in
     levels(as.factor(x$Color))){
  map <- addPolylines(map,lng=~lon,lat=~lat,data=x[x$Color==Color |
x$lastColor==Color,], color=~Color) }
map

As you can see, the last two observations are again in red color. But when
the map renders, it joins the last two observations with the first three.

I am not sure what to do here? Inserting a row of NAs would help? But I am
also using another javascript plugin (polylineDecorator) for adding arrows
to the direction of travel and that is intolerant to NAs.
Appreciate some help here.


Regards
Dhiraj Khanna
Mob:09873263331

On Sat, Sep 1, 2018 at 8:06 PM Dhiraj Khanna <[hidden email]> wrote:

> Thank you Kent, that worked like a charm!
> Regards
>
> Dhiraj Khanna
> Mob:09873263331
>
>
> On Sat, Sep 1, 2018 at 7:59 PM Kent Johnson <[hidden email]> wrote:
>
>> You have to include the points where the colors change in both polylines.
>> Here is one way:
>>
>> x$lastColor = dplyr::lag(x$Color)
>> map <-  leaflet(x)
>> map <- addTiles(map)
>> for( Color in
>> levels(as.factor(x$Color))){
>>   map <- addPolylines(map,lng=~lon,lat=~lat,data=x[x$Color==Color |
>> x$lastColor==Color,], color=~Color) }
>> map
>>
>> Kent
>>
>> On Sat, Sep 1, 2018 at 8:56 AM, Dhiraj Khanna <[hidden email]>
>> wrote:
>>
>>> @Kent they are appearing as three separate lines. I am hoping to see
>>> them joint with no gaps. The transition from row 4 to row 5 is where the
>>> speed has changed from 2.1 knots to 3.4 knots. I am hoping to see another
>>> line from row 4 to row 5 in red colour. Similarly for the other disjoint
>>> points.
>>> Regards
>>>
>>> Dhiraj Khanna
>>> Mob:09873263331
>>>
>>>
>>> On Sat, Sep 1, 2018 at 6:17 PM Kent Johnson <[hidden email]> wrote:
>>>
>>>> Message: 5
>>>>> Date: Sat, 1 Sep 2018 08:28:24 +0530
>>>>> From: Dhiraj Khanna <[hidden email]>
>>>>> To: [hidden email]
>>>>> Subject: [R-sig-Geo] Adding colour to polylines in Leaflet
>>>>> Message-ID:
>>>>>         <
>>>>> [hidden email]>
>>>>> Content-Type: text/plain; charset="utf-8"
>>>>>
>>>>> I am working with shipping data where I get the dynamic parameters of a
>>>>> ship like its position, speed, heading and rate of turn. I am then
>>>>> trying
>>>>> to plot this on a leaflet map and trying to colour the polylines based
>>>>> on
>>>>> the speed, but it always shows up in the same colour. Here’s some
>>>>> sample
>>>>> data:
>>>>>
>>>>> <snip>
>>>>> This is the code I have tried which doesn’t work:-
>>>>>
>>>>> map <-  leaflet(x) map <- addTiles(map) for( Color in
>>>>> levels(as.factor(x$Color))){   map <- addPolylines(map,
>>>>> lng=~lon,lat=~lat,data=x[x$Color==Color,], color=~Color) } map
>>>>>
>>>>> Regards
>>>>> Dhiraj Khanna
>>>>> Mob:09873263331
>>>>
>>>>
>>>> What are you expecting to see? When I run your code I get a map with
>>>> three lines, one red, one orange and one yellow.
>>>>
>>>> Kent
>>>>
>>>>
>>
        [[alternative HTML version deleted]]

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

Re: Consolidated SRS database/list?

Sat, 09/22/2018 - 07:23
Alex,
Thanks for QGIS's srs.db!  I wasn't aware of it.

I currently use the spatial_ref_sys from PostGIS to create a SRS data frame
but plan to use rgdal::make_EPSG more often.  The reason I brought this up
is because on the lab computers (cannot install stuff on it) where I teach
there is no PostGIS and I didn't know how to lookup EPSG codes for various
SRS definitions from within R.  I hadn't thought of Spatialite metadata as
a viable alternative.  So, thanks for that.  I will look into it and most
likely use it in conjunction with make_EPSG!

Finally, I am really looking forward to the consolidated SRS database from
the gdal barn-raising effort!  This consolidated database will be
invaluable, and of great aid/service, to the geospatial community, IMO.
Thanks,
Vijay.

On Sat, Sep 22, 2018 at 1:22 AM Alex Mandel <[hidden email]>
wrote:

> QGIS makes one
> https://github.com/qgis/QGIS/blob/master/resources/srs.db
> There's some script in the build that updates it also, not without issue:
> https://issues.qgis.org/issues/17993
>
> I suppose you could also dump out how PostGIS does it to Sqlite, or use
> the Spatialite metadata table.
> https://www.gaia-gis.it/gaia-sins/spatialite-cookbook/html/metadata.html
>
> But the thread mentioned that goes back to the MetaCRS mailing list is
> probably the right place in the community to revive the discussion.
>
> Seems like something to encourage, and a good topic for an OSGeo
> sponsored sprint.
>
> Thanks,
> Alex
>
> On 09/21/2018 12:32 AM, Roger Bivand wrote:
> > On Thu, 20 Sep 2018, Vijay Lulla wrote:
> >
> >> Ok, thanks!  While the page provided information about the project and
> >> its
> >> funding status I couldn't find the SQLite database.  Do you happen to
> >> know
> >> when this will be available?
> >
> > No more than is on that page, plus the time needed to re-write plenty of
> > sf, lwgeom, rgdal and sp. At that stage, contributions welcome!
> >
> > Roger
> >
> >>
> >> On Thu, Sep 20, 2018 at 1:02 PM Roger Bivand <[hidden email]>
> wrote:
> >>
> >>> On Thu, 20 Sep 2018, Vijay Lulla wrote:
> >>>
> >>>> Dear list members,
> >>>> A few years ago Roger Bivand posted a discussion (
> >>>> https://stat.ethz.ch/pipermail/r-sig-geo/2015-August/023204.html )
> >>>> about
> >>>> consolidating SRS definitions into a SQLite database and I am
> wondering
> >>> if
> >>>> there has been any development along those lines.
> >>>
> >>> Rather than trying this just within R, we're hoping that the GDAL
> >>> barn-raising effort:
> >>>
> >>> https://gdalbarn.com/
> >>>
> >>> will take us there and further, and be much better than having a
> >>> non-standard implementation.
> >>>
> >>> When that effort is done, we'll be open for ideas about interfacing it
> >>> through PROJ and GDAL, which now ship with CSV files that we copy into
> >>> Windows and MacOS binary packages (rgdal, sf, lwgeom).
> >>>
> >>> For now, if it helps, rgdal::make_EPSG() reads the EPSG CSV file
> shipped
> >>> with PROJ into the R workspace as a data.frame.
> >>>
> >>> Roger
> >>>
> >>>> Specifically, is there any consolidated collection of SRS
> >>>> definitions in
> >>>> R (either a data.frame or tibble or SQLite backed) that are being used
> >>>> by geospatial packages that users can use too?  If so, can you please
> >>>> point me to it?  If not, would it be worthwhile to have this
> >>>> consolidated list/dataframe, maybe as part of data for one of the core
> >>>> geospatial packages? Thanks in advance, Vijay
> >>>>
> >>>>       [[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]
> >>> http://orcid.org/0000-0003-2392-6140
> >>> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
> >>>
> >>
> >>
> >>
> >
>
>
--
Vijay Lulla

Assistant Professor,
Dept. of Geography, IUPUI
425 University Blvd, CA-207C.
Indianapolis, IN-46202
[hidden email]
ORCID: https://orcid.org/0000-0002-0823-2522
Webpage: http://vijaylulla.com

        [[alternative HTML version deleted]]

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

Re: Consolidated SRS database/list?

Sat, 09/22/2018 - 00:22
QGIS makes one
https://github.com/qgis/QGIS/blob/master/resources/srs.db
There's some script in the build that updates it also, not without issue:
https://issues.qgis.org/issues/17993

I suppose you could also dump out how PostGIS does it to Sqlite, or use
the Spatialite metadata table.
https://www.gaia-gis.it/gaia-sins/spatialite-cookbook/html/metadata.html

But the thread mentioned that goes back to the MetaCRS mailing list is
probably the right place in the community to revive the discussion.

Seems like something to encourage, and a good topic for an OSGeo
sponsored sprint.

Thanks,
Alex

On 09/21/2018 12:32 AM, Roger Bivand wrote:
> On Thu, 20 Sep 2018, Vijay Lulla wrote:
>
>> Ok, thanks!  While the page provided information about the project and
>> its
>> funding status I couldn't find the SQLite database.  Do you happen to
>> know
>> when this will be available?
>
> No more than is on that page, plus the time needed to re-write plenty of
> sf, lwgeom, rgdal and sp. At that stage, contributions welcome!
>
> Roger
>
>>
>> On Thu, Sep 20, 2018 at 1:02 PM Roger Bivand <[hidden email]> wrote:
>>
>>> On Thu, 20 Sep 2018, Vijay Lulla wrote:
>>>
>>>> Dear list members,
>>>> A few years ago Roger Bivand posted a discussion (
>>>> https://stat.ethz.ch/pipermail/r-sig-geo/2015-August/023204.html )
>>>> about
>>>> consolidating SRS definitions into a SQLite database and I am wondering
>>> if
>>>> there has been any development along those lines.
>>>
>>> Rather than trying this just within R, we're hoping that the GDAL
>>> barn-raising effort:
>>>
>>> https://gdalbarn.com/
>>>
>>> will take us there and further, and be much better than having a
>>> non-standard implementation.
>>>
>>> When that effort is done, we'll be open for ideas about interfacing it
>>> through PROJ and GDAL, which now ship with CSV files that we copy into
>>> Windows and MacOS binary packages (rgdal, sf, lwgeom).
>>>
>>> For now, if it helps, rgdal::make_EPSG() reads the EPSG CSV file shipped
>>> with PROJ into the R workspace as a data.frame.
>>>
>>> Roger
>>>
>>>> Specifically, is there any consolidated collection of SRS
>>>> definitions in
>>>> R (either a data.frame or tibble or SQLite backed) that are being used
>>>> by geospatial packages that users can use too?  If so, can you please
>>>> point me to it?  If not, would it be worthwhile to have this
>>>> consolidated list/dataframe, maybe as part of data for one of the core
>>>> geospatial packages? Thanks in advance, Vijay
>>>>
>>>>       [[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]
>>> http://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

Pages