ropensci / unconf14

Repo to brainstorm ideas (unconference style) for the rOpenSci hackathon.
28 stars 3 forks source link

rMaps #1

Open karthik opened 10 years ago

karthik commented 10 years ago

One really interesting project to flesh out during the hackathon would be the rMaps library. Creating a placeholder here to discuss some ideas before we get to the meeting.

@sckott, @ramnathv

ramnathv commented 10 years ago

Thanks for creating a placeholder @karthik. I will add more to this over the next few weeks so that we have something concrete.

sckott commented 10 years ago

@ramnathv note that we invited you to a hipchat room for chat...

ramnathv commented 10 years ago

@sckott Ah! I had forgotten about that. Joined now.

msund commented 10 years ago

Hey @ramnathv, @sckott, & @karthik,

We recently took a pass at rMaps and made two population bubble charts. If you all would be interested in doing something together, we'd love to work with you and try to be useful. It's a very cool package and fun library that we thought would be cool to combine with something like the weather or population data. I would love to come to this, but will not be around.

Here's the post with code: bit.ly/NDS4mu. If you click through you can see the interactive version (text on the hover).

plot.ly/~MattSundquist/878/.

canada

plot.ly/~MatthewSundquist/11/

us

jhollist commented 10 years ago

@msund, @ramnathv, @sckott, & @karthik,

From a users perspective, I would love to see the ability to plot sp and raster objects directly with rMaps (or something similar eg. ggvis). As I have transitioned nearly all of my GIS work to R, the one thing that is missing is an easy way to visualize my own spatial data and be able to pan, zoom, and identify. All those tools are already there with the great stuff in rMaps, ggvis, clickme, etc. but the ability to add sp/raster objects isn't there yet, as far as I can tell. It appears you could convert to geojson or KML and draw those, but a quick and straightforward map(mySpObject) sort of syntax would be great. Chaining commands on top of that, ala ggplot2 would also be cool.

Another consideration I think is important is having ways to develop exploratory maps in addition to production quality maps (what I see as the current focus). For instance, The way I generally work is do some sort of geoprocessing and then visualize the results to check things. Having the ability to quickly make maps with zoom, pan and identify without a lot of the background images (e.g. openstreetmaps) would be a great addition.

Anyway, sorry for crashing the party here, but the interactive mapping component in R is missing and with it, I could completely ditch my traditional GIS platform (I won't name names here). Using this with the embedded viewer in RStudio would result in R=GIS!

Anyway, good luck with the (un)hackathon. Sounds like a cool idea!

Cheers, Jeff

ramnathv commented 10 years ago

Thanks for your thoughts @jhollist. That is precisely the idea with rMaps. It is to allow R users to work with spatial objects of all kinds, and be able to visualize them as interactive maps, without having to worry about the implementation details of the backend. A lot of the code in visualizing spatial objects is boilerplate, mainly involving data transformations of various kinds. My vision for rMaps is to take care of this automatically, allowing users to focus on the key questions they are exploring.

Your point on exploratory analysis is well taken. You are right in that currently, most of these JS viz libraries focus on production quality maps. Some libraries like Crosslet that rMaps supports is great for exploratory purposes.

rMaps is still early work in progress. But the vision is to leverage all the mapping related work that has been done in R, and give it an interactive front.

sckott commented 10 years ago

@msund thanks for your comment. We could potentially include an interface to use the plotly api. Something to think about.

sckott commented 10 years ago

Thanks for this @jhollist ! This is awesome to see that there is interest in rMaps and to here your use case.

Continue to let us know what kinds of things you think would be nice to have. See also the repo for rMaps here https://github.com/ramnathv/rMaps

jhollist commented 10 years ago

Thanks @ramnathv and @sckott.

I've spent a little time with rMaps, but not much. I should have some time today to play around. If anything else comes to mind, I'll let you know.

And thanks again for all the great R packages! Makes me want to up my development game.

karthik commented 10 years ago

Hi @jhollist Thanks for the ideas and definitely not an imposition. It would be great if you could come up with a few examples, and even data files that we can use to test out some use case ideas. I understand if you are unable to share current research but actual examples with data and code really help bootstrap things along.

Also, I'll work out the logistics of remote participation if that's of interest to you.

jhollist commented 10 years ago

Karthik,

Let me check my calendar. If I am free, I would love to join in remotely.

Will let you know tomorrow.

As for examples, the two datasets included with lakemorpho might be a good place to start. If you can easily visualize those (raster object and SpatialPolygonsDataFrame) with rMaps, most other sp objects should be relatively easy. They are in an Albers Equal Area projection, so you'd have the other projection to deal with as well. To my mind simple mind, it would just be a matter of reprojecting to decimal degrees and converting to a format (KML or GeoJSON) that rMaps could handle easily. Both tasks handled with rgdal.

I think a lot of this depends on how far you want to hide the details from the user. If you restrict the spatial objects to R objects, then the suite of sp objects (SpatialLinesxx, SpatialPointsxx, etc.) plus raster (at least for me!) would be good. If you want to open that up and allow other spatial datasets to be visualized directly, that is another issue. You'd have to account for shapefiles, file geodatabse, KML, GeoJSON, geotiff, GRID, GRASS data, etc. But again, limiting to sp objects is, I think, clean and justifiable.

Just thinking out loud here.

Jeff

ramnathv commented 10 years ago

@jhollist The more I think about this, it seems like taking a modular approach to rMaps might be useful. I can essentially see two important things here:

  1. Helper functions that can convert spatial objects of different formats into KML or GeoJSON.
  2. Functions to visualize the resulting KML/GeoJSON

I can also see the need for a simple, yet clean UI that will make operating on these really easy. For example, when I think of a choropleth map, the key elements to specify (in my mind at least), would be the map object, the data to plot, the fields to display, key to match map and data, and other styling options. It shouldn't matter to the end user what the format of the map object is.

jhollist commented 10 years ago

The two steps sound good.

As for the UI/use case, often the spatial info is what I want to see initially, the data/fields that I want to map along with that come later. Often there are multiple values associated with a given spatial feature that i'd like to see.

Let me think on this a bit more. I'll get back tomorrow.

Jeff On Feb 19, 2014 10:06 PM, "Ramnath Vaidyanathan" notifications@github.com wrote:

@jhollist https://github.com/jhollist The more I think about this, it seems like taking a modular approach to rMaps might be useful. I can essentially see two important things here:

  1. Helper functions that can convert spatial objects of different formats into KML or GeoJSON.
  2. Functions to visualize the resulting KML/GeoJSON

I can also see the need for a simple, yet clean UI that will make operating on these really easy. For example, when I think of a choropleth map, the key elements to specify (in my mind at least), would be the map object, the data to plot, the fields to display, key to match map and data, and other styling options. It shouldn't matter to the end user what the format of the map object is.

Reply to this email directly or view it on GitHubhttps://github.com/ropensci/hackathon/issues/1#issuecomment-35582282 .

ramnathv commented 10 years ago

I agree. A key strength of interactive maps is that you can easily switch between different value fields you want to view with your spatial feature. For example, crosslet allows multiple value fields to be visualized on a choropleth. For spatial bubblemaps, it should be straightforward to display all value fields in a hover, and at the same time allowing the points to be styled using a particular field, taking advantage of aesthetics like shape, color and size. The possibilities are endless.

Would love to hear more about your thinking.

jhollist commented 10 years ago

@karthik

I am free March 31 and Apr 1 and would love to join in the fun remotely if feasible. I do have a class at 3pm EST on that Monday so wouldn't be available from ~2pm on.

@ramnathv

  1. Using the hover would be nice, but the ability to toggle between hover and on click would be good, especially if you have many features (i.e. dense points could be a pain with the hover popping up all the time).
  2. Ability to layer multiple spatial objects (i.e. points, on top of polygons, on top of raster) would be good.

Lastly, if you want to see some very basic spatial analysis and vis take a look at a recent class blog post. I have used this material to teach workshops on R and Spatial Analysis. The maps are ugly, but they are just using base to quickly see the output of some analytical steps.

I should update the post to include rMaps in the list of (VERY) promising additions!

wbuchanan commented 9 years ago

I assume it's possible to hack at some of Bostock's examples (http://bl.ocks.org/mbostock/7755778) to create something analogous to masking layers based on scale (e.g., only show points at a specific level of detail to avoid the cluttering problem mentioned above). Additionally, it might be good to also consider supporting topoJSON format files as well since their smaller footprint could make for more efficient rendering. I've been attempting to hack at ggvis to do a bit of this, but the way it renders polygons is very different from ggplot2, so rendering a map with 150 + polygons can take a while.