[R-sig-Geo] projection of ggmap:get_map() output

[Agustin Lobo]

But the fact that the output of get_map() includes the bounding box in
geographic
coordinates (epsg:4326) does not imply that the matrix is on the same
projection.
This should be specified.
I can provide you a utm raster along with bounding box coordinates in
geographic coordinates (epsg:4326).
Actually, according to the code I just showed, it is not clear at all
that the matrix provided
in the ggmap "raster" object is in epsg:4326.

Agus



On Thu, Apr 24, 2014 at 10:21 AM, Edzer Pebesma
<edzer.pebesma at uni-muenster.de> wrote:
> EPSG:4326, or WGS84, is only one way to refer to places on the earth by
> longitudes and latitudes; it seems that google maps come in a Mercator
> projection, EPSG:3857, read e.g. this:
>
> http://docs.openlayers.org/library/spherical_mercator.html
>
> or
>
> https://developers.google.com/maps/documentation/javascript/maptypes#MapCoordinates
>
> Iliffe and Lott: Datums and Map Projections: For Remote Sensing, GIS and
> Surveying
>
> provide an excellent explanation on what goes on here, including what
> google maps does.
>
> On 04/24/2014 09:56 AM, Agustin Lobo wrote:
>> (follow up of previous message, I pressed enter as if I were in the R
>> session and sent the message...)
>>
>> On Wed, Apr 23, 2014 at 4:37 PM, Barry Rowlingson
>> <b.rowlingson at lancaster.ac.uk> wrote:
>>>  - I imagine the web services expect EPSG:4326.
>>
>> What they expect, yes. But what about what we retrieve? The bbox
>> coordinates might be in geographic coordinates (epsg:4326) but
>> the actual projection of the matrix could be any other. Actually, I
>> think that no geographic object without CRS information should be
>> admitted in R.
>>
>> In order to investigate this further, I've done the following:
>>
>> mibb <- matrix(c(-69.88634, -48.78450, -34.05533, -18.63424),byrow=TRUE,nrow=2)
>> delme <- get_map(location = mibb, maptype = "hybrid", source=
>> "google", crop = FALSE, zoom = 5)
>>
>> mgmap <- as.matrix(gmap)
>> vgmap <- as.vector(mgmap)
>> vgmaprgb <- col2rgb(vgmap)
>> gmapr <- matrix(vgmaprgb[1,],ncol=ncol(
>> mgmap),nrow=nrow(mgmap))
>> gmapg <- matrix(vgmaprgb[2,],ncol=ncol(mgmap),nrow=nrow(mgmap))
>> gmapb <- matrix(vgmaprgb[3,],ncol=ncol(mgmap),nrow=nrow(mgmap))
>> rgmaprgb <- brick(raster(gmapr),raster(gmapg),raster(gmapb))
>> projection(rgmaprgb) <- CRS("+init=epsg:4326")
>> extent(rgmaprgb) <- unlist(attr(gmap,which="bb"))[c(2,4,1,3)]
>> rgmaprgb
>> plotRGB(rgmaprgb)
>>
>> This looks good, but when I save as GTiff
>> writeRaster(rgmaprgb,file="rgmaprgb",format="GTiff",overwrite=TRUE,datatype="INT1U")
>>
>> and check with QGIS, there is a very significant shift versus the GM
>> layer that is downladed by plugin OpenLayers.
>>
>> Thus I worry that my overlay using rasterVis:levelplot and ggmap:
>> layer could actually be wrong as well.
>>
>> I'm going to test on a more local area and let you know.
>>
>> Agus
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> R-sig-Geo at 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 0xAC227795
>
>
> _______________________________________________
> R-sig-Geo mailing list
> R-sig-Geo at r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>