Feature request: map from data.frame

[AB-Kent]

I often have spatial point data in data.frames read from CSV files. Can mapView() be extended to support a data frame with columns lat/latitude and lon/long/longitude or direct specification of lat/lon similar to e.g. leaflet::addCircles?

[mdsumner]

I am not sure what the answer to that is, but are you familiar with creating a SpatialPointsDataFrame?

You can do

d <- read.csv("myfile.csv", stringsAsFactors = FALSE) ## pseudocode
## names can be anything, but let's assume "lon" and "lat"
library(sp)
coordinates(d) <- c("lon", "lat")
proj4string(d) <- CRS("+init=epsg:4326")

library(mapview)
mapview(d)

Note that the coordinates<- step removes those columns from the DataFrame part, and treats them in an internal matrix, used for plotting etc. You can get those with coordinates(d).

The names I used are just for illustration, set the RHS vector c("lon", "lat") to be whatever the two names are that you have, and be sure they are longitude, then latitude in that vector (it doesn't matter where they are in the data frame).

There are other ways to construct the object i.e. with SpatialPointsDataFrame() but the pattern I've used there is more concise. You can get back to a standard data frame with as.data.frame(d).

[AB-Kent]

I didn't know it was quite that easy to create a SPDF, no. OTOH the value of mapview is "easy and quick visualization" so it would be nice to avoid the extra steps (and remembering how to do it).

[mdsumner]

I think there's value in that, it would be nice to have a pipeline like this where a special select function elevates the fields in a certain way, rather than removing them. This could also be used for setting units and so on for "common scenarios", different assumptions applied to a different member of a "select_special" family.

d %>% spatial_select(lon, lat) %>% mapview() 

## we could group by for multipoints for example, but it leaves our other columns with nowhere to be
d %>% spatial_select(lon, lat) %>% group_by(fac) %>% mapview() 

and there are a bunch of things to worry about. One thing I really want is pipelines for structure spatial data that come from tables like this, it's rare for polygons but it's really common for lines. So the same model would work:

d %>% spatial_select(lon, lat, datetime) %>% group_by(name, voyagenumber) %>% mapview() 

I think this is currently missing in the tidyverse, with ggvis having made a start but without inclusion of the wider field of "spatial" in R and I'm working on ways to experiment with the ideas. If we can get this kind of thing to work it has a lot more applicability than just mapview, and it might not even be much work for mapview to support.

(and I mean "spatial" as in anything, really anything multi-dimensional and/or hierarchical, time is "spatial" afaic)

(Thanks for the trigger to think this out aloud).

[tim-salabim]

Well, the objective of mapview is to "very quickly and conveniently create interactive visualisations of spatial data." Where "spatial data" is actually one key element and refers to spatial class representations popular in R (raster, sp and now sf). The assumption here is that mapview is a tool that is used during spatial data analysis workflow, hence data is available in some spatial format. The reasons for not having a sort of guessTheLatLonColumn function in mapview are:

1. as Mike pointed out it is pretty straight forward to convert conventional data frames to spatial objects (even easier now with sf) and
2. for the amount of data that leaflet can render with acceptable performance there is hardly any computational overhead to do the above conversion.

Having said that, I think plain data frame representations will need to be supported by mapview at some stage, as we are getting closer to a proper solution for rendering many hundreds of thousands to millions of points and then the computational overhead of converting to some spatial object first will be significant.

So, in a nutshell, yes this is on our nice-to-have list, but I am not sure when this can be implemented.

[tim-salabim]

@mdsumner wouldn't that be for sf?

d %>% st_as_sf(coords = c("lon", "lat")) %>% mapview()

[mdsumner]

Yes, that's a good idea - and already works (nice!), but I'm also looking outside of sf. I want this to work for a much wider range of models.

[gisma]

I must admit that your contributions and ideas sound very tempting. It would be more than a nice to have feature. However I think it is far away from being a good or reliable idea.

The discussed examples represents the most simple spatial data concept. 0-dimensional information with no projection. All of you know the cosmos and complexity of more than 0-d data out there. Only a minority of R-users is aware of the spatiotemporal dimensionality of data and the reliable spatial transforming and projection of this data.

Again It sounds charming to have the one-click-deal-with-data-button in mapview but in my opinion we should keep a very clear separation line between the different goals we are addressing. Mapview is intended for an easy interactive visualization (maybe we could call it also very straightforward interactive mapping) of spatial data. So far mapview is not designed for things like analyzing, importing, exporting, transforming ... spatial data. If we need general magic tools for stuff like importing-spatial-data-to-R we should think about the simplification and fusion of existing packages that are already dealing with this. There are tons of hybrid un-focused packages developed for special settings and goals but not optimized for the addressed goals. I am not sure if we also should drift into this direction in future mapview development. I think we have to accept and integrate that spatiotemporal data is NOT easy to understand or use...

[tim-salabim]

With the advent of package sf I consider this no longer an issue.

[brry]

With sf including CRS, this is:

df %>% st_as_sf(coords=c("lon","lat"), crs="+proj=longlat +datum=WGS84") %>% mapview()