[R-sig-Geo] rgdal, regeos, maptools retirement: a world vanishing
Dear Roger, I had missed your message about rgdal, rgeos, maptools and your retirement... As being retired since 2 years, and emeritus as yourself, I can tell you how free an "emeritus" can be when rid of all forms of bureaucracies, competition for grants and institutional top-down injunctions. To tell you the truth I never had before a so deep feeling of being free to do the job for which I was paid for than since I am retired/emeritus. I want to warmly thank you for all the work done since decades (speaking in the name of many in our lab). I remember our correspondence when I was back from field work in China, in the early 2000, when I was asking you how graphics could help and handle shapes and mapping... and I still have the first edition of Applied Spatial Data Analysis with R with your signing mentioning those early times. Of course thenafter, rgal, rgeos and maptools have been instrumental for most of my papers in ecology and epidemiology. For sure, we will be a bit lost (and a bit scared not to find equivalent facilities) in rewriting a large number of scripts with other libraries... Anyway, I wish you all the best for your new life, and hope our paths will anyway cross from time to time... Cheers, Patrick ---- *Patrick GIRAUDOUX* Professor emeritus of ecology Honorary member of the /Institut universitaire de France/ Distinguished professor of the Yunnan University of Finance and Economics, China *Chrono-environnement* UMR UFC/CNRS 6249 usc INRA Université de Franche-Comté La Bouloie 25030 Besançon Cedex, France Web sites: Perso <https://chrono-environnement.univ-fcomte.fr/personnes/annuaire/article/giraudoux-patrick?lang=en> Lab <http://chrono-environnement.univ-fcomte.fr/> IRN EHEDE <http://gdri-ehede.univ-fcomte.fr/> Zone atelier (LTSER site) Arc jurassien <https://zaaj.univ-fcomte.fr/spip.php?article29> Metadata portal dat@osu<http://dataosu.obs-besancon.fr/search.php?s=giraudoux> [[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] reading geopackage gpkg with readOGR
Apologize to answer to myself, but this morning I had advise from a
colleague who confirmed that *.gpkg files can be read straightfully with
st_read("trspixNarati_alt_UTM44.gpkg")
readOGR("trspixNarati_alt_UTM44.gpkg")
Trying again this morning, indeed, the file can be read as:
readOGR("trspixNarati_alt_UTM44.gpkg") # package in the working directory
readOGR("./Shapes/trspixNarati_alt_UTM44.gpkg") # package in the
'Shapes' folder
Quite incomprehensible why it did not work yesterday...
Le 13/04/2021 à 08:35, Patrick Giraudoux a écrit :
>
> Dear listers,
>
> I did not find the way to open a geopackage using rgdal::readOGR.
>
> The package name is 'trspixNarati_alt_UTM44.gpkg' (with two companion
> files: 'trspixNarati_alt_UTM44.gpkg-shm' and
> 'trspixNarati_alt_UTM44.gpkg-wal') stored in a folder 'Shapes'
>
> The corresponding object should be a SpatialPointsDataFrame.
>
> I have tried several combinations (a bit blind) with
>
> readOGR("./Shapes/trspixNaratiUTM44_alt_UTM44.gpkg")
>
> readOGR("./Shapes/","trspixNaratiUTM44_alt_UTM44.gpkg")
>
> readOGR("./Shapes/","trspixNaratiUTM44_alt_UTM44")
>
> with no success...
>
> This link https://jsta.github.io/2016/07/14/geopackage-r.html gives
> indications on the how to to it, but supposes that one knows a layer
> name (which is not my case)
>
> Any idea about the syntax of this driver ?
>
> Best,
>
> Patrick
>
[[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] reading geopackage gpkg with readOGR
Dear listers,
I did not find the way to open a geopackage using rgdal::readOGR.
The package name is 'trspixNarati_alt_UTM44.gpkg' (with two companion
files: 'trspixNarati_alt_UTM44.gpkg-shm' and
'trspixNarati_alt_UTM44.gpkg-wal') stored in a folder 'Shapes'
The corresponding object should be a SpatialPointsDataFrame.
I have tried several combinations (a bit blind) with
readOGR("./Shapes/trspixNaratiUTM44_alt_UTM44.gpkg")
readOGR("./Shapes/","trspixNaratiUTM44_alt_UTM44.gpkg")
readOGR("./Shapes/","trspixNaratiUTM44_alt_UTM44")
with no success...
This link https://jsta.github.io/2016/07/14/geopackage-r.html gives
indications on the how to to it, but supposes that one knows a layer
name (which is not my case)
Any idea about the syntax of this driver ?
Best,
Patrick
[[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] generating points from random to overdispersed on a raster grid.
Le 22/06/2020 à 16:20, Roger Bivand a écrit : > On Sat, 20 Jun 2020, Patrick Giraudoux wrote: > >> Dear listers, >> >> On a simulation purpose, I would like to generate data variying from >> random to various degrees of overdispersion on a raster grid. For >> instance on a matrix 1000 x 1000, to select a number of pixels that >> could be considered spatially aggregated (with a possibility for tuning >> the degree of aggregation from "random" - no aggregation - to strong >> clusters). >> >> Has anyone heard about how to proceed or an idea about it? > > This sounds very much like spatstat, but could you provide a short > code example to show what the discretised output should be? Are these > presence/absence in the grid cells? > > Best wishes, > > Roger Good point Roger. Actually some earlier answers helped be even to clarify the problem in my mind... I did not realise at first there was two hidden components in my question. I becomes clear that the way to adress the issue is scale dependent. If the need is to simulate spatial aggregation of points (e.g. vole colonies or vole individuals), thus we probably need to dig in Akos' proposition and spatstat, indeed. If the need is to simulate overdispersed densities (e.g. according to a e.g. negbinomial distribution), thus selecting pixels randomly on a raster and giving them the values computed on the negbinomial distribution should make it. Both can be combined to obtain a perfect mess The ball is now in my and collaborator's court ! Thanks anyway to responders who really helped be to go a step further (below David Pleydell's answer, a former postdoc now researcher at INRA, contacted directly off list, but this might be of interest or other listers). Le 22/06/2020 à 13:01, David Pleydell a écrit : Hi Patrick (...) Since the Poisson is a special case of negative binomial then why not? https://en.wikipedia.org/wiki/Negative_binomial_distribution#Poisson_distribution According to the above chunk of wikipedia, as r -> Inf the neg binomial converges to Poisson. So in a spatial model you could include log(r) (or log(1/r)) as a Gaussian random field (or Markov random field, or 2-D spline etc etc). You would need to give some thought as to how to parameterise this - i.e. if there was no data would you want over-dispersed vs Poisson to be equally likely, or should the prior favour one or the other? If this is a (modestly sized) spatial model it should be possible to use the conditional-autoregressive (CAR) priors that Andrew Lawson has written for nimble (https://r-nimble.org/nimbleExamples/CAR.html). These are adaptations of what has previously been implemented in geo-BUGS (with the added advantage of the flexibility and transparency of nimble). One potential limit of this option is that under-dispersion is assumed to not take place. So a slightly different approach would be needed for potentially territorial animals (e.g. blackbirds). In this case a gamma distribution could be more flexible: when scale=1 then mean=variance, when scale <1 variance1 variance>mean. [[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] generating points from random to overdispersed on a raster grid.
Dear listers, On a simulation purpose, I would like to generate data variying from random to various degrees of overdispersion on a raster grid. For instance on a matrix 1000 x 1000, to select a number of pixels that could be considered spatially aggregated (with a possibility for tuning the degree of aggregation from "random" - no aggregation - to strong clusters). Has anyone heard about how to proceed or an idea about it? Best, Patrick [[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] how to specify the size of device so that it fits a SpatialPolygonsDataFrame plot exactly
Le 29/07/2019 à 11:12, Roger Bivand a écrit :
On Sun, 28 Jul 2019, Patrick Giraudoux wrote:
Le 28/07/2019 à 17:08, Roger Bivand a écrit : This feels like a
section in
ASDAR, ch. 3, and code chunks 24-27 in
https://asdar-book.org/book2ed/vis_mod.R. Could you please try that
first
by way of something reproducible?
Le 28/07/2019 à 17:15, Patrick Giraudoux a écrit :
Ups... How can I have missed this chapter of my bible ;-) ? (must
admit I
had been on google first). Will re-read it carefully and come back
to the
list with a solution or a reproducible example, indeed.
OK. Read it again, I was not totally lost. Here is a reproducible
example. To ease reproducibility with simple objects, I will use two
bounding boxes. bbChina in WGS84, bbChinaUTM47 in UTM47. I want a
window fitting the WGS84, and you'll see I get it through a strange way.
bbChina <- new("SpatialPolygons", polygons = list(new("Polygons",
Polygons = list( new("Polygon", labpt = c(104.8, 35.95), area =
2372.28, hole = FALSE, ringDir = 1L, coords = structure(c(73, 73,
136.6, 136.6, 73, 17.3, 54.6, 54.6, 17.3, 17.3), .Dim = c(5L, 2L,
plotOrder = 1L, labpt = c(104.8, 35.95), ID = "1", area = 2372.28)),
plotOrder = 1L, bbox = structure(c(73, 17.3, 136.6, 54.6), .Dim =
c(2L, 2L), .Dimnames = list(c("x", "y"), c("min", "max"))),
proj4string = new("CRS", projargs = "+init=epsg:4326 +proj=longlat
+datum=WGS84 +no_defs +ellps=WGS84 +towgs84=0,0,0"))
bbChinaUTM47 <- new("SpatialPolygons", polygons =
list(new("Polygons", Polygons = list( new("Polygon", labpt =
c(856106.391943348, 4317264.60126758 ), area = 30651262771540.1, hole
= FALSE, ringDir = 1L, coords = structure(c(-2331000.09677063,
-2331000.09677063, 4043212.88065733, 4043212.88065733,
-2331000.09677063, 1912947.1678777, 6721582.03465746,
6721582.03465746, 1912947.1678777, 1912947.1678777), .Dim = c(5L,
2L, plotOrder = 1L, labpt = c(856106.391943348,
4317264.60126758), ID = "1", area = 30651262771540.1)), plotOrder =
1L, bbox = structure(c(-2331000.09677063, 1912947.1678777,
4043212.88065733, 6721582.03465746), .Dim = c(2L, 2L), .Dimnames =
list(c("x", "y"), c("min", "max"))), proj4string = new("CRS",
projargs = "+init=epsg:4326 +proj=longlat +datum=WGS84 +no_defs
+ellps=WGS84 +towgs84=0,0,0"))
Then let's go:
Example #1: here, being straightforward we get two indesirable white
strips on the sides:
width1<-max(bbox(bbChina)[1,])-min(bbox(bbChina)[1,])
height1<-max(bbox(bbChina)[2,])-min(bbox(bbChina)[2,])
ratio<-width1/height1
ratio
windows(height=8,width=8*ratio)
par(mar=c(0,0,0,0))
plot(bbChina,col="grey",xaxs='i', yaxs='i')
dev.off()
Example #2: computing the ratio on UTM47, but plotting WGS84
(strange), I get a better fit but with still two small white strips
up and down.
width1<-max(bbox(bbChinaUTM47)[1,])-min(bbox(bbChinaUTM47)[1,])
height1<-max(bbox(bbChinaUTM47)[2,])-min(bbox(bbChinaUTM47)[2,])
ratio<-width1/height1
ratio
windows(height=8,width=8*ratio)
par(mar=c(0,0,0,0))
plot(bbChina,col="grey",xaxs='i', yaxs='i') # no data range extention
(xaxs and yaxs parameter)
dev.off()
Example #3: multiplying the ratio by 1.04, I get a good fit
width1<-max(bbox(bbChinaUTM47)[1,])-min(bbox(bbChinaUTM47)[1,])
height1<-max(bbox(bbChinaUTM47)[2,])-min(bbox(bbChinaUTM47)[2,])
ratio<-width1/height1
ratio
windows(height=8,width=8*ratio*1.04)
par(mar=c(0,0,0,0))
plot(bbChina,col="grey",xaxs='i', yaxs='i')
dev.off()
Looks like the issue has something to do with the way CRS are handled
when plotting objects, mmmh ? Tricky isn't it ?
Yes, and the section in the book only discusses projected objects, as
geographical coordinates are stretched N-S proportionally to the
distance from the Equator. For the UTM47 object, I have:
library(sp)
bbChinaUTM47 <-
SpatialPolygons(list(Polygons(list(Polygon(matrix(c(-2331000.09677063,
-2331000.09677063, 4043212.88065733, 4043212.88065733,
-2331000.09677063, 1912947.1678777, 6721582.03465746,
6721582.03465746, 1912947.1678777, 1912947.1678777), ncol=2))),
ID="1")), proj4string=CRS("+proj=utm +zone=47")) # you had longlat, so
triggering the stretching.
x11() # or equivalent
dxy <- apply(bbox(bbChinaUTM47), 1, diff)
dxy
ratio <- dxy[1]/dxy[2]
ratio
pin <- par("pin")
pin
par(pin=c(ratio * pin[2], pin[2]), xaxs="i", yaxs="i")
plot(bbChinaUTM47)
box()
where the box overlaps the SP object. To finesse:
c(ratio * pin[2], pin[2])
dev.off()
X11(width=6.85, height=5.2)
par(mar=c(0,0,0,0)+0.1)
pin <- par("pin")
par(pin=c(ratio * pin[2], pin[2]), xaxs="i", yaxs="i")
plot(bbChinaUTM47)
box()
dev.off()
From plot.Spatial(), asp is set to 1/cos((m
Re: [R-sig-Geo] how to specify the size of device so that it fits a SpatialPolygonsDataFrame plot exactly
> Le 28/07/2019 à 17:08, Roger Bivand a écrit :
> This feels like a section in ASDAR, ch. 3, and code chunks 24-27 in
> https://asdar-book.org/book2ed/vis_mod.R. Could you please try that
> first by way of something reproducible?
Le 28/07/2019 à 17:15, Patrick Giraudoux a écrit :
>
> Ups... How can I have missed this chapter of my bible ;-) ? (must
> admit I had been on google first). Will re-read it carefully and come
> back to the list with a solution or a reproducible example, indeed.
OK. Read it again, I was not totally lost. Here is a reproducible
example. To ease reproducibility with simple objects, I will use two
bounding boxes. bbChina in WGS84, bbChinaUTM47 in UTM47. I want a
window fitting the WGS84, and you'll see I get it through a strange way.
bbChina <- new("SpatialPolygons", polygons = list(new("Polygons",
Polygons = list( new("Polygon", labpt = c(104.8, 35.95), area = 2372.28,
hole = FALSE, ringDir = 1L, coords = structure(c(73, 73, 136.6, 136.6,
73, 17.3, 54.6, 54.6, 17.3, 17.3), .Dim = c(5L, 2L, plotOrder = 1L,
labpt = c(104.8, 35.95), ID = "1", area = 2372.28)), plotOrder = 1L,
bbox = structure(c(73, 17.3, 136.6, 54.6), .Dim = c(2L, 2L), .Dimnames =
list(c("x", "y"), c("min", "max"))), proj4string = new("CRS", projargs =
"+init=epsg:4326 +proj=longlat +datum=WGS84 +no_defs +ellps=WGS84
+towgs84=0,0,0"))
bbChinaUTM47 <- new("SpatialPolygons", polygons = list(new("Polygons",
Polygons = list( new("Polygon", labpt = c(856106.391943348,
4317264.60126758 ), area = 30651262771540.1, hole = FALSE, ringDir = 1L,
coords = structure(c(-2331000.09677063, -2331000.09677063,
4043212.88065733, 4043212.88065733, -2331000.09677063, 1912947.1678777,
6721582.03465746, 6721582.03465746, 1912947.1678777, 1912947.1678777),
.Dim = c(5L, 2L, plotOrder = 1L, labpt = c(856106.391943348,
4317264.60126758), ID = "1", area = 30651262771540.1)), plotOrder = 1L,
bbox = structure(c(-2331000.09677063, 1912947.1678777, 4043212.88065733,
6721582.03465746), .Dim = c(2L, 2L), .Dimnames = list(c("x", "y"),
c("min", "max"))), proj4string = new("CRS", projargs = "+init=epsg:4326
+proj=longlat +datum=WGS84 +no_defs +ellps=WGS84 +towgs84=0,0,0"))
Then let's go:
Example #1: here, being straightforward we get two indesirable white
strips on the sides:
width1<-max(bbox(bbChina)[1,])-min(bbox(bbChina)[1,])
height1<-max(bbox(bbChina)[2,])-min(bbox(bbChina)[2,])
ratio<-width1/height1
ratio
windows(height=8,width=8*ratio)
par(mar=c(0,0,0,0))
plot(bbChina,col="grey",xaxs='i', yaxs='i')
dev.off()
Example #2: computing the ratio on UTM47, but plotting WGS84 (strange),
I get a better fit but with still two small white strips up and down.
width1<-max(bbox(bbChinaUTM47)[1,])-min(bbox(bbChinaUTM47)[1,])
height1<-max(bbox(bbChinaUTM47)[2,])-min(bbox(bbChinaUTM47)[2,])
ratio<-width1/height1
ratio
windows(height=8,width=8*ratio)
par(mar=c(0,0,0,0))
plot(bbChina,col="grey",xaxs='i', yaxs='i') # no data range extention
(xaxs and yaxs parameter)
dev.off()
Example #3: multiplying the ratio by 1.04, I get a good fit
width1<-max(bbox(bbChinaUTM47)[1,])-min(bbox(bbChinaUTM47)[1,])
height1<-max(bbox(bbChinaUTM47)[2,])-min(bbox(bbChinaUTM47)[2,])
ratio<-width1/height1
ratio
windows(height=8,width=8*ratio*1.04)
par(mar=c(0,0,0,0))
plot(bbChina,col="grey",xaxs='i', yaxs='i')
dev.off()
Looks like the issue has something to do with the way CRS are handled
when plotting objects, mmmh ? Tricky isn't it ?
[[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] how to specify the size of device so that it fits a SpatialPolygonsDataFrame plot exactly
Le 28/07/2019 à 17:08, Roger Bivand a écrit :
On Sat, 27 Jul 2019, Patrick Giraudoux wrote:
Dear listers,
I would like to write jpeg (or png, etc.) maps using the function
graphics:jpeg (png, etc.), but with the device window exactly fitting
the map (= no white strip above, below or on the sides of the map).
The map is derived from a SpatialPolygonsDataFrame (WGS84)
However, even if I set
par(mar=c(0,0,0,0) and pass xaxs='i', yaxs='i' in the plot, there are
still white strips
I tried several tricks but none are fully satisfying.
Trial #1: I computed the ratio of the bounding box and using this
ratio in the function jpeg with the height and width arguments. I did
it both in WGS84 and in UTM47:
ratio<-(max(bbox(ChinaUTM)[1,])-min(bbox(ChinaUTM)[1,]))/(max(bbox(ChinaUTM)[2,])-min(bbox(ChinaUTM)[2,]))
# ratio width/height
then
jpeg("./MapChina.jpeg",height=8,width=8*ratio,res=300,units="in")
par(mar=c(0,0,0,0)) # no margin
plot(China,col="grey",border="white",lwd=2,xaxs='i', yaxs='i')
dev.off()
The best is obtained with UTM47 (planar projection), however I get
(almost) rid of any white strip only if I add an additionnal 1.04
coefficient (obtained by trial-error)
Hence:
jpeg("./MapChina.jpeg",height=8,width=8*ratio*1.04,res=300,units="in")
par(mar=c(0,0,0,0)) # no margin
plot(China,col="grey",border="white",lwd=2,xaxs='i', yaxs='i')
dev.off()
Trial #2: The other way has been to pick up the parameter values like
that:
par(mar=c(0,0,0,0)) # no margin
plot(China,col="grey",border="white",lwd=2,xaxs='i', yaxs='i')
pt<-par()$pin
ratio<-pt[2]/pt[1]
jpeg("./MapChina.jpeg",height=8,width=8*ratio,res=300,units="in")
par(mar=c(0,0,0,0)) # no margin
plot(China,col="grey",border="white",lwd=2,xaxs='i', yaxs='i') #
dev.off()
Does not work either
Any idea about how to deal with this ? In short how to get the exact
size of a SpatialPolygonDataFrame plot to make the device window
exactly this size?
This feels like a section in ASDAR, ch. 3, and code chunks 24-27 in
https://asdar-book.org/book2ed/vis_mod.R. Could you please try that
first by way of something reproducible?
Best wishes,
Roger
Ups... How can I have missed this chapter of my bible ;-) ? (must admit
I had been on google first). Will re-read it carefully and come back to
the list with a solution or a reproducible example, indeed.
Best,
Patrick
___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
[R-sig-Geo] how to specify the size of device so that it fits a SpatialPolygonsDataFrame plot exactly
Dear listers,
I would like to write jpeg (or png, etc.) maps using the function
graphics:jpeg (png, etc.), but with the device window exactly fitting
the map (= no white strip above, below or on the sides of the map). The
map is derived from a SpatialPolygonsDataFrame (WGS84)
However, even if I set
par(mar=c(0,0,0,0) and pass xaxs='i', yaxs='i' in the plot, there are
still white strips
I tried several tricks but none are fully satisfying.
Trial #1: I computed the ratio of the bounding box and using this ratio
in the function jpeg with the height and width arguments. I did it both
in WGS84 and in UTM47:
ratio<-(max(bbox(ChinaUTM)[1,])-min(bbox(ChinaUTM)[1,]))/(max(bbox(ChinaUTM)[2,])-min(bbox(ChinaUTM)[2,]))
# ratio width/height
then
jpeg("./MapChina.jpeg",height=8,width=8*ratio,res=300,units="in")
par(mar=c(0,0,0,0)) # no margin
plot(China,col="grey",border="white",lwd=2,xaxs='i', yaxs='i')
dev.off()
The best is obtained with UTM47 (planar projection), however I get
(almost) rid of any white strip only if I add an additionnal 1.04
coefficient (obtained by trial-error)
Hence:
jpeg("./MapChina.jpeg",height=8,width=8*ratio*1.04,res=300,units="in")
par(mar=c(0,0,0,0)) # no margin
plot(China,col="grey",border="white",lwd=2,xaxs='i', yaxs='i')
dev.off()
Trial #2: The other way has been to pick up the parameter values like that:
par(mar=c(0,0,0,0)) # no margin
plot(China,col="grey",border="white",lwd=2,xaxs='i', yaxs='i')
pt<-par()$pin
ratio<-pt[2]/pt[1]
jpeg("./MapChina.jpeg",height=8,width=8*ratio,res=300,units="in")
par(mar=c(0,0,0,0)) # no margin
plot(China,col="grey",border="white",lwd=2,xaxs='i', yaxs='i') #
dev.off()
Does not work either
Any idea about how to deal with this ? In short how to get the exact
size of a SpatialPolygonDataFrame plot to make the device window exactly
this size?
Best,
Patrick
___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Re: [R-sig-Geo] Reordering geographical coordinates clockwise to make a polygon
Apologize to answer to myself: the way described below would work only if there are no concave "peninsula" towards north or south inside the polygon. Even thinking about an alternate solution, e.g. the Traveling Salesman Problem (TSP), ie. the shortest route linking all points, one could get wrong since points of a narrowpeninsula could have points closest to the opposite border than from the next point on the border... Suppose we are stuck, and should redraw polygons by hand Le 05/11/2018 à 14:02, Patrick Giraudoux a écrit : > > Dear listers, > > There is an interesting post here: > https://stackoverflow.com/questions/6989100/sort-points-in-clockwise-order > dealing on the issue. However, I would like to know if a function has > been already developped in a R package. > > I am coping with a young colleague's shapefile where borders of > polygons have been drawn as lines quite inconsistently. To change this > SpatialLinesDataFrame into a SpatialPoints object is easy. The idea is > to select the points bordering each polygon (delete the others), > define the point set as a Polygon, then rebuild step by step a > SpatialPolygonsDataFrame with all its (~25) polygons. It would be much > quicker than to redraw one by one the 5160 data points (two times on > borders shared by two polygons). > > The problem is that the points must be reordered clockwise (the way > lines making the borders is all except clockwise) before making them > a polygon. > > Any function already developped for that ? > > Cheers, > > Patrick > > > [[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] sampling with a "cluster" constraints
Le 23/03/2018 à 08:59, Roger Bivand a écrit : Just a thought - spatstat? This has had line segements too for some time, maybe chapter 17 in the spatstat book? Roger Indeed. There are at least two possibilities: simulations using either Matern process or Neyman-Scott Point Process with Variance Gamma cluster kernel... Will see how it could be applicable in my case. Thanks again for the hint, Roger. Patrick ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Re: [R-sig-Geo] sampling with a "cluster" constraints
Le 23/03/2018 à 08:59, Roger Bivand a écrit : Just a thought - spatstat? This has had line segements too for some time, maybe chapter 17 in the spatstat book? Roger Thanks Roger. I will check this. If nothing comes out, I am thinking about developping a quick and dirty home-made function based on negative binomial distribution where a "clustering" (dispersion) parameter can be tuned... Hence, shit stats for hazel grouse and capercaillie shit distribution :-D... Patric ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
[R-sig-Geo] sampling with a "cluster" constraints
Dear Listers, Everybody is probably used with sp:spsample, which permits to produce points locations at random or on a regular grid. Is anybody aware of a package permitting similarly to produce points locations in a field with various degrees of clustering. The idea is to produce points in a field with various degrees of clustering repetedly, and to compare statistics to observed data. E.g. observations in the real world are clustered; one computes a statistics, e.g. the distance of each observation to a feature (e.g. to a road network); then one compute B=999 similarly clustered distributions randomly and the corresponding statistics. This would allow to compute how likely the observed statistics is. Any hint welcome! Best, Patrick [[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] readOGR does not read file names with accent
Le 15/02/2018 à 13:01, Roger Bivand a écrit :
And with a further fix for a downstream encoding issue:
http://spatial.nhh.no/R/rgdal/rgdal_1.2-17.zip
Roger
OK. Works perfect now, even with a worst case scenario "accents + white
space", e.g.
readOGR("./track génét/gélinotte/2016/Mont Noir","général jour 5")
Really great ! Many thanks for your help and so quick response... Awsome !
Best wishes,
Patrick
___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Re: [R-sig-Geo] readOGR does not read file names with accent
PS: surprisingly, the files with accent are well read from QGIS (however
QGIS uses gdal as workhorse...)
Le 15/02/2018 à 08:20, Patrick Giraudoux a écrit :
>> Patrick:
>>
>> Is there also a space in the file path? What is the locale, I guess
>> CP1252?
>
> My locale is fr;Français (France)
>
>
> Le 15/02/2018 à 07:57, Roger Bivand a écrit :
>> ... and could you try sf::st_read(), as it uses enc2utf8()
>> internally? If that works, the same may be used in rgdal.
>>
>
> st_read has the same issue: reads the file with no accent but not with
> accent:
>
> library(sf)
> st_read("./track
> génét/gélinotte/2017/Trémontagne","trace_chaux_du_dombief")
> Reading layer `trace_chaux_du_dombief' from data source
> `U:\Users\pgiraudo2\Documents\Tetra\Master Tony Vialet\track
> génét\gélinotte\2017\Trémontagne' using driver `ESRI Shapefile'
> Simple feature collection with 1 feature and 5 fields
> geometry type: LINESTRING
> dimension: XY
> bbox: xmin: 870249.9 ymin: 2180142 xmax: 871070 ymax: 2180930
> epsg (SRID):NA
> proj4string:NA
>
> but
>
> st_read("./track
> génét/gélinotte/2017/Trémontagne","tracé_chaux_du_dombief")
> Cannot open layer tracé_chaux_du_dombief
> Error in CPL_read_ogr(dsn, layer, as.character(options), quiet, type,
> : Opening layer failed.
[[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] readOGR does not read file names with accent
> Patrick:
>
> Is there also a space in the file path? What is the locale, I guess
> CP1252?
My locale is fr;Français (France)
Le 15/02/2018 à 07:57, Roger Bivand a écrit :
> ... and could you try sf::st_read(), as it uses enc2utf8() internally?
> If that works, the same may be used in rgdal.
>
st_read has the same issue: reads the file with no accent but not with
accent:
library(sf)
st_read("./track génét/gélinotte/2017/Trémontagne","trace_chaux_du_dombief")
Reading layer `trace_chaux_du_dombief' from data source
`U:\Users\pgiraudo2\Documents\Tetra\Master Tony Vialet\track
génét\gélinotte\2017\Trémontagne' using driver `ESRI Shapefile'
Simple feature collection with 1 feature and 5 fields
geometry type: LINESTRING
dimension: XY
bbox: xmin: 870249.9 ymin: 2180142 xmax: 871070 ymax: 2180930
epsg (SRID):NA
proj4string:NA
but
st_read("./track génét/gélinotte/2017/Trémontagne","tracé_chaux_du_dombief")
Cannot open layer tracé_chaux_du_dombief
Error in CPL_read_ogr(dsn, layer, as.character(options), quiet, type, :
Opening layer failed.
[[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] readOGR does not read file names with accent
Dear all,
My plateform is Windows 7. I am meeting trouble when reading a shapefile
with rgdal:readOGR when the file name includes an accent.
For instance,
readOGR("./track
génét/gélinotte/2017/Trémontagne","trace_chaux_du_dombief.shp")is well read
BUT
readOGR("./track
génét/gélinotte/2017/Trémontagne","tracé_chaux_du_dombief.shp")gives
Error in ogrInfo(dsn = dsn, layer = layer, encoding = encoding,
use_iconv = use_iconv, :
Cannot open layer
In both cases accents in the path are well accepted. The difference just
come from accent in the filename.
Any idea about a workaround (except trivial: manually changing accents
to non accent ;-): I have tens of files to read)?
Best,
Patrick
[[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] Wrong reading of data type in readOGR ?
Le 25/11/2016 à 16:18, Roger Bivand a écrit :
On Fri, 25 Nov 2016, Patrick Giraudoux wrote:
Dear Listers,
I meet a problem with readOGR on an ESRI shapefile which was
correctly read in the past (practical training with students). Now
all integer variables are read as "factors" although they should be
read as integer. With the argument stringsAsFactors=FALSE, the
reading gives "characters", but not the expected integers.
Please see:
https://stat.ethz.ch/pipermail/r-sig-geo/2016-October/025038.html
https://stat.ethz.ch/pipermail/r-sig-geo/2016-November/025104.html
This is the result of the antiquated way DBF handle numbers, and
changes made in GDAL2 to accommodate 64-bit integers, which most often
are IDs, not numbers. Maybe try the GDAL1_integer64_policy= argument,
or re-write the shapefiles with the offending integer written as a
double, or stop using shapefiles.
Roger
For info, a command line like this (with GDAL1_integer64=TRUE)
2539<-readOGR(".","Arvicola2539maj11au", GDAL1_integer64=TRUE)
...works perfect and meet the expectations. May be useful to keep in
mind for old shapefiles left on a shelter in the attic...
Before Roger's response, during the training course (may day, may day,
etc.), the other way round had been to import with no arguments and then
use a loop such:
for(i in 18:75) d2539@data[,i]<-as.numeric(as.character(d2539@data[,i]))
but it is (not recommandable) ruffian's way (:-)
___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Re: [R-sig-Geo] Wrong reading of data type in readOGR ?
Le 25/11/2016 à 16:18, Roger Bivand a écrit : On Fri, 25 Nov 2016, Patrick Giraudoux wrote: Dear Listers, I meet a problem with readOGR on an ESRI shapefile which was correctly read in the past (practical training with students). Now all integer variables are read as "factors" although they should be read as integer. With the argument stringsAsFactors=FALSE, the reading gives "characters", but not the expected integers. Please see: https://stat.ethz.ch/pipermail/r-sig-geo/2016-October/025038.html https://stat.ethz.ch/pipermail/r-sig-geo/2016-November/025104.html This is the result of the antiquated way DBF handle numbers, and changes made in GDAL2 to accommodate 64-bit integers, which most often are IDs, not numbers. Maybe try the GDAL1_integer64_policy= argument, or re-write the shapefiles with the offending integer written as a double, or stop using shapefiles. Roger OK. Clear enough. Thanks, Roger. Will modify the training guideline accordingly. Best, Patrick ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
[R-sig-Geo] Wrong reading of data type in readOGR ?
Dear Listers, I meet a problem with readOGR on an ESRI shapefile which was correctly read in the past (practical training with students). Now all integer variables are read as "factors" although they should be read as integer. With the argument stringsAsFactors=FALSE, the reading gives "characters", but not the expected integers. Reading the corresponding *.dbf file with foreign:read.dbf gives a correct reading. This makes me suspect that something goes wrong with the last version of readOGR (maybe earlier too). Those installed one year ago in the computer room are OK. Any suggestion/idea? Best, Patrick ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
[R-sig-Geo] GPX and writeOGR
Dear listers, I am struggling with writeOGR (package rgdal) to make it write a gpx file. Among other trials, I am stuck with this (dbposWGS84 is a SpatialPointsDataFrame with three attribute fields): writeOGR(dbposWGS84,dbposWGS84,waypoints,GPX) Error in writeOGR(dbposWGS84, dbposWGS84, waypoints, GPX) : Creating Name field failed Any idea about what is going wrong ? Patrick [[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] computing polygons from a centroid point distribution
Le 23/12/2011 02:41, Rolf Turner a écrit : You should be aware that the ***centroid*** of a Dirichlet/Voronoi tile is ***NOT*** in general the point determining that tile. I do not believe that your original question, as posed (in terms of centroids) actually has a solution. cheers, Rolf Turner Thanks for this info. Now I realize that my question was wrongly formulated. A tesselation based on spatial points was enough for what I wanted to do. Best, Patrick On 20/12/11 21:55, Patrick Giraudoux wrote: Le 20/12/2011 07:53, Ben Madin a écrit : Patrick, On 20/12/2011, at 2:40 PM, Patrick Giraudoux wrote: Given a spatial point distribution in a two dimensional space, I wonder if there is a function in R that could make a polygon partition of the two dimensional space, with each point as centroid of each polygon ? Any suggestion about package(s) and function(s), if any, welcome, library(deldir) ?deldir might be what you are after? cheers Ben Yes ! exactly what I needed. Missed that it could have been properly called tesselation, rather than to use winding explanations... Many thanks, Patrick ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
[R-sig-Geo] computing polygons from a centroid point distribution
Hi, Given a spatial point distribution in a two dimensional space, I wonder if there is a function in R that could make a polygon partition of the two dimensional space, with each point as centroid of each polygon ? Any suggestion about package(s) and function(s), if any, welcome, Best, Patrick ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
