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: 1 hour 53 min ago

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

Re: RGDAL installation fail after yum upgrade

Fri, 09/21/2018 - 11:52
On Fri, 21 Sep 2018, Rich Shepard wrote:

> On Fri, 21 Sep 2018, [hidden email] wrote:
>
>>  I have checked all the packages (GDAL v1.11.4, PROJ4 v4.9.1) and seems
>>  that the minimun required version has been satisfied. But on the system I
>>  have two version of PROJ4, the version v4.8.0 ( /usr/bin/proj ) and the
>>  version v4.9.1 ( /usr/local/bin/proj ).
>
> David,
>
>  This is the cause of many problems: two different versions of software on
> the same host.
>
>>  So can I force the use of the new version of PROJ with some parameters
>>  during the installation of RGDAL?
>
>  Take a look at your $PATH; it's likely that /usr/local/bin/ is checked
> before usr/bin/. And different applications using, e.g., proj4, may look for
> it in either place. This means that one application finds the 4.9.1 version
> while another application finds the 4.8.0 version.
Rich: thanks - having multiple versions is indeed a challenge on platforms
where R uses dynamically loaded libraries. On Windows and MacOS, most CRAN
packages with external dependencies are built with static linking (the
*old* way). However, executables are on the PATH, but dynamically loaded
libraries - shared objects - are on LD_LIBRARY_PATH. Try:

echo $LD_LIBRARY_PATH

at the shell prompt, then inside R:

Sys.getenv("LD_LIBRARY_PATH")

and you'll see that R may have made modifications on startup. A typical
trap is also forgetting to run /sbin/ldconfig -v as root after installing
software in /usr/local/lib (and adding /usr/local/lib to a file in
/etc/ld.so.conf.d) so that the shared objects are visible.

The easier route is to have just one version of external software
installed where R can see it; it is harder but possibly on a cluster
necessary to modify LD_LIBRARY_PATH locally and consistently. Also look at
closed sf issues on github; there we stepped back from messing with
LD_LIBRARY_PATH on a general basis.

Hope this helps,

Roger


>
>  I recommend that you put all core binaries in /usr/bin (which means moving
> 4.9.1 from /usr/local/bin/ to /usr/bin/ and keeping in the latter only
> software developed locally.
>
>  My network runs Slackware so I don't know how difficult it might be for
> you to re-organize your CentOS installations, but making the time to do this
> will make life easier for you.
>
> Best regards,
>
> Rich
>
> _______________________________________________
> 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
Roger Bivand
Department of Economics
Norwegian School of Economics
Helleveien 30
N-5045 Bergen, Norway

Re: RGDAL installation fail after yum upgrade

Fri, 09/21/2018 - 09:02
On Fri, 21 Sep 2018, [hidden email] wrote:

> I have checked all the packages (GDAL v1.11.4, PROJ4 v4.9.1) and seems
> that the minimun required version has been satisfied. But on the system I
> have two version of PROJ4, the version v4.8.0 ( /usr/bin/proj ) and the
> version v4.9.1 ( /usr/local/bin/proj ).

David,

   This is the cause of many problems: two different versions of software on
the same host.

> So can I force the use of the new version of PROJ with some parameters
> during the installation of RGDAL?

   Take a look at your $PATH; it's likely that /usr/local/bin/ is checked
before usr/bin/. And different applications using, e.g., proj4, may look for
it in either place. This means that one application finds the 4.9.1 version
while another application finds the 4.8.0 version.

   I recommend that you put all core binaries in /usr/bin (which means moving
4.9.1 from /usr/local/bin/ to /usr/bin/ and keeping in the latter only
software developed locally.

   My network runs Slackware so I don't know how difficult it might be for
you to re-organize your CentOS installations, but making the time to do this
will make life easier for you.

Best regards,

Rich

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

Re: RGDAL installation fail after yum upgrade

Fri, 09/21/2018 - 08:35
Dear Roger, thanks for your reply.

I know, that this cluster have several problems, at first the pool software.
I'm the maintainer and not the creator, so I have inherited all this problems.

The version of OS is Centos 7.5 and unluckly all the software has been installed
via EPEL repository and not from source.

I have checked all the packages (GDAL v1.11.4, PROJ4 v4.9.1) and seems that
the minimun required version has been satisfied. But on the system I have two
version of PROJ4, the version v4.8.0 ( /usr/bin/proj ) and the version v4.9.1
( /usr/local/bin/proj ).

So can I force the use of the new version of PROJ with some parameters during
the installation of RGDAL?

Thanks in advance for your support.
David

-----Original Message-----
From: Roger Bivand [mailto:[hidden email]]
Sent: Friday, September 21, 2018 12:25 PM
To: GIOVANNINI David (JRC-ISPRA-EXT)
Cc: [hidden email]
Subject: Re: [R-sig-Geo] RGDAL installation fail after yum upgrade

On Fri, 21 Sep 2018, [hidden email] wrote:

> Dear list members, I'm tring to install RGDAL on a cluster, but after
> the update of R packages seems not possible to install it.

On a cluster running which very outdated version of which operating
system? How did you install PROJ and GDAL, hopefully from source? How did
you install R, again hopefully from source? If you install from source,
your upstream binaries should only use the limited resources of your
outdated platform; if you install binary packages, those packages will
make brave and possibly untrue assumptions about your platform. It is also
very possible that you have multiple versions of GDAL and/or PROJ on your
systems, and that (parts of) configure and install find different
versions. In particular, at least one version of PROJ does not have
pj_ctx_* file access functions, needed in several places.

If you can't fix your systems (PROJ 4.8.0 was released in 2012, over 6
years ago), use a version of rgdal, GDAL and driver software to match your
vintage. Possibly your compile trains are also very outdated too.

Maintainers cannot be expected to keep current package versions running
smoothly on ancient platforms (although we try to help) without active
contributions from interested users. Provide patches to configure.ac that
work for you and do not have any negative impacts on current systems, or
keep your systems more up to date.

Roger

>
> Below the error message:
>
>> install.packages("rgdal")
> Installing package into '/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5'
> (as 'lib' is unspecified)
> trying URL 'https://cran.stat.unipd.it/src/contrib/rgdal_1.3-4.tar.gz'
> Content type 'application/octet-stream' length 1664774 bytes (1.6 MB)
> ==================================================
> downloaded 1.6 MB
>
> * installing *source* package 'rgdal' ...
> ** package 'rgdal' successfully unpacked and MD5 sums checked
> configure: R_HOME: /usr/lib64/R
> configure: CC: gcc -m64 -std=gnu99
> configure: CXX: g++ -m64
> configure: C++11 support available
> configure: rgdal: 1.3-4
> checking for /usr/bin/svnversion... yes
> configure: svn revision: 766
> checking for gdal-config... /bin/gdal-config
> checking gdal-config usability... yes
> configure: GDAL: 1.11.4
> checking GDAL version >= 1.11.4... yes
> checking gdal: linking with --libs only... yes
> checking GDAL: /usr/share/gdal/pcs.csv readable... yes
> checking proj_api.h presence and usability... yes
> ./configure: line 2126: test: =: unary operator expected
> checking PROJ version >= 4.8.0... yes
> checking projects.h presence and usability... yes
> /tmp/ccnBOZCl.o: In function `main':
> /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/proj_conf_test2.c:20: undefined reference to `pj_ctx_fclose'
> collect2: error: ld returned 1 exit status
> ./configure: line 2242: ./proj_conf_test2: No such file or directory
> checking PROJ.4: epsg found and readable... yes
> /tmp/ccu3xNdp.o: In function `main':
> /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/proj_conf_test3.c:20: undefined reference to `pj_ctx_fclose'
> collect2: error: ld returned 1 exit status
> ./configure: line 2301: ./proj_conf_test3: No such file or directory
> checking PROJ.4: conus found and readable... yes
> configure: Package CPP flags:  -I/usr/include/gdal
> configure: Package LIBS:  -L/usr/lib64 -lgdal -lproj
> configure: creating ./config.status
> config.status: creating src/Makevars
> ** libs
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c OGR_write.cpp -o OGR_write.o
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c gdal-bindings.cpp -o gdal-bindings.o
> gcc -m64 -std=gnu99 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -c init.c -o init.o
> gcc -m64 -std=gnu99 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -c inverser.c -o inverser.o
> gcc -m64 -std=gnu99 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -c local_stubs.c -o local_stubs.o
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c ogr_geom.cpp -o ogr_geom.o
> gcc -m64 -std=gnu99 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -c ogr_polygons.c -o ogr_polygons.o
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c ogr_proj.cpp -o ogr_proj.o
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c ogrdrivers.cpp -o ogrdrivers.o
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c ogrsource.cpp -o ogrsource.o
> ogrsource.cpp: In function 'SEXPREC* ogrReadListColumn(OGRLayer*, SEXP, int, int, int)':
> ogrsource.cpp:651:12: warning: unused variable 'DINT_MAX' [-Wunused-variable]
>     double DINT_MAX = 2251799813685248.0;
>            ^
> ogrsource.cpp:652:12: warning: unused variable 'DINT_MIN' [-Wunused-variable]
>     double DINT_MIN = -2251799813685248.0;
>            ^
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c projectit.cpp -o projectit.o
> g++ -m64 -std=gnu++11 -shared -L/usr/lib64/R/lib -Wl,-z,relro -o rgdal.so OGR_write.o gdal-bindings.o init.o inverser.o local_stubs.o ogr_geom.o ogr_polygons.o ogr_proj.o ogrdrivers.o ogrsource.o projectit.o -L/usr/lib64 -lgdal -lproj -L/usr/lib64/R/lib -lR
> installing to /home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/rgdal/libs
> ** R
> ** data
> ** inst
> ** byte-compile and prepare package for lazy loading
> ** help
> *** installing help indices
>  converting help for package 'rgdal'
>    finding HTML links ... done
>    CRS-class                               html
>    GDALDataset-class                       html
>    GDALDriver-class                        html
>    GDALMajorObject-class                   html
>    GDALRasterBand-class                    html
>    GDALReadOnlyDataset-class               html
>    GDALReadOnlyDataset-methods             html
>    GDALTransientDataset-class              html
>    GridsDatums                             html
>    RGB2PCT                                 html
>    SGDF2PCT                                html
>    SpatialGDAL-class                       html
>    closeDataset-methods                    html
>    displayDataset                          html
>    llgrid                                  html
> Rd warning: /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/man/llgrid.Rd:11: file link 'Spatial' in package 'sp' does not exist and so has been treated as a topic
> Rd warning: /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/man/llgrid.Rd:16: file link 'gridat' in package 'sp' does not exist and so has been treated as a topic
> Rd warning: /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/man/llgrid.Rd:17: file link 'gridat' in package 'sp' does not exist and so has been treated as a topic
>    make_EPSG                               html
>    nor2k                                   html
>    projInfo                                html
>    project                                 html
>    readGDAL                                html
> Rd warning: /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/man/readGDAL.Rd:136: file link 'flipVertical' in package 'sp' does not exist and so has been treated as a topic
>    readOGR                                 html
>    showWKT                                 html
>    spTransform-methods                     html
>    wrappers                                html
>    writeOGR                                html
> ** building package indices
> ** installing vignettes
> ** testing if installed package can be loaded
> Error: package or namespace load failed for 'rgdal' in dyn.load(file, DLLpath = DLLpath, ...):
> unable to load shared object '/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/rgdal/libs/rgdal.so':
>  /home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/rgdal/libs/rgdal.so: undefined symbol: pj_ctx_fgets
> Error: loading failed
> Execution halted
> ERROR: loading failed
> * removing '/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/rgdal'
>
> The downloaded source packages are in
>     '/tmp/RtmpXrQsj2/downloaded_packages'
> Warning message:
> In install.packages("rgdal") :
>  installation of package 'rgdal' had non-zero exit status
>
> I have tried several solutions but without any success.
>
> Have you any idea about the problem?
>
> Thanks in advance
> David
>
> [[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: RGDAL installation fail after yum upgrade

Fri, 09/21/2018 - 05:25
On Fri, 21 Sep 2018, [hidden email] wrote:

> Dear list members, I'm tring to install RGDAL on a cluster, but after
> the update of R packages seems not possible to install it.

On a cluster running which very outdated version of which operating
system? How did you install PROJ and GDAL, hopefully from source? How did
you install R, again hopefully from source? If you install from source,
your upstream binaries should only use the limited resources of your
outdated platform; if you install binary packages, those packages will
make brave and possibly untrue assumptions about your platform. It is also
very possible that you have multiple versions of GDAL and/or PROJ on your
systems, and that (parts of) configure and install find different
versions. In particular, at least one version of PROJ does not have
pj_ctx_* file access functions, needed in several places.

If you can't fix your systems (PROJ 4.8.0 was released in 2012, over 6
years ago), use a version of rgdal, GDAL and driver software to match your
vintage. Possibly your compile trains are also very outdated too.

Maintainers cannot be expected to keep current package versions running
smoothly on ancient platforms (although we try to help) without active
contributions from interested users. Provide patches to configure.ac that
work for you and do not have any negative impacts on current systems, or
keep your systems more up to date.

Roger

>
> Below the error message:
>
>> install.packages("rgdal")
> Installing package into '/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5'
> (as 'lib' is unspecified)
> trying URL 'https://cran.stat.unipd.it/src/contrib/rgdal_1.3-4.tar.gz'
> Content type 'application/octet-stream' length 1664774 bytes (1.6 MB)
> ==================================================
> downloaded 1.6 MB
>
> * installing *source* package 'rgdal' ...
> ** package 'rgdal' successfully unpacked and MD5 sums checked
> configure: R_HOME: /usr/lib64/R
> configure: CC: gcc -m64 -std=gnu99
> configure: CXX: g++ -m64
> configure: C++11 support available
> configure: rgdal: 1.3-4
> checking for /usr/bin/svnversion... yes
> configure: svn revision: 766
> checking for gdal-config... /bin/gdal-config
> checking gdal-config usability... yes
> configure: GDAL: 1.11.4
> checking GDAL version >= 1.11.4... yes
> checking gdal: linking with --libs only... yes
> checking GDAL: /usr/share/gdal/pcs.csv readable... yes
> checking proj_api.h presence and usability... yes
> ./configure: line 2126: test: =: unary operator expected
> checking PROJ version >= 4.8.0... yes
> checking projects.h presence and usability... yes
> /tmp/ccnBOZCl.o: In function `main':
> /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/proj_conf_test2.c:20: undefined reference to `pj_ctx_fclose'
> collect2: error: ld returned 1 exit status
> ./configure: line 2242: ./proj_conf_test2: No such file or directory
> checking PROJ.4: epsg found and readable... yes
> /tmp/ccu3xNdp.o: In function `main':
> /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/proj_conf_test3.c:20: undefined reference to `pj_ctx_fclose'
> collect2: error: ld returned 1 exit status
> ./configure: line 2301: ./proj_conf_test3: No such file or directory
> checking PROJ.4: conus found and readable... yes
> configure: Package CPP flags:  -I/usr/include/gdal
> configure: Package LIBS:  -L/usr/lib64 -lgdal -lproj
> configure: creating ./config.status
> config.status: creating src/Makevars
> ** libs
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c OGR_write.cpp -o OGR_write.o
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c gdal-bindings.cpp -o gdal-bindings.o
> gcc -m64 -std=gnu99 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -c init.c -o init.o
> gcc -m64 -std=gnu99 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -c inverser.c -o inverser.o
> gcc -m64 -std=gnu99 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -c local_stubs.c -o local_stubs.o
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c ogr_geom.cpp -o ogr_geom.o
> gcc -m64 -std=gnu99 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -c ogr_polygons.c -o ogr_polygons.o
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c ogr_proj.cpp -o ogr_proj.o
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c ogrdrivers.cpp -o ogrdrivers.o
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c ogrsource.cpp -o ogrsource.o
> ogrsource.cpp: In function 'SEXPREC* ogrReadListColumn(OGRLayer*, SEXP, int, int, int)':
> ogrsource.cpp:651:12: warning: unused variable 'DINT_MAX' [-Wunused-variable]
>     double DINT_MAX = 2251799813685248.0;
>            ^
> ogrsource.cpp:652:12: warning: unused variable 'DINT_MIN' [-Wunused-variable]
>     double DINT_MIN = -2251799813685248.0;
>            ^
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c projectit.cpp -o projectit.o
> g++ -m64 -std=gnu++11 -shared -L/usr/lib64/R/lib -Wl,-z,relro -o rgdal.so OGR_write.o gdal-bindings.o init.o inverser.o local_stubs.o ogr_geom.o ogr_polygons.o ogr_proj.o ogrdrivers.o ogrsource.o projectit.o -L/usr/lib64 -lgdal -lproj -L/usr/lib64/R/lib -lR
> installing to /home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/rgdal/libs
> ** R
> ** data
> ** inst
> ** byte-compile and prepare package for lazy loading
> ** help
> *** installing help indices
>  converting help for package 'rgdal'
>    finding HTML links ... done
>    CRS-class                               html
>    GDALDataset-class                       html
>    GDALDriver-class                        html
>    GDALMajorObject-class                   html
>    GDALRasterBand-class                    html
>    GDALReadOnlyDataset-class               html
>    GDALReadOnlyDataset-methods             html
>    GDALTransientDataset-class              html
>    GridsDatums                             html
>    RGB2PCT                                 html
>    SGDF2PCT                                html
>    SpatialGDAL-class                       html
>    closeDataset-methods                    html
>    displayDataset                          html
>    llgrid                                  html
> Rd warning: /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/man/llgrid.Rd:11: file link 'Spatial' in package 'sp' does not exist and so has been treated as a topic
> Rd warning: /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/man/llgrid.Rd:16: file link 'gridat' in package 'sp' does not exist and so has been treated as a topic
> Rd warning: /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/man/llgrid.Rd:17: file link 'gridat' in package 'sp' does not exist and so has been treated as a topic
>    make_EPSG                               html
>    nor2k                                   html
>    projInfo                                html
>    project                                 html
>    readGDAL                                html
> Rd warning: /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/man/readGDAL.Rd:136: file link 'flipVertical' in package 'sp' does not exist and so has been treated as a topic
>    readOGR                                 html
>    showWKT                                 html
>    spTransform-methods                     html
>    wrappers                                html
>    writeOGR                                html
> ** building package indices
> ** installing vignettes
> ** testing if installed package can be loaded
> Error: package or namespace load failed for 'rgdal' in dyn.load(file, DLLpath = DLLpath, ...):
> unable to load shared object '/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/rgdal/libs/rgdal.so':
>  /home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/rgdal/libs/rgdal.so: undefined symbol: pj_ctx_fgets
> Error: loading failed
> Execution halted
> ERROR: loading failed
> * removing '/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/rgdal'
>
> The downloaded source packages are in
>     '/tmp/RtmpXrQsj2/downloaded_packages'
> Warning message:
> In install.packages("rgdal") :
>  installation of package 'rgdal' had non-zero exit status
>
> I have tried several solutions but without any success.
>
> Have you any idea about the problem?
>
> Thanks in advance
> David
>
> [[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
Roger Bivand
Department of Economics
Norwegian School of Economics
Helleveien 30
N-5045 Bergen, Norway

RGDAL installation fail after yum upgrade

Fri, 09/21/2018 - 04:52
Dear list members,
I'm tring to install RGDAL on a cluster, but after the update of R packages seems not possible to install it.

Below the error message:

> install.packages("rgdal")
Installing package into '/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5'
(as 'lib' is unspecified)
trying URL 'https://cran.stat.unipd.it/src/contrib/rgdal_1.3-4.tar.gz'
Content type 'application/octet-stream' length 1664774 bytes (1.6 MB)
==================================================
downloaded 1.6 MB

* installing *source* package 'rgdal' ...
** package 'rgdal' successfully unpacked and MD5 sums checked
configure: R_HOME: /usr/lib64/R
configure: CC: gcc -m64 -std=gnu99
configure: CXX: g++ -m64
configure: C++11 support available
configure: rgdal: 1.3-4
checking for /usr/bin/svnversion... yes
configure: svn revision: 766
checking for gdal-config... /bin/gdal-config
checking gdal-config usability... yes
configure: GDAL: 1.11.4
checking GDAL version >= 1.11.4... yes
checking gdal: linking with --libs only... yes
checking GDAL: /usr/share/gdal/pcs.csv readable... yes
checking proj_api.h presence and usability... yes
./configure: line 2126: test: =: unary operator expected
checking PROJ version >= 4.8.0... yes
checking projects.h presence and usability... yes
/tmp/ccnBOZCl.o: In function `main':
/tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/proj_conf_test2.c:20: undefined reference to `pj_ctx_fclose'
collect2: error: ld returned 1 exit status
./configure: line 2242: ./proj_conf_test2: No such file or directory
checking PROJ.4: epsg found and readable... yes
/tmp/ccu3xNdp.o: In function `main':
/tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/proj_conf_test3.c:20: undefined reference to `pj_ctx_fclose'
collect2: error: ld returned 1 exit status
./configure: line 2301: ./proj_conf_test3: No such file or directory
checking PROJ.4: conus found and readable... yes
configure: Package CPP flags:  -I/usr/include/gdal
configure: Package LIBS:  -L/usr/lib64 -lgdal -lproj
configure: creating ./config.status
config.status: creating src/Makevars
** libs
g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c OGR_write.cpp -o OGR_write.o
g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c gdal-bindings.cpp -o gdal-bindings.o
gcc -m64 -std=gnu99 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -c init.c -o init.o
gcc -m64 -std=gnu99 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -c inverser.c -o inverser.o
gcc -m64 -std=gnu99 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -c local_stubs.c -o local_stubs.o
g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c ogr_geom.cpp -o ogr_geom.o
gcc -m64 -std=gnu99 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -c ogr_polygons.c -o ogr_polygons.o
g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c ogr_proj.cpp -o ogr_proj.o
g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c ogrdrivers.cpp -o ogrdrivers.o
g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c ogrsource.cpp -o ogrsource.o
ogrsource.cpp: In function 'SEXPREC* ogrReadListColumn(OGRLayer*, SEXP, int, int, int)':
ogrsource.cpp:651:12: warning: unused variable 'DINT_MAX' [-Wunused-variable]
     double DINT_MAX = 2251799813685248.0;
            ^
ogrsource.cpp:652:12: warning: unused variable 'DINT_MIN' [-Wunused-variable]
     double DINT_MIN = -2251799813685248.0;
            ^
g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c projectit.cpp -o projectit.o
g++ -m64 -std=gnu++11 -shared -L/usr/lib64/R/lib -Wl,-z,relro -o rgdal.so OGR_write.o gdal-bindings.o init.o inverser.o local_stubs.o ogr_geom.o ogr_polygons.o ogr_proj.o ogrdrivers.o ogrsource.o projectit.o -L/usr/lib64 -lgdal -lproj -L/usr/lib64/R/lib -lR
installing to /home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/rgdal/libs
** R
** data
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
  converting help for package 'rgdal'
    finding HTML links ... done
    CRS-class                               html
    GDALDataset-class                       html
    GDALDriver-class                        html
    GDALMajorObject-class                   html
    GDALRasterBand-class                    html
    GDALReadOnlyDataset-class               html
    GDALReadOnlyDataset-methods             html
    GDALTransientDataset-class              html
    GridsDatums                             html
    RGB2PCT                                 html
    SGDF2PCT                                html
    SpatialGDAL-class                       html
    closeDataset-methods                    html
    displayDataset                          html
    llgrid                                  html
Rd warning: /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/man/llgrid.Rd:11: file link 'Spatial' in package 'sp' does not exist and so has been treated as a topic
Rd warning: /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/man/llgrid.Rd:16: file link 'gridat' in package 'sp' does not exist and so has been treated as a topic
Rd warning: /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/man/llgrid.Rd:17: file link 'gridat' in package 'sp' does not exist and so has been treated as a topic
    make_EPSG                               html
    nor2k                                   html
    projInfo                                html
    project                                 html
    readGDAL                                html
Rd warning: /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/man/readGDAL.Rd:136: file link 'flipVertical' in package 'sp' does not exist and so has been treated as a topic
    readOGR                                 html
    showWKT                                 html
    spTransform-methods                     html
    wrappers                                html
    writeOGR                                html
** building package indices
** installing vignettes
** testing if installed package can be loaded
Error: package or namespace load failed for 'rgdal' in dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object '/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/rgdal/libs/rgdal.so':
  /home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/rgdal/libs/rgdal.so: undefined symbol: pj_ctx_fgets
Error: loading failed
Execution halted
ERROR: loading failed
* removing '/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/rgdal'

The downloaded source packages are in
     '/tmp/RtmpXrQsj2/downloaded_packages'
Warning message:
In install.packages("rgdal") :
  installation of package 'rgdal' had non-zero exit status

I have tried several solutions but without any success.

Have you any idea about the problem?

Thanks in advance
David

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

Fri, 09/21/2018 - 02:32
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
>>
>
>
>
--
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
Roger Bivand
Department of Economics
Norwegian School of Economics
Helleveien 30
N-5045 Bergen, Norway

Re: Consolidated SRS database/list?

Thu, 09/20/2018 - 15:47
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?

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: Library version mis-match [FIXED]

Thu, 09/20/2018 - 15:27
On Thu, 20 Sep 2018, Rich Shepard wrote:

> This might well be the issue. geos was upgraded from the summer's 3.6.3 to
> the very recent 3.7.0 and when I run weekly upgrades to installed
> Slackbuilds.org packages that was upgraded. I'll rebuild gdal and check that
> the issue is resolved.

   Fixed. Rebuilt/re-installed gdal-2.4.4 and rgdal re-installed without
problems.

Thanks again,

Rich

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

Re: Library version mis-match

Thu, 09/20/2018 - 13:47
On Thu, 20 Sep 2018, Roger Bivand wrote:

> No, this is the right list, but always include the output of sessionInfo(),
> and the startup messages shown by rgdal and rgeos when they are attached.

Roger,

   I'll include more information the next time I have an issue.

> How many other versions of gdal and/or geos do you have? It looks as though
> libgdal was built against libgeos-3.6.3, but you upgraded libgeos later,

   This might well be the issue. geos was upgraded from the summer's 3.6.3 to
the very recent 3.7.0 and when I run weekly upgrades to installed
Slackbuilds.org packages that was upgraded. I'll rebuild gdal and check that
the issue is resolved.

   Not long ago I did rebuild the sequence proj -> geos -> gdal -> grass and
the R upgrade might have missed that.

Many thanks,

Rich

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

Re: Library version mis-match

Thu, 09/20/2018 - 13:37
On Thu, 20 Sep 2018, Rich Shepard wrote:

>  If the r-help list is better suited for this question let me know and I'll
> move the thread there.

No, this is the right list, but always include the output of
sessionInfo(), and the startup messages shown by rgdal and rgeos when they
are attached.

>
>  Installed here are gdal-2.2.4 and geos-3.7.0
>

How many other versions of gdal and/or geos do you have? It looks as
though libgdal was built against libgeos-3.6.3, but you upgraded libgeos
later, removing that version. Easiest is having one version only, and
building everything in lockstep (PROJ and GEOS, then GDAL, then rgdal
and/or GRASS) and having only one version of each. Both rgdal and rgeos
may suffer from being installed with the versions shown by gdal-config and
geos-config, but finding different versions in the dynamic library load
path. I'm assuming you are neither on Windows nor MacOS - all this is
sorted out on CRAN in binary rgdal and rgeos (and sf) packages for those
platforms.

Hope this helps,

Roger

>  When I check installed libraries with library() both rgdal and rgeos are
> shown as being available:
>
> rgdal                   Bindings for the 'Geospatial' Data Abstraction
>                        Library
> rgeos                   Interface to Geometry Engine - Open Source
>                         ('GEOS')
>
>  However, when I try to use them in an operation with the sp() package the
> attempts fail. So I tried re-installing them. rgeos had no problem
> re-installing, but rgdal is not happy:
>
> ** testing if installed package can be loaded
> Error: package or namespace load failed for ?rgdal? in dyn.load(file, DLLpath
> = DLLpath, ...):
>  unable to load shared object '/usr/lib/R/library/rgdal/libs/rgdal.so':
>  libgeos-3.6.3.so: cannot open shared object file: No such file or directory
> Error: loading failed
> Execution halted
> ERROR: loading failed
> * removing ?/usr/lib/R/library/rgdal?
> * restoring previous ?/usr/lib/R/library/rgdal?
>
> The downloaded source packages are in
> ?/tmp/Rtmp22EDOj/downloaded_packages?
> Updating HTML index of packages in '.Library'
> Making 'packages.html' ... done
> Warning message:
> In install.packages("rgdal") :
>   installation of package ?rgdal? had non-zero exit status
>
>  How can I resolve this by having R recognize, and use, geos-3.7.0? Or, do
> I need to downgrade geos to the earlier 3.6.3?
>
> Rich
>
> _______________________________________________
> 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
Roger Bivand
Department of Economics
Norwegian School of Economics
Helleveien 30
N-5045 Bergen, Norway

Library version mis-match

Thu, 09/20/2018 - 12:38
   If the r-help list is better suited for this question let me know and I'll
move the thread there.

   Installed here are gdal-2.2.4 and geos-3.7.0

   When I check installed libraries with library() both rgdal and rgeos are
shown as being available:

rgdal                   Bindings for the 'Geospatial' Data Abstraction
                         Library
rgeos                   Interface to Geometry Engine - Open Source
                         ('GEOS')

   However, when I try to use them in an operation with the sp() package the
attempts fail. So I tried re-installing them. rgeos had no problem
re-installing, but rgdal is not happy:

** testing if installed package can be loaded
Error: package or namespace load failed for ‘rgdal’ in dyn.load(file, DLLpath = DLLpath, ...):
  unable to load shared object '/usr/lib/R/library/rgdal/libs/rgdal.so':
   libgeos-3.6.3.so: cannot open shared object file: No such file or directory
Error: loading failed
Execution halted
ERROR: loading failed
* removing ‘/usr/lib/R/library/rgdal’
* restoring previous ‘/usr/lib/R/library/rgdal’

The downloaded source packages are in
  ‘/tmp/Rtmp22EDOj/downloaded_packages’
Updating HTML index of packages in '.Library'
Making 'packages.html' ... done
Warning message:
In install.packages("rgdal") :
   installation of package ‘rgdal’ had non-zero exit status

   How can I resolve this by having R recognize, and use, geos-3.7.0? Or, do
I need to downgrade geos to the earlier 3.6.3?

Rich

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

Re: Consolidated SRS database/list?

Thu, 09/20/2018 - 12:01
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
Roger Bivand
Department of Economics
Norwegian School of Economics
Helleveien 30
N-5045 Bergen, Norway

Consolidated SRS database/list?

Thu, 09/20/2018 - 11:33
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.  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

Pages