from:"Robin Lovelace"

Re: [R-sig-Geo] Combine line segments into one line

2021-10-12 Thread Robin Lovelace

Great to see the geometry but this still isn't quite a 'reprex'. Can you
provide code that others can reproduce, e.g. starting with:

dataformap = ...

you should be able to get the ... bit from a minimal example of your data
with dput(dataformap). Even better, you could try creating a fully
reproducible example and test it's reproducible using the reprex. You can
do this by copying the code that is reproducible and then entering
reprex::reprex() into the R console. You need to have installed the reprex
package first.

If you'd like to paste code with images you could try pasting the output
into a GitHub issue tracker, e.g.
https://github.com/r-spatial/discuss/issues/

Hope that helps and look forward to seeing a fully reproducible example
that should enable identification of an efficient fix!

Robin

On Tue, Oct 12, 2021 at 4:44 PM Remon Hanna 
wrote:

> Hi  Robin
>
>
>
> Thanks for coming back to me, my data frame called “data formap” and each
> line’s geometry  is in a list as below
>
>
>
> Scheme, Corridor, UID,S2S,Geometry
>
>
>
> Islington, Canonbury Road, 1447, 14605 to 14609,
> list(c(-0.100494685106162, -0.100768728775846, -0.100809237473678,
> -0.100829081233454, -0.101055753520492, -0.101056925872705,
> -0.101132027068313, -0.101179751049333, -0.101183341723369,
> -0.101214417461412, -0.101296576180155, -0.101302119916002,
> -0.101944537808155, 51.5434078452207, 51.5436641294246, 51.5436996947231,
> 51.5437244960352, 51.544168798304, 51.5441712130049, 51.544334107534,
> 51.5443894702274, 51.5443939279601, 51.5444353337587, 51.5444892923546,
> 51.544493149994, 51.5449669589982), c(-0.100337415159165,
> -0.100420276584877, -0.100443482598481, -0.100465896635865,
> -0.100480620959424, -0.100500980394883, -0.100507243380856,
> -0.100501227668383, -0.100494685106162, 51.5430850037077, 51.543253316,
> 51.5432674582742, 51.5432850407821, 51.5433055391161, 51.5433471893563,
> 51.5433731318632, 51.5433990971125, 51.5434078452207))
>
>
>
>
>
> Islington, Canonbury Road, 19934, 14609 TO 29772,
> list(c(-0.102378850945486, -0.102404766293504, -0.102612043222577,
> -0.102841140440283, -0.102857165923901, -0.10307303364985,
> -0.103096514259402, -0.103308545727647, -0.10331512465684,
> -0.103613310295447, -0.103628721780704, -0.104683501048217,
> 51.5460024466378, 51.5460044053932, 51.5460430024067, 51.5460719844139,
> 51.5460746176867, 51.5461185026024, 51.5461247589939, 51.5461957028378,
> 51.5461980449175, 51.5463107753556, 51.546317496109, 51.5468445401221),
> c(-0.101944538040546, -0.101987754430814,  -0.101995197988773,
> -0.102120422782938, -0.102135897924177, -0.102179623597572,
> -0.102185478839142, -0.102221057492863, -0.102249160660721,
> -0.102264674655534, -0.102353250310779, -0.10236569955816,
> -0.10238744921156, -0.102390154716109, -0.102369692569022,
> -0.102373676493536, -0.102378850945486, 51.5449669591696, 51.5449988326798,
> 51.5450048166063, 51.5451147525675, 51.5451321348331, 51.5451973544301,
> 51.5452078768073, 51.545287421255, 51.5453095810419, 51.545324703994,
> 51.5454336871467, 51.5454557182705,  51.5455198269438, 51.5455452536589,
> 51.5457128758933, 51.5459370064566, 51.5460024466378))
>
>
>
>
>
> # converts table to sf format
>
> dataformap <- st_as_sf(dataformap)
>
>
>
> # Render leaflet map
>
> map<- leaflet(data=dataformap)%>%
>
> addProviderTiles("CartoDB.Positron",options =
> providerTileOptions(minZoom=7))%>%
>
>   addPolylines(data=dataformap,color= ~ pal(Scheme), weight = 2,opacity =
> 0.75,
>
>smoothFactor = 0,label = ~dataformap$Scheme,
>
>popup = paste("Scheme:", dataformap$Scheme, "","",
>
>     "Corridor:", dataformap$Corridor,
> "" ))%>%
>
>   addDrawToolbar(targetGroup = "Scheme", editOptions =
> editToolbarOptions())
>
>
>
> map
>
>
>
> Thanks
>
>
>
> Remon
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows
>
>
>
> *From: *Robin Lovelace 
> *Sent: *12 October 2021 14:44
> *To: *r-sig-geo@r-project.org
> *Subject: *Re: [R-sig-Geo] Combine line segments into one line
>
>
>
> Hi Remon,
>
> Please could you provide a fully reproducible example to illustrate the
> data you have, what you have tried, and what you hope to achieve?
>
> I cannot see the screenshot mentioned.
>
> All the best,
>
> Robin
>
> On Fri, Oct 8, 2021 at 1:55 PM Remon Hanna 
> wrote:
>
> > Hi
> >
> > I have line segments that I would like to combine them within each
> > corridor, I.e each corridor wi

Re: [R-sig-Geo] Combine line segments into one line

2021-10-12 Thread Robin Lovelace

Hi Remon,

Please could you provide a fully reproducible example to illustrate the
data you have, what you have tried, and what you hope to achieve?

I cannot see the screenshot mentioned.

All the best,

Robin

On Fri, Oct 8, 2021 at 1:55 PM Remon Hanna 
wrote:

> Hi
>
> I have line segments that I would like to combine them within each
> corridor, I.e each corridor will be one line of combined segments of
> NAME_S2S and combined geometry  as per the screenshot.
>
> I have managed to plot the segments on the map as you can see but when
> zooming in these segments are not in one, which I would like to group them.
>
> I ran the below line to group them by corridor, but I get error below;
>
> > dataformap1<-gLineMerge(dataformap[dataformap$Corridor==1, ])
> Error in gLineMerge(dataformap[dataformap$Corridor == 1, ]) :
>   Invalid geometry, may only be applied to lines
>
> Many thanks in advance
>
> Remon Hanna
>
> Sent from Mail for Windows
>
>
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

[R-sig-Geo] Feedback on priorities for a 2nd edition of Geocomputation with R

2021-09-06 Thread Robin Lovelace

Dear R-SIG-GEO members,

Myself, Jakub Nowosad and Jannes Muenchow have plans to update the open
source book Geocomputation with R to keep up-to-date with the evolution of
R packages for working with geographic data (notably sf 1.0.0+ and terra).

To help guide our work on this over the next few months (we are hoping to
publish the book in CRC Press at some point in 2022) we would appreciate
feedback from anyone who has used the book. What are aspects we should
improve? What should we cover in more detail?

If you would like to shape the direction of the book into the future,
please provide feedback on this form, that should only take around 5
minutes to complete: https://forms.gle/nq9RmbxJyZXQgc948

There is a longer discussion of ideas for future topics and priorities here
where we welcome further comments, suggestions and ideas:
https://github.com/Robinlovelace/geocompr/issues/12#issuecomment-609026237

Many thanks,

Robin

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] NA values in predictions from gstat::krige()

2020-10-27 Thread Robin Lovelace

Update, I had missed something obvious: the unnecessary st_crop. Many
thanks to Jannes, who pointed this out:
https://github.com/Robinlovelace/geocompr/issues/585#issuecomment-716780818

And apologies for 'spamming' the list, hope my next comment/question will
be more enlightening!

Robin

On Mon, Oct 26, 2020 at 5:31 PM Robin Lovelace  wrote:

> Hi all,
>
> When using the gstat package I get NA values for the majority of cells
> predicted and I'm not sure what I'm doing wrong. The data is quite noisy
> and I plan to do some aggregation on the input data before trying this
> again with the interpolate() function from raster/terra, but thought it
> worth asking as the answer may be of use to others.
>
> # reprex
> library(sf)
> library(gstat)
> library(stars)
> u = "
> https://github.com/saferactive/saferactive/releases/download/0.1.1/rnet_lnd_1pcnt.Rds
> "
> rnet_lnd = readRDS(url(u))
> rnet_lnd
> grd = st_bbox(rnet_lnd) %>%
>   st_as_stars(dx = 500, dy = 500) %>%
>   st_set_crs(27700) %>%
>   st_crop(rnet_lnd)
> grd
> v = variogram(bicycle~1, rnet_lnd, cutoff = 1)
> plot(v)
> vm = fit.variogram(v, vgm(psill = "Sph", model = "Exp", range = 1,
> nugget = 1))
> plot(vm, cutoff = 1)
> rnet_krige = gstat::krige(bicycle~1, rnet_lnd, grd, vm, nmax = 100)
> plot(rnet_lnd$geometry)
> plot(rnet_krige, add = TRUE)
>
> Outcome on my computer: predictions only in raster grid cells with
> observations but I expected from the Spatial Data Science book a continuous
> surface with predictions for all of the grid cells, as shown here:
> https://keen-swartz-3146c4.netlify.app/interpolation.html
>
> I've also asked this question on stack-overflow where the output from the
> above commands can be found: https://stackoverflow.com/questions/64541951/
>
> Thanks for reading and apologies if I'm missing something obvious.
>
> Robin
>

[[alternative HTML version deleted]]

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

[R-sig-Geo] NA values in predictions from gstat::krige()

2020-10-27 Thread Robin Lovelace

Hi all,

When using the gstat package I get NA values for the majority of cells
predicted and I'm not sure what I'm doing wrong. The data is quite noisy
and I plan to do some aggregation on the input data before trying this
again with the interpolate() function from raster/terra, but thought it
worth asking as the answer may be of use to others.

# reprex
library(sf)
library(gstat)
library(stars)
u = "
https://github.com/saferactive/saferactive/releases/download/0.1.1/rnet_lnd_1pcnt.Rds
"
rnet_lnd = readRDS(url(u))
rnet_lnd
grd = st_bbox(rnet_lnd) %>%
  st_as_stars(dx = 500, dy = 500) %>%
  st_set_crs(27700) %>%
  st_crop(rnet_lnd)
grd
v = variogram(bicycle~1, rnet_lnd, cutoff = 1)
plot(v)
vm = fit.variogram(v, vgm(psill = "Sph", model = "Exp", range = 1,
nugget = 1))
plot(vm, cutoff = 1)
rnet_krige = gstat::krige(bicycle~1, rnet_lnd, grd, vm, nmax = 100)
plot(rnet_lnd$geometry)
plot(rnet_krige, add = TRUE)

Outcome on my computer: predictions only in raster grid cells with
observations but I expected from the Spatial Data Science book a continuous
surface with predictions for all of the grid cells, as shown here:
https://keen-swartz-3146c4.netlify.app/interpolation.html

I've also asked this question on stack-overflow where the output from the
above commands can be found: https://stackoverflow.com/questions/64541951/

Thanks for reading and apologies if I'm missing something obvious.

Robin

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] convert from any spatial* classes to a specific character string

2020-09-03 Thread Robin Lovelace

Update on this, it has been implemented:
https://github.com/MatMatt/clmsapi/commit/bf7996006a96b31cc8e150b81f56c64e7da695ce

Thanks Matteo for the response to me (which may have been intended for the
list).

Robin

On Wed, Sep 2, 2020 at 4:25 PM Robin Lovelace  wrote:

> Does this help? The approach covers sf, sp and maybe other classes that
> can be converted into sf objects.
>
> ``` r
> library(spData)
> library(sf)
> #> Linking to GEOS 3.8.0, GDAL 3.0.4, PROJ 7.0.0
> x_sf = rmapshaper::ms_simplify(lnd[1:3, ], 0.01)
> #> Registered S3 method overwritten by 'geojsonlint':
> #>   method from
> #>   print.location dplyr
> x_sp = sf::as_Spatial(x_sf)
> geo_to_char = function(x) {
>   if(!is(object = x, class2 = "sf")) {
> x = sf::st_as_sf(x)
>   }
>   sf::st_as_text(sf::st_geometry(x))
> }
> geo_to_char(x_sf)
> #> [1] "POLYGON ((-0.3306791 51.32901, -0.3305339 51.34842, -0.3086951
> 51.37545, -0.3177201 51.39367, -0.3096538 51.40001, -0.3060304 51.42123,
> -0.2866189 51.42017, -0.2540906 51.43729, -0.2446848 51.40423, -0.2474248
> 51.39758, -0.2387446 51.38609, -0.2608406 51.37956, -0.2854616 51.36425,
> -0.3039032 51.34325, -0.3057101 51.33541, -0.3193073 51.32781, -0.3306791
> 51.32901))"
>
>
>
> #> [2] "POLYGON ((-0.0785486 51.41985, -0.0689427 51.40418, -0.0427724
> 51.38945, -0.0369519 51.37701, -0.0053322 51.35268, 0.0022661 51.32914,
> -0.0251301 51.33861, -0.0379184 51.33871, -0.0478549 51.32651, -0.0641537
> 51.31863, -0.0848293 51.31587, -0.0943518 51.29936, -0.1243197 51.28676,
> -0.1373403 51.30078, -0.155344 51.30128, -0.1619055 51.31963, -0.1444548
> 51.32648, -0.1475475 51.33878, -0.1275566 51.34745, -0.1169191 51.34575,
> -0.1233396 51.37119, -0.1337986 51.39127, -0.1245223 51.39741, -0.1324811
> 51.40841, -0.1126856 51.42324, -0.0785486 51.41985))"
>
> #> [3] "POLYGON ((0.0022661 51.32914, -0.0053322 51.35268, -0.0369519
> 51.37701, -0.0427724 51.38945, -0.0689427 51.40418, -0.0785486 51.41985,
> -0.0748669 51.4258, -0.0436909 51.42291, -0.0301069 51.42565, -0.0105455
> 51.41355, 0.0254105 51.42899, 0.0398142 51.44099, 0.0585966 51.42459,
> 0.0753431 51.43199, 0.1124939 51.41317, 0.134136 51.41385, 0.1488766
> 51.40848, 0.1598909 51.39465, 0.1498092 51.39087, 0.1532098 51.37804,
> 0.1362526 51.34555, 0.1166538 51.3413, 0.1202182 51.33214, 0.1047428
> 51.32734, 0.0850008 51.31602, 0.0856654 51.29309, 0.0584828 51.28936,
> 0.0457041 51.29401, 0.0328814 51.30752, 0.0149821 51.29179, 0.0022661
> 51.32914))"
> geo_to_char(x_sp)
> #> [1] "POLYGON ((-0.3306791 51.32901, -0.3305339 51.34842, -0.3086951
> 51.37545, -0.3177201 51.39367, -0.3096538 51.40001, -0.3060304 51.42123,
> -0.2866189 51.42017, -0.2540906 51.43729, -0.2446848 51.40423, -0.2474248
> 51.39758, -0.2387446 51.38609, -0.2608406 51.37956, -0.2854616 51.36425,
> -0.3039032 51.34325, -0.3057101 51.33541, -0.3193073 51.32781, -0.3306791
> 51.32901))"
>
>
>
> #> [2] "POLYGON ((-0.0785486 51.41985, -0.0689427 51.40418, -0.0427724
> 51.38945, -0.0369519 51.37701, -0.0053322 51.35268, 0.0022661 51.32914,
> -0.0251301 51.33861, -0.0379184 51.33871, -0.0478549 51.32651, -0.0641537
> 51.31863, -0.0848293 51.31587, -0.0943518 51.29936, -0.1243197 51.28676,
> -0.1373403 51.30078, -0.155344 51.30128, -0.1619055 51.31963, -0.1444548
> 51.32648, -0.1475475 51.33878, -0.1275566 51.34745, -0.1169191 51.34575,
> -0.1233396 51.37119, -0.1337986 51.39127, -0.1245223 51.39741, -0.1324811
> 51.40841, -0.1126856 51.42324, -0.0785486 51.41985))"
>
> #> [3] "POLYGON ((0.0022661 51.32914, -0.0053322 51.35268, -0.0369519
> 51.37701, -0.0427724 51.38945, -0.0689427 51.40418, -0.0785486 51.41985,
> -0.0748669 51.4258, -0.0436909 51.42291, -0.0301069 51.42565, -0.0105455
> 51.41355, 0.0254105 51.42899, 0.0398142 51.44099, 0.0585966 51.42459,
> 0.0753431 51.43199, 0.1124939 51.41317, 0.134136 51.41385, 0.1488766
> 51.40848, 0.1598909 51.39465, 0.1498092 51.39087, 0.1532098 51.37804,
> 0.1362526 51.34555, 0.1166538 51.3413, 0.1202182 51.33214, 0.1047428
> 51.32734, 0.0850008 51.31602, 0.0856654 51.29309, 0.0584828 51.28936,
> 0.0457041 51.29401, 0.0328814 51.30752, 0.0149821 51.29179, 0.0022661
> 51.32914))"
> ```
>
> Created on 2020-09-02 by the [reprex package](
> https://reprex.tidyverse.org) (v0.3.0)
>
> On Wed, Sep 2, 2020 at 1:25 PM Matteo Mattiuzzi 
> wrote:
>
>> Dear list,
>>
>> I have recently submitted a little R package to CRAN (now waiting for
>> approval) https://github.com/MatMatt/clmsapi.
>> The package is a R client for downloading data from the Copernicus Land
>> Monitoring Service (https://cryo.land.copernicus.eu/finder/).
>>
>> T

Re: [R-sig-Geo] convert from any spatial* classes to a specific character string

2020-09-02 Thread Robin Lovelace

Does this help? The approach covers sf, sp and maybe other classes that can
be converted into sf objects.

``` r
library(spData)
library(sf)
#> Linking to GEOS 3.8.0, GDAL 3.0.4, PROJ 7.0.0
x_sf = rmapshaper::ms_simplify(lnd[1:3, ], 0.01)
#> Registered S3 method overwritten by 'geojsonlint':
#>   method from
#>   print.location dplyr
x_sp = sf::as_Spatial(x_sf)
geo_to_char = function(x) {
  if(!is(object = x, class2 = "sf")) {
x = sf::st_as_sf(x)
  }
  sf::st_as_text(sf::st_geometry(x))
}
geo_to_char(x_sf)
#> [1] "POLYGON ((-0.3306791 51.32901, -0.3305339 51.34842, -0.3086951
51.37545, -0.3177201 51.39367, -0.3096538 51.40001, -0.3060304 51.42123,
-0.2866189 51.42017, -0.2540906 51.43729, -0.2446848 51.40423, -0.2474248
51.39758, -0.2387446 51.38609, -0.2608406 51.37956, -0.2854616 51.36425,
-0.3039032 51.34325, -0.3057101 51.33541, -0.3193073 51.32781, -0.3306791
51.32901))"



#> [2] "POLYGON ((-0.0785486 51.41985, -0.0689427 51.40418, -0.0427724
51.38945, -0.0369519 51.37701, -0.0053322 51.35268, 0.0022661 51.32914,
-0.0251301 51.33861, -0.0379184 51.33871, -0.0478549 51.32651, -0.0641537
51.31863, -0.0848293 51.31587, -0.0943518 51.29936, -0.1243197 51.28676,
-0.1373403 51.30078, -0.155344 51.30128, -0.1619055 51.31963, -0.1444548
51.32648, -0.1475475 51.33878, -0.1275566 51.34745, -0.1169191 51.34575,
-0.1233396 51.37119, -0.1337986 51.39127, -0.1245223 51.39741, -0.1324811
51.40841, -0.1126856 51.42324, -0.0785486 51.41985))"

#> [3] "POLYGON ((0.0022661 51.32914, -0.0053322 51.35268, -0.0369519
51.37701, -0.0427724 51.38945, -0.0689427 51.40418, -0.0785486 51.41985,
-0.0748669 51.4258, -0.0436909 51.42291, -0.0301069 51.42565, -0.0105455
51.41355, 0.0254105 51.42899, 0.0398142 51.44099, 0.0585966 51.42459,
0.0753431 51.43199, 0.1124939 51.41317, 0.134136 51.41385, 0.1488766
51.40848, 0.1598909 51.39465, 0.1498092 51.39087, 0.1532098 51.37804,
0.1362526 51.34555, 0.1166538 51.3413, 0.1202182 51.33214, 0.1047428
51.32734, 0.0850008 51.31602, 0.0856654 51.29309, 0.0584828 51.28936,
0.0457041 51.29401, 0.0328814 51.30752, 0.0149821 51.29179, 0.0022661
51.32914))"
geo_to_char(x_sp)
#> [1] "POLYGON ((-0.3306791 51.32901, -0.3305339 51.34842, -0.3086951
51.37545, -0.3177201 51.39367, -0.3096538 51.40001, -0.3060304 51.42123,
-0.2866189 51.42017, -0.2540906 51.43729, -0.2446848 51.40423, -0.2474248
51.39758, -0.2387446 51.38609, -0.2608406 51.37956, -0.2854616 51.36425,
-0.3039032 51.34325, -0.3057101 51.33541, -0.3193073 51.32781, -0.3306791
51.32901))"



#> [2] "POLYGON ((-0.0785486 51.41985, -0.0689427 51.40418, -0.0427724
51.38945, -0.0369519 51.37701, -0.0053322 51.35268, 0.0022661 51.32914,
-0.0251301 51.33861, -0.0379184 51.33871, -0.0478549 51.32651, -0.0641537
51.31863, -0.0848293 51.31587, -0.0943518 51.29936, -0.1243197 51.28676,
-0.1373403 51.30078, -0.155344 51.30128, -0.1619055 51.31963, -0.1444548
51.32648, -0.1475475 51.33878, -0.1275566 51.34745, -0.1169191 51.34575,
-0.1233396 51.37119, -0.1337986 51.39127, -0.1245223 51.39741, -0.1324811
51.40841, -0.1126856 51.42324, -0.0785486 51.41985))"

#> [3] "POLYGON ((0.0022661 51.32914, -0.0053322 51.35268, -0.0369519
51.37701, -0.0427724 51.38945, -0.0689427 51.40418, -0.0785486 51.41985,
-0.0748669 51.4258, -0.0436909 51.42291, -0.0301069 51.42565, -0.0105455
51.41355, 0.0254105 51.42899, 0.0398142 51.44099, 0.0585966 51.42459,
0.0753431 51.43199, 0.1124939 51.41317, 0.134136 51.41385, 0.1488766
51.40848, 0.1598909 51.39465, 0.1498092 51.39087, 0.1532098 51.37804,
0.1362526 51.34555, 0.1166538 51.3413, 0.1202182 51.33214, 0.1047428
51.32734, 0.0850008 51.31602, 0.0856654 51.29309, 0.0584828 51.28936,
0.0457041 51.29401, 0.0328814 51.30752, 0.0149821 51.29179, 0.0022661
51.32914))"
```

Created on 2020-09-02 by the [reprex package](
https://reprex.tidyverse.org) (v0.3.0)

On Wed, Sep 2, 2020 at 1:25 PM Matteo Mattiuzzi 
wrote:

> Dear list,
>
> I have recently submitted a little R package to CRAN (now waiting for
> approval) https://github.com/MatMatt/clmsapi.
> The package is a R client for downloading data from the Copernicus Land
> Monitoring Service (https://cryo.land.copernicus.eu/finder/).
>
> The API expects a parameter called 'geometry' with the following formatting
> (character):
> 'POLYGON((lon+lat,lon+lat,lon+lat, ... ))' # commas are replaced with ascii
> '%2C' in the query string
> or
> 'POINT(lon+lat)'
> see also here:
> https://cryo.land.copernicus.eu/resto/api/collections/HRSI/describe.xml
>
> I could expect users to prepare the geometry parameter as it is needed by
> the API, but I would prefer to improve the user friendliness by adding some
> functionalities (similar as in the MODIS package) that can convert from
> different spatial extent objects/classes to the needed character string (in
> clmsapi::composeUrl).
>
> What is the best way to implement that? What are the classes I should
> consider as input for the geometry parameter? (i.e. well established and
> well supplied with conversion-functions).
>
> Thanks a

Re: [R-sig-Geo] rgdal: About the new gdal3 and proj >=6 condition

2020-06-02 Thread Robin Lovelace

Confirmed: this worked perfectly for me.

Video evidence that this is fixed:
https://asciinema.org/a/zPQFbI6Q01oqUy1HRauCjLUXY

Thanks Roger!

Robin

On Tue, Jun 2, 2020 at 4:00 PM Roger Bivand  wrote:

> Brian Ripley (thanks!) provided a patch for rgdal's configure.ac, and the
> R-forge build and check processes now succeed, so please try to install
> either downloading
> http://download.r-forge.r-project.org/src/contrib/rgdal_1.5-9.tar.gz and
> installing from the command line (after running R CMD check), or
> install.packages("rgdal", repos="http://R-Forge.R-project.org";).
>
> Remember that if GDAL is < 3, and PROJ >= 6, you need the configure
> argument: --configure-args=--with-proj_api=proj_api.h.
>
> Roger
>
> On Sun, 31 May 2020, Roger Bivand wrote:
>
> > Fresh version of rgdal rev 995 on link and R-forge, with more tweaks to
> the
> > configure file. Please test.
> >
> > Roger
> >
> > On Fri, 29 May 2020, Roger Bivand wrote:
> >
> >>  I have put a tarball, built without vignettes with GDAL 2.2.4 and PROJ
> >>  7.0.1 that passes CMD check (with warnings for missing vignettes) on:
> >>
> >>  http://spatial.nhh.no/R/rgdal/gdal_1.5-9.tar.gz
> >>
> >>  It involves code copying to provide duplicated functions in three
> >>  settings:
> >>
> >>  PROJ < 6 & GDAL < 3
> >> PROJ >  = 6 & GDAL >= 3
> >> PROJ >  = 6 & GDAL < 3 (your homebrew case)
> >>
> >>  You need the configure argument:
> >>  --configure-args=--with-proj_api=proj_api.h.
> >>  Without the argument, you now get directed to use it.
> >>
> >>  For now I've dropped the configure tests for sqlite3, curl and tiff;
> works
> >>  for me but may not work for you.
> >>
> >>  Please make the output of:
> >>
> >>  R CMD check
> --install-args="--configure-args=--with-proj_api=proj_api.h"
> >>  rgdal_1.5-9.tar.gz
> >>
> >>  available ASAP. I count on an immediate response.
> >>
> >>  Roger
> >>
> >>  On Fri, 29 May 2020, Roger Bivand wrote:
> >>
> >>>   On Fri, 29 May 2020, Patrick Schratz wrote:
> >>>
> The just released rgdal v1.5.8 requires gdal >= 3 when proj >= 6 is
> present. It does not even install the package if this condition is
> not
> met
> but errors during linking.
> >>>
> >>>   Please document with the output of 00install.out from R CMD check
> >>>   rgdal_1.5-8.tar.gz, and pkg-config proj --modversion, gdalinfo
> --version
> >>>   with system details.
> >>>
> >>>   Yes, PROJ >= 6 makes no sense without GDAL >= 3; GDAL 3 makes no
> sense
> >>>   with PROJ < 6. GDAL 3 with PROJ < 6 uses the old proj_api.h API and
> the
> >>>   old metadata structure with Proj4 string degradation; GDAL < 3 with
> PROJ
>    = 6 must use the deprecated API and the new metadata structure.
> >>>
> 
> I could not find any sources in the web or in the announcement
> post of
> v1.5.8 why this condition was enforced so strictly.
> Does it cause unwanted results?
> >>>
> >>>   Yes, definitely. GDAL 3 was released as 3, not 2.5, to stress the
> >>>   complete
> >>>   break between GDAL 2 (with PROJ <= 5) and GDAL >= 3 (with PROJ >= 6)
> >>>   after
> >>>   GDAL barnraising. So:
> >>>
> >>> PROJ
> >>> < 6 >= 6
> >>>   GDAL < 3   OK   NO
> >>>>   = 3   NO   OK
> >>>
> >>>
> >>>
> If so, then there is a big issue since the “gdal2 and proj >= 6”
> combination has been used by many people in the past already.
> >>>
> >>>   No good precedent, just binary packagers protecting slow downstream
> >>>   adaptation.
> >>>
> I haven’t tracked down for how long this situation was on the
> market
> already.
> Also the {sf} package is still installable with this combination
> and I
> am not aware of any warnings/issues that came up due to this so
> far.
> 
> >>>
> >>>   rgdal is a much older package and has much more older code that needs
> >>>   this
> >>>   protection. It is possible to accommodate the no-go areas, but I'd
> >>>   really
> >>>   value patches to R-forge, as I cannot check multiple PROJ/GDAL
> version
> >>>   combinations just because someone isn't up to speed.
> >>>
> It further causes complete breakage for people relying on the
> homebrew
> package manager on macOS since current versions are gdal v2.2.4 and
> proj
> 7.0.1.
> >>>
> >>>   They should never have gone beyond PROJ 5 if they are stuck on GDAL.
> >>>   PROJ
> >>>   7 is a very different animal.
> >>>
> The update to gdal3 is blocked since months due to an
> incompatibility
> with `liblas` (https://github.com/libLAS/libLAS/issues/164).
> Reading
> the
> issue, it looks unclear when this issue will be resolved.
> The alternative osgeo4mac tap holds formula that is unstable and
> somewhat broken. One cannot link rgdal with the current gdal v3.0.1
> from
> osgeo4mac.
> 
> This incompatibility with homebrew-core formula leads to further
> issues
>

Re: [R-sig-Geo] rgdal 1.5-8 released on CRAN

2020-05-30 Thread Robin Lovelace

Hi all,

For what it's worth I'm having the same issue and am getting this message:

inverser.c:5:10: fatal error: projects.h: No such file or directory
 #include 
  ^~~~
compilation terminated.
/usr/lib/R/etc/Makeconf:168: recipe for target 'inverser.o' failed
make: *** [inverser.o] Error 1
ERROR: compilation failed for package ‘rgdal’
* removing ‘/home/robin/R/x86_64-pc-linux-gnu-library/3.6/rgdal’
* restoring previous ‘/home/robin/R/x86_64-pc-linux-gnu-library/3.6/rgdal’

The development version of sf installs OK. I'm on Ubuntu with the following
versions:

sf::sf_extSoftVersion()
  GEOS   GDAL proj.4 GDAL_with_GEOS USE_PROJ_H
   "3.8.0""3.0.4""7.0.0" "true" "true"

I think I need to set the proj path. My projinfo binary is at

which projinfo
# /usr/bin/projinfo

>From the thread I guess I should add the argument ,
 configure.args=c("--with-proj-include=...") but so far my attempts have
been in vain.

As a test I tried installing older versions with the following results:

remotes::install_version(package = "rgdal", version = "1.4-8") # works
remotes::install_version(package = "rgdal", version = "1.4-7") # works
remotes::install_version(package = "rgdal", version = "1.5-8") # fails

Any pointers for installation on my set-up appreciated.

I should say huge thanks to Roger and other developers in the community for
amazing work keeping track of rapidly changing upstream dependencies. It's
a small miracle that R can be used as a powerful geographic data processing
tool, with a vast array of statistical functionality a few keystrokes away.
Hope sharing my experience is useful.




On Sat, May 30, 2020 at 7:47 PM chris english 
wrote:

> Roy,
>
> I'm not OSX but generally I see them as conceptually similar and where I
> have stumbled (at what appears to be 'this stage') is in permissions so I
> would check the 'geneaology' of permissions and your ownership there upon
> the entire path of permissions that allows dynlib to execute
> comprehensively. And as you pass the rgdal hurdle so the same for gdal,
> geos. As applies to OSX, this may appear as voodoo, but if there is a sudo
> analog in OSX, try it. My voodoo (that is possibly disconcerting to those
> who view computers as logical systems. I would have advocated base 3 were I
> there at the beginning...)
>
> Chris
>
> On Sat, May 30, 2020 at 2:12 PM Roy Mendelssohn - NOAA Federal via
> R-sig-Geo  wrote:
>
> > Hi All:
> >
> > Okay after some fiddling I was able to get it to sort of successfully
> > compile,  where I am having problems is in finding the dynamic libraries,
> > such as I get this error:
> >
> > > dyld: Library not loaded: @rpath/libproj.19.dylib
> >
> > and
> >
> > > Error: package or namespace load failed for ‘rgdal’ in dyn.load(file,
> > DLLpath = DLLpath, ...):
> > >  unable to load shared object
> >
> '/Users/rmendels/Library/R/4.0/library/00LOCK-rgdal/00new/rgdal/libs/rgdal.so':
> > >
> >
> dlopen(/Users/rmendels/Library/R/4.0/library/00LOCK-rgdal/00new/rgdal/libs/rgdal.so,
> > 6): Library not loaded: @rpath/libgdal.26.dylib
> > >   Referenced from:
> >
> /Users/rmendels/Library/R/4.0/library/00LOCK-rgdal/00new/rgdal/libs/rgdal.so
> > >   Reason: image not found
> > > Error: loading failed
> >
> > It has to do with these are defined in terms of @rpath.  I thought
> > defining this in $LD_LIBRARY_PATH would do it,  but I have:
> >
> > > echo $LD_LIBRARY_PATH
> > > /Users/rmendels/Library/R/4.0/library:/Users/rmendels/anaconda3/lib
> >
> > I also tried setting$DYLD_LIBRARY_PATH same problem.  If someone can
> > tell me how to set it so @rpath finds the dynamic libraries I might be
> able
> > to get this to work.
> >
> > Thanks,
> >
> > -Roy
> >
> >
> >
> > > On May 30, 2020, at 8:04 AM, chris english <
> > englishchristoph...@gmail.com> wrote:
> > >
> > > my setup - albeit on 20.04 as reported by sf
> > >
> > > > library(sf)
> > > Linking to GEOS 3.9.0dev, GDAL 3.1.0, PROJ 7.0.1
> > >
> > > Note I'm using release gdal, that I none the less built from source as
> I
> > had to enable Mr. Sid for some particular
> > >  data. Couldn't get GDAL 3.2.*dev working but still toying around with
> > it. Roger's discussion of the history of all
> > > of this on r-spatial and the path forward is very much worth the read
> as
> > and relates to his following message here.
> > >
> > >
> > >
> > > On Sat, May 30, 2020 at 10:33 AM Roy Mendelssohn - NOAA Federal <
> > roy.mendelss...@noaa.gov> wrote:
> > > Yes thanks.  As I said in reply to Roger I am far from an expert in
> > these things,  but if I can get it to build,  then I will try to post
> > somewhere for others to use.
> > >
> > > -Roy
> > >
> > > > On May 30, 2020, at 7:03 AM, chris english <
> > englishchristoph...@gmail.com> wrote:
> > > >
> > > > Roy,
> > > > From a related prior post Roger shared this link to rgdal-1.5-9,
> > http://spatial.nhh.no/R/rgdal/ . I followed discussions
> > > > from the 'sf' github re

[R-sig-Geo] Recommended set-up for r-spatial packages on Linux

2020-03-01 Thread Robin Lovelace

I'm asking out of interest and in anticipation of students and others
asking, and am wondering if my default answer needs to be re-assessed. For
details see here: https://github.com/r-spatial/discuss/issues/35

Replies here very welcome.

Thanks.

[[alternative HTML version deleted]]

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

[R-sig-Geo] Spatilal Network Hackathon

2020-02-19 Thread Robin Lovelace

Dear all,

We are happy to invite you to join a hackathon on spatial networks on the*
27th of May at the University of Milan - Bicocca from 9AM to 5PM. *The
hackathon is an official satellite event of the European R Users Meeting
(ERUM) <https://2020.erum.io/> conference, that will be organized in Milan
from 27th to 30th of May. The hackathon will be focussed on developing and
testing of the new R package for spatial networks: sfnetworks.

Anyone with an interest in spatial networks and open source software is
invited, especially if you have experience with real world spatial network
data that could be used in documentation or experience developing software
for working with spatial or graph datasets (particularly R packages).

The event is free and you can get a ticket at the following link:
https://www.eventbrite.co.uk/e/erum2020-satellite-event-hackathon-on-spatial-networks-tickets-90976873277
You can read a more detailed description of the event at the following
link: https://2020.erum.io/program/hackathon/

*Summary*:

   - *What*: A hackathon on spatial networks where we will present our new
   R package and discuss with the participants the problems they face working
   with spatial networks.
   - *Who*: Everyone working on or interested in spatial networks can join
   the hackathon. The only minimal requirement is a basic knowledge of sf
   and igraph packages. We will provide a few vignettes explaining how our
   package works, so you don't need to be an expert in the field.
   - *When*: 27th of May, from 9AM to 5PM
   - *Where*: University of Milan - Bicocca, the same building of the
   ERUM2020 conference. We will specify the venue of the event as soon as
   possible. You can also find more information on how to reach the venue
   here <https://2020.erum.io/venue/>.

Best wishes, Lorena Abad, Andrea Gilardi, Robin Lovelace, Lucan van der
Meer.

[[alternative HTML version deleted]]

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

[R-sig-Geo] Feedback request and heads-up: open source book

2018-09-05 Thread Robin Lovelace

Hi all,

*Summary*

As mentioned on this list already there is a new book project on R-spatial
called Geocomputation with R. It's an open source and publicly accessible
project which can be found in its entirety here:
https://geocompr.robinlovelace.net/

The purpose of this email is to inform you that the book is now mostly
complete and ready for use. It's also to request feedback before it gets
sent to the printers in early October. There's a ~month long window of
opportunity to contribute, alongside others who have kindly helped already,
to the printed version:
https://github.com/robinlovelace/geocompr#contributing

...

*Details*

A major aim of the project is to provide high quality, up-to-date teaching
material free of charge to people around the world. We have been working on
it for over a year. But only in the last month have we got a cohesive draft
of all 15 chapters, so now is a good time to take a look and start using it
for your own teaching/learning: few things will change in the content.
However, we have a deadline at the end of September to submit the final
draft for the physical book.

Each of us is an experienced R user for geographic applications. We have
some development experience. And each chapter (except for 10, 14 and 15)
have undergone a formal process of 'technical review'. But there will still
inevitably be mistakes, parts that are not clear, and a huge amount of room
for improvement.

We are therefore sending this message to ask for feedback. People in the
wider R-spatial community, and especially readers of the r-sig-geo list
messages, have a huge amount of expertise. We would therefore be grateful
for suggestions from you. Especially useful would feedback on:

   - Any key functions or topics we're missing (note the commonly requested
   topic of spatial interpolation is well-covered in other resources, and gets
   a mention in an extended example at ).
   - Any bits of the explanation that are not crystal clear? Please let us
   know. We try to use plain English but there is definitely room for
   improvement in the prose in many sections.
   - Any exercises that don't make sense, are too easy/hard or are
   unhelpful?

We've had loads of support so far from many people in the form of comments,
reviews and suggestions. And the fact that R-spatial exists at all is
thanks to developers like Edzer and Roger who's code underlies much of what
we have written. So the final thing to say is thanks for being part of the
community that has made this possible. We hope the book contributes to the
community.

For info on how to contribute and the book directly via a Pull Request, see
here: https://geocompr.robinlovelace.net/index.html#how-to-contribute but
emails to me on this address are equally appreciated if you spot anything.

Robin, Jakub and Jannes.

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Spatial Query (Selection) with Apply

2018-08-29 Thread Robin Lovelace

Hi Ariel,

Glad it helped.

Yes you could place your apply command into a lapply to get a list of
matrices.

Something like this should work:

dist_list <- lapply(tmp, function(coord) {

   apply(X = coord, MARGIN = 1, FUN = function(x) spDistsN1(coord, x,
longlat = T)

}

Robin



On Tue, Aug 28, 2018 at 9:13 PM, Ariel Fuentesdi 
wrote:

> Thanks, Robin
>
> It worked perfectly, although I transformed the data from sf to
> SpatialDataFrame objects with:
>
> zones <- as(zones, "Spatial")
> nodes <- as(nodes, "Spatial")
>
> The next step I will follow is to create Distance Matrix like this:
>
> coord <- tmp2[[1]]@coords
> dist1 <- apply(X = coord, MARGIN = 1, FUN = function(x) spDistsN1(coord,
> x, longlat = T))
>
> obviously, the task is a distance matrix for every selection. ¿What would
> you recommend, the aggregate function as you talked before or something
> like a nested apply?
>
> Regards,
> Ariel
>
>
>
> 2018-08-27 19:32 GMT-03:00 Robin Lovelace :
>
>> Hi Ariel,
>>
>> It helps when asking for help with code to produce a reproducible
>> example. To understand your input data I've created nodes and zones based
>> on the spData data nz_height and nz_elev. Based on the assumption you want
>> to find all the nodes in each zone I think the direct answer to your
>> question is something like the following:
>>
>> tmp2 = lapply(s, function(x) {
>>   nodes[zones[x, ], ]
>> })
>>
>> The longer answer is that aggregate(), st_join() +
>> aggregate()/summarize() may provide quicker solutions, depending on what
>> you want to do with the points after grouping them by which zone they fall
>> in.
>> Note: I've used sf objects based on the explanation here
>> https://geocompr.robinlovelace.net/spatial-operations.html#spatial-vec
>> which may not work with sp data but the aggregate code should work roughly
>> the same:
>>
>> # install.packages("sf")
>> # install.packages("spData")
>> library(spData)
>> library(sf)
>> #> Linking to GEOS 3.6.2, GDAL 2.2.3, proj.4 4.9.3
>> zones = nz
>> nodes = nz_height
>> tmp = list()
>> s = 1:nrow(nz)
>>
>> for(i in s) {
>>   tmp[[i]] = nodes[nz[i, ], ]
>> }
>>
>> # understand what's going on with plots (not shown)
>> # plot(st_geometry(nz))
>> # plot(st_geometry(tmp[[i]]), add = TRUE, col = "red")
>> # plot(nz[i, ], col = "green", add = TRUE)
>>
>> tmp2 = lapply(s, function(x) {
>>   nz_height[nz[x, ], ]
>> })
>>
>> identical(tmp, tmp2)
>> #> [1] TRUE
>>
>> Created on 2018-08-27 by the [reprex package](http://reprex.tidyverse.org)
>> (v0.2.0).
>>
>> I've also pasted the reprex into the geocompr github tracker so the plots
>> can be seen and the code formatted: https://github.com/Robinlovela
>> ce/geocompr/issues/294
>>
>> Hope this helps,
>>
>> Robin
>>
>>
>> On Mon, Aug 27, 2018 at 9:53 PM, Ariel Fuentesdi <
>> ariel.fuente...@usach.cl> wrote:
>>
>>> Hi,
>>>
>>> I want to do multiple selections of a point shapefile based on polygons
>>> on
>>> other layers, I can do this in a for loop, but I desire to do this in a
>>> function of the apply family.
>>>
>>> I named the point shapefile "nodes" and the polygons shapefile "zones".
>>>
>>> This is what I did:
>>>
>>> tmp <- list()
>>> for (i in 1:nrow(zones@data)) {
>>> tmp[[i]] <- nodes[subset(zones, ESTUDIO == i),]
>>> tmp
>>>   }
>>>
>>> But I have no clue how to change it to the apply family, can you provide
>>> an example of this?
>>>
>>> Thanks in advance.
>>>
>>> Regards,
>>> Ariel Fuentes
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> ___
>>> R-sig-Geo mailing list
>>> R-sig-Geo@r-project.org
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>
>>
>>
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Spatial Query (Selection) with Apply

2018-08-27 Thread Robin Lovelace

Hi Ariel,

It helps when asking for help with code to produce a reproducible example.
To understand your input data I've created nodes and zones based on the
spData data nz_height and nz_elev. Based on the assumption you want to find
all the nodes in each zone I think the direct answer to your question is
something like the following:

tmp2 = lapply(s, function(x) {
  nodes[zones[x, ], ]
})

The longer answer is that aggregate(), st_join() + aggregate()/summarize()
may provide quicker solutions, depending on what you want to do with the
points after grouping them by which zone they fall in.
Note: I've used sf objects based on the explanation here https://geocompr.
robinlovelace.net/spatial-operations.html#spatial-vec which may not work
with sp data but the aggregate code should work roughly the same:

# install.packages("sf")
# install.packages("spData")
library(spData)
library(sf)
#> Linking to GEOS 3.6.2, GDAL 2.2.3, proj.4 4.9.3
zones = nz
nodes = nz_height
tmp = list()
s = 1:nrow(nz)

for(i in s) {
  tmp[[i]] = nodes[nz[i, ], ]
}

# understand what's going on with plots (not shown)
# plot(st_geometry(nz))
# plot(st_geometry(tmp[[i]]), add = TRUE, col = "red")
# plot(nz[i, ], col = "green", add = TRUE)

tmp2 = lapply(s, function(x) {
  nz_height[nz[x, ], ]
})

identical(tmp, tmp2)
#> [1] TRUE

Created on 2018-08-27 by the [reprex package](http://reprex.tidyverse.org)
(v0.2.0).

I've also pasted the reprex into the geocompr github tracker so the plots
can be seen and the code formatted: https://github.com/
Robinlovelace/geocompr/issues/294

Hope this helps,

Robin

On Mon, Aug 27, 2018 at 9:53 PM, Ariel Fuentesdi 
wrote:

> Hi,
>
> I want to do multiple selections of a point shapefile based on polygons on
> other layers, I can do this in a for loop, but I desire to do this in a
> function of the apply family.
>
> I named the point shapefile "nodes" and the polygons shapefile "zones".
>
> This is what I did:
>
> tmp <- list()
> for (i in 1:nrow(zones@data)) {
> tmp[[i]] <- nodes[subset(zones, ESTUDIO == i),]
> tmp
>   }
>
> But I have no clue how to change it to the apply family, can you provide
> an example of this?
>
> Thanks in advance.
>
> Regards,
> Ariel Fuentes
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

[R-sig-Geo] Any plans to provide access to CGAL in R?

2017-07-10 Thread Robin Lovelace

Hi all,

I've just been made aware of the CGAL  C++ library
for computational geometry.

It seems to be able to do some things that may be useful to some readers of
of this list, as outlined in this overview of a syllabus based on CGAL:
http://delivery.acm.org/10.1145/293/2927362/a8-alliez.pdf

I've found some non-CRAN packages that link to it but nothing that seems to
provide access to all CGAL functions (listed below). Any ideas if there are
plans afoot for this or even if it's worth doing?


   - http://kien-kieu.github.io/lite/rlite.html
   - https://github.com/rcqls/EBSpatCGAL

There is also TDA on CRAN:
https://cran.r-project.org/web/packages/TDA/index.html

And a C++ library that claims to support it for simple features (found by
looking for support in QGIS): https://github.com/Oslandia/SFCGAL

Plus a question on StackExchange:
https://stackoverflow.com/questions/14463590/cgal-tools-is-there-an-interface-to-cgal-or-equivalent-toolset-in-r

Thanks in advance,

Robin

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Plotting 2 rasters over each other on a map with 2D colour scheme

2016-09-22 Thread Robin Lovelace

Hi Vasya

To some extent this is more a visualisation question than a geospatial
question but is interesting because it's common to want to plot 2 variables
together. Your question comes at a good time because there has recently
been published a package for solving precisely this problem: *colorspace*.

https://github.com/wmurphyrd/colorplaner

There are mapping examples in there, but not with raster data. I'm sure you
could use it to solve your problem, however.

Another approach is to use the magick image manipulation package.

Here's some code and an image showing the result.

Code: https://gist.github.com/Robinlovelace/9d9844886ec186c4423b611e6185392e

Resulting image (sorry about the 'pipes' Edzer!): https://flic.kr/p/Mj5cos

I suggest the colorplane package instead of the *magick* way (unless
someone knows of a better solution) at present because it also seems to
create a legend for you.

If you provide a simple, reproducible example to start with, that will
increase the probability of someone helping out.

On Thu, Sep 22, 2016 at 11:51 AM, Vasya Pupkin via R-sig-Geo <
r-sig-geo@r-project.org> wrote:

> Hi guys,
>
> What I am trying to do is to make a map that would show the areas which
> are hot-dry, hot-wet, cold-dry, cold-wet. I have 2 rasters with
> precipitation and temperature values. And I want to plot them over each
> other so that each extreme combination of the 2 variables (hot-dry,
> hot-wet, cold-dry, cold-wet) would have its own colour with respective
> gradients for the intermediate values on the colour scheme, that will have
> to produce a 2D colour legend. Below please see a link to the concept
> image, that I have produced for explanation. I saw such a thing once and
> thought that was a briliant idea to show how 2 variables interact, but then
> I totally forgot where it was. I have been googling for 2 days - no result.
> Any help is very much welcome - the name of the thing, name of the software
> to do it (how to do it would be marvelous), keywords to google, workarounds
> - anything.
>
> Concept image:
> https://cloud.mail.ru/public/SHno/98X3czaW5
>
> Best wishes,
> Vasya.
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Combine line segments into one line

Re: [R-sig-Geo] Combine line segments into one line

[R-sig-Geo] Feedback on priorities for a 2nd edition of Geocomputation with R

Re: [R-sig-Geo] NA values in predictions from gstat::krige()

[R-sig-Geo] NA values in predictions from gstat::krige()

Re: [R-sig-Geo] convert from any spatial* classes to a specific character string

Re: [R-sig-Geo] convert from any spatial* classes to a specific character string

Re: [R-sig-Geo] rgdal: About the new gdal3 and proj >=6 condition

Re: [R-sig-Geo] rgdal 1.5-8 released on CRAN

[R-sig-Geo] Recommended set-up for r-spatial packages on Linux

[R-sig-Geo] Spatilal Network Hackathon

[R-sig-Geo] Feedback request and heads-up: open source book

Re: [R-sig-Geo] Spatial Query (Selection) with Apply

Re: [R-sig-Geo] Spatial Query (Selection) with Apply

[R-sig-Geo] Any plans to provide access to CGAL in R?

Re: [R-sig-Geo] Plotting 2 rasters over each other on a map with 2D colour scheme

16 matches

Site Navigation

Mail list logo

Footer information