Skip to content

Heatmap

3 messages · Carlos Javier Rincon Rodriguez, David Winsemius, Jim Lemon

#
Hi. Good morning.

I am trying to load a shapefile to do a heatmap of Colombia. I using all
this package:

library(ctv)

library(spatial)

library(ggplot2)

library(sp)

library(rgdal)

library(rgeos)

library(maptools)

library(ggmap)


and a using this two commands to load the file:


depto<-readShapePoly("depto.shp")

depto <- readOGR(dsn = ".", "depto")


but the result is:


     depto<-readShapePoly("depto.shp")

     Error in getinfo.shape(filen) : Error opening SHP file


     depto <- readOGR(dsn = ".", "depto")

     Error in ogrInfo(dsn = dsn, layer = layer, encoding = encoding,
use_iconv = use_iconv,  : Cannot open file


Also I am working in a MAC computer and when I open R, I have this warning
message:


    WARNING: You're using a non-UTF8 locale, therefore only ASCII
characters will work.

    Please read R for Mac OS X FAQ (see Help) section 9 and adjust your
system preferences accordingly.


I looking the R for Mac document but there is not section 9.!!!


Thanks for any help.



Carlos.



2015-05-05 18:01 GMT-05:00 Carlos Javier Rincon Rodriguez <
cjrinconr at unal.edu.co>:

  
  
#
On May 22, 2015, at 10:32 AM, Carlos Javier Rincon Rodriguez wrote:

            
Was going to suggest following up on the SIG-geo mailing list since the shape-shifters don't all hang out in these parts, but I see that you crossposted. (That's not considered good form on R mailing lists.)
This FAQ:

http://cran.r-project.org/bin/macosx/RMacOSX-FAQ.html

(I see 10 numbered major headings, although admittedly the 9th is the acknowledgements section. I'm wondering if it were the 7th section that was meant, since it has information about setting the locale.)
#
Hi Carlos,
The error from:

readShapePoly("depto.shp")

may well be that the function cannot find the file. Assuming that
there is a file "depto.shp", is it in the working directory of R when
you issue this command? Find out by:

getwd()

I suppose that macintosh computers try to hide the actual location of
files, so you may have to hunt around to find where the file resides
and whether you will have to add a path to your call. The second error
probably stems from the first, as if the file hasn't been read, the
information in it cannot be extracted.

Jim
On Sat, May 23, 2015 at 7:07 AM, David Winsemius <dwinsemius at comcast.net> wrote: