Re: [R-sig-Geo] Does sp::coordinates() behave correct?
yes, and print(gis.k, digits=7) gives: print(gis.k, digits=7) coordinates name rsoll hsoll 1 (3469125, 5521625) K0001 3469125 5521625 2 (3469375, 5521125) K0002 3469375 5521125 3 (3471875, 5522875) K0016 3471875 5522875 4 (3472500, 5524510) K0020 3472500 5524510 I will update the print methods for Spatial objects in sp to use getOption(digits) [1] 7 as a default for digits, instead of 6. On 10/21/2013 09:41 PM, Rainer Hurling wrote: Hi Sarah, thanks for clearing this up and the very fast answer. Greetings from Göttingen in Germany, Rainer Am 21.10.2013 21:31, schrieb Sarah Goslee: Hi, It's purely a printing issue; the coordinates are unchanged: coordinates(gis.k) x y [1,] 3469125 5521625 [2,] 3469375 5521125 [3,] 3471875 5522875 [4,] 3472500 5524510 A number of print methods in R round things to 'look nice', which can lead to unexpected side-effects, like confused users. Thanks for the short reproducible example; much appreciated. Sarah On Mon, Oct 21, 2013 at 3:27 PM, Rainer Hurling rhur...@gwdg.de wrote: I am using 'coordinates(x) - ~x+y' to convert data.frames into SpatialPointsDataFrames. It seems, that some coordinates will be rounded(?), when they are transformed by coordinates(): library(maptools) # Defining some Datapoints with coordinates gis.k - data.frame(name=c(K0001,K0002,K0016,K0020), rsoll=c(3469125,3469375,3471875,3472500), hsoll=c(5521625,5521125,5522875,5524510)) # Converting them into a SpatialPointsDataFrame gis.k$x - gis.k$rsoll gis.k$y - gis.k$hsoll coordinates(gis.k) - ~x+y # Show contents of new SpatialPointsDataFrame gis.k coordinates name rsoll hsoll 1 (3469120, 5521620) K0001 3469125 5521625 2 (3469380, 5521120) K0002 3469375 5521125 3 (3471880, 5522880) K0016 3471875 5522875 4 (3472500, 5524510) K0020 3472500 5524510 In lines 1 to 3 the coordinates from rsoll and hsoll are rounded, for example 3469125 into 3469120 and 3471875 into 3471880. (In some cases they are rounded up, in others round down?) Only coordinates with last digit =0 are not changed. Is this an expected behaviour and if this is right, why? If not, what would be the correct solution to convert these coordinates? Or do I missunderstand something here. Any help is appreciated. Thanks in advance, Rainer Hurling ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo -- Edzer Pebesma Institute for Geoinformatics (ifgi), University of Münster Heisenbergstraße 2, 48149 Münster, Germany. Phone: +49 251 83 33081 http://ifgi.uni-muenster.de GPG key ID 0xAD3A77F1 ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Re: [R-sig-Geo] Does sp::coordinates() behave correct?
Am 22.10.2013 08:58 (UTC+1) schrieb Edzer Pebesma: yes, and print(gis.k, digits=7) After Sarah's answer I remembered, that this is only a printing issue. Thanks for your further example to print exact coordinates. gives: print(gis.k, digits=7) coordinates name rsoll hsoll 1 (3469125, 5521625) K0001 3469125 5521625 2 (3469375, 5521125) K0002 3469375 5521125 3 (3471875, 5522875) K0016 3471875 5522875 4 (3472500, 5524510) K0020 3472500 5524510 I will update the print methods for Spatial objects in sp to use getOption(digits) [1] 7 as a default for digits, instead of 6. That would be very nice! Until now we always have to remember, when print spatial objects directly [= print(gis.k)], that there could be some 'pretty printing at work' ;) Just a small thought: Do 7 digits will fit all usual cases of coordinate types? Or would it be better to calculate the longest value (number of digits) before printing coordinates? But I fear, this would slow down printing to much ... Thanks for your very good and important sp package. We almost daily use it heavily, Rainer On 10/21/2013 09:41 PM, Rainer Hurling wrote: Hi Sarah, thanks for clearing this up and the very fast answer. Greetings from Göttingen in Germany, Rainer Am 21.10.2013 21:31, schrieb Sarah Goslee: Hi, It's purely a printing issue; the coordinates are unchanged: coordinates(gis.k) x y [1,] 3469125 5521625 [2,] 3469375 5521125 [3,] 3471875 5522875 [4,] 3472500 5524510 A number of print methods in R round things to 'look nice', which can lead to unexpected side-effects, like confused users. Thanks for the short reproducible example; much appreciated. Sarah On Mon, Oct 21, 2013 at 3:27 PM, Rainer Hurling rhur...@gwdg.de wrote: I am using 'coordinates(x) - ~x+y' to convert data.frames into SpatialPointsDataFrames. It seems, that some coordinates will be rounded(?), when they are transformed by coordinates(): library(maptools) # Defining some Datapoints with coordinates gis.k - data.frame(name=c(K0001,K0002,K0016,K0020), rsoll=c(3469125,3469375,3471875,3472500), hsoll=c(5521625,5521125,5522875,5524510)) # Converting them into a SpatialPointsDataFrame gis.k$x - gis.k$rsoll gis.k$y - gis.k$hsoll coordinates(gis.k) - ~x+y # Show contents of new SpatialPointsDataFrame gis.k coordinates name rsoll hsoll 1 (3469120, 5521620) K0001 3469125 5521625 2 (3469380, 5521120) K0002 3469375 5521125 3 (3471880, 5522880) K0016 3471875 5522875 4 (3472500, 5524510) K0020 3472500 5524510 In lines 1 to 3 the coordinates from rsoll and hsoll are rounded, for example 3469125 into 3469120 and 3471875 into 3471880. (In some cases they are rounded up, in others round down?) Only coordinates with last digit =0 are not changed. Is this an expected behaviour and if this is right, why? If not, what would be the correct solution to convert these coordinates? Or do I missunderstand something here. Any help is appreciated. Thanks in advance, Rainer Hurling ___ 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] R not responding
R is not running. Whenever I open it, it run for few seconds and the close with an error message not responding. Any clue? JOSEPH BECHARA Wildfire Management Program Coordinator Ashrafieh 1020 Building, 8th floor, Mathaf, Beirut, Lebanon Tel.: +961 (1) 426630-1-2 Fax: +961 (1) 426631 Mail: mailto:jbejj...@lri-lb.org jbech...@lri-lb.org http://www.lri-lb.org/ www.lri-lb.org Description: Description: LRI-logo-Email image001.jpg___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Re: [R-sig-Geo] Problems with Kcross.inhom
Hi Rolf and Julia Many thanks for your help, I appreciate that. I am sorry for the inconvenient, I am new in these things. Just to clarify, my window is complex because is created from a shapefile that delimit my study area. This study area (called W in the analysis) have the spatial locations of my data (ficus and tienda). With the purpose of reproduce the analysis and try to find the problem, in the attachment documents you can find the shapefile of my study area, a txt document of my data and my R script (Kcrossinhom(DV)). Again, I really appreciate your help. Thank you. Cheers 2013/10/21 Julia Chacon Labella juliacha...@gmail.com Yes, I tried to reproduced your example, and I didn´t have any problem. Have you check how are your lambdas?? Why are you using at points instead of the default by pixel?? It seems that could be the lambda values what is wrong. Try to visualized them, and try with the pixel image. Other option is to built a new window for your pattern. How did you built it? 2013/10/22 Rolf Turner r.tur...@auckland.ac.nz Again, your problem is not reproducible. We do not have the objects north, west, W and tipo which are necessary to duplicate your steps. I tried to reproduce your problem with an artificial example: W - owin(c(0,3350),c(0,6150)) set.seed(42) Z - runifpoint(201,win=W) m - sample(rep(c(ficus,tienda)**,c(131,70)),201) marks(Z) - factor(m) ff - with(split(Z),bw.diggle(ficus)**) tt - with(split(Z),bw.diggle(**tienda)) lambdaf - with(split(Z),density(ficus,**ff,at=points)) lambdat - with(split(Z),density(tienda,**tt,at=points)) K - Kcross.inhom(Z,ficus,**tienda,lambdaf,lambdat) No problema. It is possible that the error has something to do with the rather intricate (1716 vertices) boundary of your observation window. However since I don't have that window I can't tell. cheers, Rolf Turner On 10/22/13 10:16, david.villalobos wrote: Sure Julia, First: I have the following object called Z Z - ppp(north, west,window=W,marks=tipo) summary(Z) Marked planar point pattern: 201 points Average intensity 4.46e-05 points per square unit Coordinates are integers i.e. rounded to the nearest 1 unit Multitype: frequency proportion intensity ficus131 0.652 2.90e-05 tienda70 0.348 1.55e-05 Window: polygonal boundary single connected closed polygon with 1716 vertices enclosing rectangle: [484546.8, 487897.4] x [1147521.3, 1153682.9] units Window area = 4509680 square units Second: I calculated the bandwidth sigma for the kernel estimator of point process intensity with a Cross Validated Bandwidth Selection for Kernel Density (bw.diggle) attach(split(Z)) f-bw.diggle(ficus) t-bw.diggle(tienda) Third: I calculated with the Kernel Smoothed Intensity of Point Pattern (density.ppp) the values of the the estimated intensity of the sub-process of points of type i and j: lambdaf-density.ppp(ficus,f,**at=points) lambdat-density.ppp(tienda,t,**at=points) and Finally: I ran the script for Kcross.inhom for the method (1): estimate intensities by nonparametric smoothing, but I had the error. K - Kcross.inhom(Z, ficus, tienda, lambdaf, lambdat) Error in Kwtsum(dclose, bI, weight, b, 1/lambdaI, breaks) : Weights in K-function were infinite or NA I tryed the method (2): leave-one-out, but I had the same problems Any help is appreciated. A lot of thanks. -- View this message in context: http://r-sig-geo.2731867.n2.** nabble.com/Problems-with-**Kcross-inhom-**tp7584914p7584920.htmlhttp://r-sig-geo.2731867.n2.nabble.com/Problems-with-Kcross-inhom-tp7584914p7584920.html Sent from the R-sig-geo mailing list archive at Nabble.com. __**_ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/**listinfo/r-sig-geohttps://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-geohttps://stat.ethz.ch/mailman/listinfo/r-sig-geo -- Julia -- Saludos David Villalobos Chaves Maestría Académica en Biología Universidad de Costa Rica tipoX Y tienda 486080 1149670 tienda 486142 1149690 tienda 486111 1150020 tienda 486135 1150010 tienda 486186 1150030 tienda 486126 1150040 tienda 486080 1150010 tienda 486051 1150020 tienda 486038 1149990 tienda 486036 1149990 tienda 486036 1149990 tienda 486049 115 tienda 485907 1149910 tienda 485813 1149900 tienda 485788 1149860 tienda 485808 1149870 tienda 485888 1149900 tienda 486016 1149980 tienda 486113 1150200 tienda 486115 1150200 tienda 486109 1150200 tienda 486093 1150170 tienda 486082 1150140 tienda 486076 1150140 tienda 486058 1150110 tienda 485971 1150120 tienda 485971 1150120 tienda 485971 1150120 tienda 486005 1150070 tienda
[R-sig-Geo] spplot class intervals
I am not able to force spplot to do class interval at specified points. I set them very similar to what gives the spplot command automatically for not to have some mistake in values. I used following command (I simplified it because of this question): spplot(hron_prec, c(AVETREN, AVETEST), at = c(1.9, 2.35, 2.8, 3.3, 3.7, 4.2)) hron_prec is point shapefile and AVETREN and AVETEST are two real valued attributes of it with values from 1.9 to 4.2 it gives me breaks in 1.9, 2.36, 2.82, 3.28, 3.74, 4.2 and warning message was displayed: In spmap.to.lev(sdf, zcol = zcol, names.attr = names.attr) : spmap.to.lev ignores spatial dimensions beyond the first 2 I want to have class intervals more rounded and I would like to set them where I want - please what could be wrong? Milan Milan Cisty, PhD. Associate Professor in Water Resources Management Department of Land and Water Resources Management Faculty of Civil Engineering Slovak University of Technology Bratislava Radlinskeho 11, 813 68 Bratislava, Slovak Republic e-mail: mailto:milan.ci...@stuba.sk milan.ci...@stuba.sk tel: 00421 2 59274628 [[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] spplot class intervals
Milan, Try using the function 'cuts' instead of at=c(). Jesse library(sp) data(meuse) coordinates(meuse)=~x+y spplot(meuse, cadmium, do.log = TRUE, key.space=list(x=0.2,y=0.9,corner=c(0,1)), cuts=c(1, 2, 3, 4, 10, 20), # My custom cuts scales=list(draw=T)) - Jesse D Berman, PhD Yale University School of Forestry and Environmental Studies Post-Doc Fellow -- View this message in context: http://r-sig-geo.2731867.n2.nabble.com/spplot-class-intervals-tp7584934p7584935.html Sent from the R-sig-geo mailing list archive at Nabble.com. ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Re: [R-sig-Geo] Problems with Kcross.inhom
It seems that you get an estimate of lambda= 0.0 for your ficus point #2. Kinhom can only be estimated when lambda 0 in all points. I would use either another sigma for bandwith estimation or set the argument leaveoneout=FALSE. Cheers, Marcelino El 22/10/2013 14:37, David Villalobos escribió: Hi Rolf and Julia Many thanks for your help, I appreciate that. I am sorry for the inconvenient, I am new in these things. Just to clarify, my window is complex because is created from a shapefile that delimit my study area. This study area (called W in the analysis) have the spatial locations of my data (ficus and tienda). With the purpose of reproduce the analysis and try to find the problem, in the attachment documents you can find the shapefile of my study area, a txt document of my data and my R script (Kcrossinhom(DV)). Again, I really appreciate your help. Thank you. Cheers 2013/10/21 Julia Chacon Labella juliacha...@gmail.com mailto:juliacha...@gmail.com Yes, I tried to reproduced your example, and I didn´t have any problem. Have you check how are your lambdas?? Why are you using at points instead of the default by pixel?? It seems that could be the lambda values what is wrong. Try to visualized them, and try with the pixel image. Other option is to built a new window for your pattern. How did you built it? 2013/10/22 Rolf Turner r.tur...@auckland.ac.nz mailto:r.tur...@auckland.ac.nz Again, your problem is not reproducible. We do not have the objects north, west, W and tipo which are necessary to duplicate your steps. I tried to reproduce your problem with an artificial example: W - owin(c(0,3350),c(0,6150)) set.seed(42) Z - runifpoint(201,win=W) m - sample(rep(c(ficus,tienda)__,c(131,70)),201) marks(Z) - factor(m) ff - with(split(Z),bw.diggle(ficus)__) tt - with(split(Z),bw.diggle(__tienda)) lambdaf - with(split(Z),density(ficus,__ff,at=points)) lambdat - with(split(Z),density(tienda,__tt,at=points)) K - Kcross.inhom(Z,ficus,__tienda,lambdaf,lambdat) No problema. It is possible that the error has something to do with the rather intricate (1716 vertices) boundary of your observation window. However since I don't have that window I can't tell. cheers, Rolf Turner On 10/22/13 10:16, david.villalobos wrote: Sure Julia, First: I have the following object called Z Z - ppp(north, west,window=W,marks=tipo) summary(Z) Marked planar point pattern: 201 points Average intensity 4.46e-05 points per square unit Coordinates are integers i.e. rounded to the nearest 1 unit Multitype: frequency proportion intensity ficus131 0.652 2.90e-05 tienda70 0.348 1.55e-05 Window: polygonal boundary single connected closed polygon with 1716 vertices enclosing rectangle: [484546.8, 487897.4] x [1147521.3, 1153682.9] units Window area = 4509680 square units Second: I calculated the bandwidth sigma for the kernel estimator of point process intensity with a Cross Validated Bandwidth Selection for Kernel Density (bw.diggle) attach(split(Z)) f-bw.diggle(ficus) t-bw.diggle(tienda) Third: I calculated with the Kernel Smoothed Intensity of Point Pattern (density.ppp) the values of the the estimated intensity of the sub-process of points of type i and j: lambdaf-density.ppp(ficus,f,__at=points) lambdat-density.ppp(tienda,t,__at=points) and Finally: I ran the script for Kcross.inhom for the method (1): estimate intensities by nonparametric smoothing, but I had the error. K - Kcross.inhom(Z, ficus, tienda, lambdaf, lambdat) Error in Kwtsum(dclose, bI, weight, b, 1/lambdaI, breaks) : Weights in K-function were infinite or NA I tryed the method (2): leave-one-out, but I had the same problems Any help is appreciated. A lot of thanks. -- View this message in context: http://r-sig-geo.2731867.n2.__nabble.com/Problems-with-__Kcross-inhom-__tp7584914p7584920.html http://r-sig-geo.2731867.n2.nabble.com/Problems-with-Kcross-inhom-tp7584914p7584920.html Sent from the R-sig-geo mailing list archive at Nabble.com. _ R-sig-Geo mailing list
[R-sig-Geo] White spaces in .dbf file id names causing issues with reading in shapefiles
Hi, I am trying to create some chloropleth maps of disease incidence data for the province of East Java, Indonesia. I can see there are a number of different packages with which I might do this (e.g. the plotmap function in SpatialEpi, or maptools) but I'm having difficulty importing the shapefiles. My problem is that all the shapefiles I can find for Indonesia very frustratingly put white spaces in the names of the districts or provinces. I carefully removed the spaces in the district and province names in my datafile, which means that even if the shapefile could be read into R, the id names would not match - a moot point at present because I can't read in the shapefiles either. I am using R 3.0.2 64 bit with the following packages loaded: library(SpatialEpi) library(ggplot2) library(ggmap) Here is the type of error I am getting: Indmap - readShapePoly(fn=IDN_adm/IDN_adm2.shp, IDvar=NAME_2) Error in `row.names-.data.frame`(`*tmp*`, value = value) : duplicate 'row.names' are not allowed In addition: Warning message: non-unique values when setting 'row.names': Banjar, Kepulauan Riau, Lampung Barat *Note, at district level there are both districts and cities - some of the cities have the same name as a (separate) district but they are prefaced by the word Kota (meaning city/town). The above error was created because there are cities and districts with the same names and there was a white space between Kota and the city name in the shapefile. I'm fairly certain that some years ago I was able to remove the spaces in MS excel and save the edited file as a .dbf without problems but now this isn't working and I see from googling this issue that MS excel 2010 does not have an option to edit and save .dbf files (they get corrupted if you try). I then tried opening the .dbf file in MS excel, removing the white spaces, saving as a .csv and re-importing into R where I was hoping write.dbf would work, but that gave me the following error: Dmap - read.table(file=Dmap.csv, header=TRUE, sep=,, na.strings=NA) str(Dmap) 'data.frame': 394 obs. of 18 variables: $ ID_0 : int 103 103 103 103 103 103 103 103 103 103 ... $ ISO : Factor w/ 1 level IDN: 1 1 1 1 1 1 1 1 1 1 ... $ NAME_0: Factor w/ 1 level Indonesia: 1 1 1 1 1 1 1 1 1 1 ... $ ID_1 : int 1264 1264 1264 1264 1264 1264 1264 1264 1264 1264 ... $ NAME_1: Factor w/ 33 levels Aceh,Bali,..: 11 11 11 11 11 11 11 11 11 11 ... $ ID_2 : int 15418 15419 15420 15421 15422 15423 15424 15425 15426 15427 ... $ NAME_2: Factor w/ 391 levels AcehBarat,AcehBaratDaya,..: 46 66 75 76 87 93 109 131 137 143 ... $ VARNAME_2 : Factor w/ 83 levels BanyuAsin,BaritoUtara,..: NA NA NA NA NA NA 11 NA NA NA ... $ NL_NAME_2 : logi NA NA NA NA NA NA ... $ HASC_2: Factor w/ 386 levels ID.AC.AB,ID.AC.AD http://id.ac.ad/,..: 156 152 154 155 158 159 160 161 162 163 ... $ CC_2 : logi NA NA NA NA NA NA ... $ TYPE_2: Factor w/ 3 levels Kabupaten,Kotamadya,..: 1 1 1 1 1 1 1 1 1 1 ... $ ENGTYPE_2 : Factor w/ 3 levels Municipality,..: 2 2 2 2 2 2 2 2 2 2 ... $ VALIDFR_2 : Factor w/ 1 level Unknown: 1 1 1 1 1 1 1 1 1 1 ... $ VALIDTO_2 : Factor w/ 2 levels Present,Unknown: 1 1 1 1 1 1 1 1 1 1 ... $ REMARKS_2 : logi NA NA NA NA NA NA ... $ Shape_Leng: num 1.18 2.09 2.24 2.77 4.6 ... $ Shape_Area: num 0.0609 0.159 0.0896 0.1426 0.1924 ... write.dbf(Dmap, out.name=dmap.dbf, arcgis=FALSE) Error in c(logical = L, integer = N, numeric = F, character = C, : invalid subscript type 'list' Is there an easier way that I could solve this (without editing the .dbf files)? Alternately if I do have to edit the .dbf files how can I use the write.dbf function (I don't think I can use convert.to.shapefile because I can't import the .shp and .shx files into R until I've fixed the .dbf file?) Thanks in advance for any suggestions, Best regards, Amy -- *Amy Mikhail* *EUPHEM fellow (European Program for Public Health Microbiology)*http://www.ecdc.europa.eu/en/activities/training_activities/EUPHEM/Pages/index.aspx Microbiology Reference Services *Public Health England http://www.gov.uk/phe* 61 Colindale Avenue London NW9 5EQ UK Phone: +44 (0)208 32 *77295* Mobile: +44 (0)781 4176107 Wmail: *amy.mikh...@phe.gov.uk* Gmail: amy.mikh...@gmail.com [[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] White spaces in .dbf file id names causing issues with reading in shapefiles
Dear Tom and Roger, Many thanks, just tried readOGR and the import was successful. Best, Amy On 22 October 2013 20:05, Tom Philippi tephili...@gmail.com wrote: Amy-- Try using readOGR from the rgdal package. I may be wrong (I'm presently locked out of my workstation by IT support so I can't verify), but I'm pretty sure that spaces in rownames isn't an issue. I hope that this helps. Tom On Tue, Oct 22, 2013 at 11:56 AM, Amy Mikhail amy.mikh...@gmail.comwrote: Hi, I am trying to create some chloropleth maps of disease incidence data for the province of East Java, Indonesia. I can see there are a number of different packages with which I might do this (e.g. the plotmap function in SpatialEpi, or maptools) but I'm having difficulty importing the shapefiles. My problem is that all the shapefiles I can find for Indonesia very frustratingly put white spaces in the names of the districts or provinces. I carefully removed the spaces in the district and province names in my datafile, which means that even if the shapefile could be read into R, the id names would not match - a moot point at present because I can't read in the shapefiles either. I am using R 3.0.2 64 bit with the following packages loaded: library(SpatialEpi) library(ggplot2) library(ggmap) Here is the type of error I am getting: Indmap - readShapePoly(fn=IDN_adm/IDN_adm2.shp, IDvar=NAME_2) Error in `row.names-.data.frame`(`*tmp*`, value = value) : duplicate 'row.names' are not allowed In addition: Warning message: non-unique values when setting 'row.names': Banjar, Kepulauan Riau, Lampung Barat *Note, at district level there are both districts and cities - some of the cities have the same name as a (separate) district but they are prefaced by the word Kota (meaning city/town). The above error was created because there are cities and districts with the same names and there was a white space between Kota and the city name in the shapefile. I'm fairly certain that some years ago I was able to remove the spaces in MS excel and save the edited file as a .dbf without problems but now this isn't working and I see from googling this issue that MS excel 2010 does not have an option to edit and save .dbf files (they get corrupted if you try). I then tried opening the .dbf file in MS excel, removing the white spaces, saving as a .csv and re-importing into R where I was hoping write.dbf would work, but that gave me the following error: Dmap - read.table(file=Dmap.csv, header=TRUE, sep=,, na.strings=NA) str(Dmap) 'data.frame': 394 obs. of 18 variables: $ ID_0 : int 103 103 103 103 103 103 103 103 103 103 ... $ ISO : Factor w/ 1 level IDN: 1 1 1 1 1 1 1 1 1 1 ... $ NAME_0: Factor w/ 1 level Indonesia: 1 1 1 1 1 1 1 1 1 1 ... $ ID_1 : int 1264 1264 1264 1264 1264 1264 1264 1264 1264 1264 ... $ NAME_1: Factor w/ 33 levels Aceh,Bali,..: 11 11 11 11 11 11 11 11 11 11 ... $ ID_2 : int 15418 15419 15420 15421 15422 15423 15424 15425 15426 15427 ... $ NAME_2: Factor w/ 391 levels AcehBarat,AcehBaratDaya,..: 46 66 75 76 87 93 109 131 137 143 ... $ VARNAME_2 : Factor w/ 83 levels BanyuAsin,BaritoUtara,..: NA NA NA NA NA NA 11 NA NA NA ... $ NL_NAME_2 : logi NA NA NA NA NA NA ... $ HASC_2: Factor w/ 386 levels ID.AC.AB,ID.AC.AD http://id.ac.ad/,..: 156 152 154 155 158 159 160 161 162 163 ... $ CC_2 : logi NA NA NA NA NA NA ... $ TYPE_2: Factor w/ 3 levels Kabupaten,Kotamadya,..: 1 1 1 1 1 1 1 1 1 1 ... $ ENGTYPE_2 : Factor w/ 3 levels Municipality,..: 2 2 2 2 2 2 2 2 2 2 ... $ VALIDFR_2 : Factor w/ 1 level Unknown: 1 1 1 1 1 1 1 1 1 1 ... $ VALIDTO_2 : Factor w/ 2 levels Present,Unknown: 1 1 1 1 1 1 1 1 1 1 ... $ REMARKS_2 : logi NA NA NA NA NA NA ... $ Shape_Leng: num 1.18 2.09 2.24 2.77 4.6 ... $ Shape_Area: num 0.0609 0.159 0.0896 0.1426 0.1924 ... write.dbf(Dmap, out.name=dmap.dbf, arcgis=FALSE) Error in c(logical = L, integer = N, numeric = F, character = C, : invalid subscript type 'list' Is there an easier way that I could solve this (without editing the .dbf files)? Alternately if I do have to edit the .dbf files how can I use the write.dbf function (I don't think I can use convert.to.shapefile because I can't import the .shp and .shx files into R until I've fixed the .dbf file?) Thanks in advance for any suggestions, Best regards, Amy -- *Amy Mikhail* *EUPHEM fellow (European Program for Public Health Microbiology)* http://www.ecdc.europa.eu/en/activities/training_activities/EUPHEM/Pages/index.aspx Microbiology Reference Services *Public Health England http://www.gov.uk/phe* 61 Colindale Avenue London NW9 5EQ UK Phone: +44 (0)208 32 *77295* Mobile: +44 (0)781 4176107 Wmail: *amy.mikh...@phe.gov.uk* Gmail: amy.mikh...@gmail.com [[alternative HTML version deleted]] ___ R-sig-Geo mailing
[R-sig-Geo] Load a map png in ggplot2 (workaround for missing world map support in ggmap)
Hello everybody, my professor and I are assembling a handout on the best options for creating maps in R. As it looked very up-to-date, I've been considering including a short tutorial on the ggmap package. Now, as some of you might have noticed, the ggmap package does not fully support world maps - you can save empty maps as a png, but you can't use them directly in a plot, as one would usually do, e.g. with ggmap(get_map(...)). Unfortunately, being able to plot data on maps of the whole world is one of our main priorities. That's why I'm trying to find out how I could load pngs (or similar image files) into ggplot and use them as a map to plot on. I know that it's possible to include background images in ggplot (see e.g. this question on stackoverflow: http://stackoverflow.com/questions/16409935/plot-data-over-background-image-with-ggplot). However, this would only cover importing the image itself, and not adjusting the x/y axes etc., as it is necessary so I can plot my spatial data onto the map properly. Has anyone encountered the same problem, and perhaps found a solution? I'm looking forward to your ideas. Please let me know if I've been unclear. Cheers, Markus ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
