mapview
mapview copied to clipboard
r-spatial
plainview equivalent for vector data
Discussed on twitter, but I thought perhaps this issue would serve as a better forum for determining a good plainview equivalent for vector data. @tim-salabim, what would be some data sources that you have in mind? Would you like the view to be static, or just very "plain"/barebones? I assume quick is a primary concern here.
Yes, quick is always primary concern for mapview as it happens often that we might just want to visualise things during workflow. Data sources are the ones for which we have mapview method definitions, hence Spatial*(DataFrame) and simple features in the future. Even though 3D may become of interest in the future, 2D points, lines and polygons will be enough at this stage.
Basically, we want to be able to draw on a blank canvas (i.e. without background map) without the need to reproject. Ideally, also with popup info of the respective feature attributes. The crux in my opinion is to respect the projection information, i.e. preserve relative locations of features to each other. In plainview we simply achieve this via columns and rows of the Raster* data. But I guess it is not that straight forward for vector data (yet, we most likely do know the bounding box and measurement units of the projection - in case we don't we simply scale to be within 0:1, which we already do for data with missing projection information where we render things in the Gulf of Guinea at lon/lat 0:1/0:1 without a background map - see lines 244:401 in https://github.com/environmentalinformatics-marburg/mapview/blob/master/R/leafletControls.R).
So, a starting point would be to create a htmlwidget to draw breweries91 on a plain canvas, e.g. plainviewVector(breweries91). To begin with, only locations would be sufficient, lines, polygons, popups, layering etc can follow later.
Regarding @mdsumner 's comment on D3js, I feel it is too bloated for what we want to achieve here. Though, some of the D3js features may come in very handy in the future.
so, in a static base-R context, how would you like breweries91 to appear?
like plot(coordinates(breweries91)[, "latitude"] ~ coordinates(breweries91)[, "longitude"], type = "p") though not static, obviously
no graticules, aspect should be respected so plot(breweries91, pch = 20) is a better example.
ok makes sense, but could we just naively use svglite to do something like?
#devtools::install_github("hadley/svglite")
library(svglite)
library(mapview)
htmlSVG(plot(breweries91, pch=20))
for starters yes, though in the future I am sure there will b other requirements such as coloring, layering, sizing... so maybe D3js after all?
Yes, very quickly we get to a point where we will need a full-featured svg library.
for sure not my core competence ... but AFAIK D3js makes much more sense than to work around with leaflet - at least for all fast "plain" operations on vector data . Nevertheless we have to think about keeping it as easy to use as it is...
yes, that's why I started this conversation (on twitter). From what I see from here http://gallery.htmlwidgets.org/ there's no general D3 implementation in R, just various bits and pieces
have you seen https://github.com/markmarkoh/datamaps? We could use without an underlying map.
looks interesting, though maybe a little too focussed on maps rather than simple feature rendering. I will have a more detailed look into D3 I think. It just looks like it has much of what we want for a GIS-like canvas.
other option is to use one of the canvas libraries, such as fabric.js
now that is an option that sounds very feasible. As, if I understand canvas correctly, also means speed? plainview as it is right now also creates some canvas objects though I am not sure about the technicalities there as this was written by a colleague.
Now that I inspect plainview a bit more, I think canvas is exactly what we want. Now, I need a beer...
yup the "fast" functions of mapview are using the canvas concept. It is extremely fast but the major disadvantage is that you have to drill down for interactivity due to the fact that the canvas you see is more or less a rendered bitmap. probably easy to solve for somebody who knows a bit more about JS and HTML5... beer is a good idea
pixijs?
On 26 Sep 2016 21:36, "gisma" [email protected] wrote:
yup the "fast" functions of mapview are using the canvas concept. It is extremely fast but the major disadvantage is that you have to drill down for interactivity due to the fact that the canvas you see is more or less a rendered bitmap. probably easy to solve for somebody who knows a bit more about JS and HTML5... beer is a good idea
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/environmentalinformatics-marburg/mapview/issues/40#issuecomment-249674105, or mute the thread https://github.com/notifications/unsubscribe-auth/ACsgwC3PaV-vwGTM23eWraiXzGKd_cBdks5quB7RgaJpZM4KGlHP .
I thought htmlwidgets was enough to get R stuff out to D3 stuff, but I think I am still missing something. I also see a bit of sp munging that could be avoided using the flatten to tables approach in spbabel. If we drove D3 from an object made of tibbles, it could be easily db- backed too. At least, that's what I've been imagining . . .
There's always a layer of custom JS functions you need to write (or, like me, copy from the web). Are you referring to a specific function regarding sp munging? Or just in general?
Just general, I don't have my bearings on this conversation, but every thing here is useful to me.
I've played enough with htmlwidgets to get some SVG and D3 magic going, but I have to concentrate quite hard and it's difficult to start up again. It's time I spent more focussed time on it, I think what I've learnt with spbabel and rangl will be useful, and I'm willing to help! If there are partial solutions or problems to tackle I can do that, but otherwise I'm starting from scratch with htmlwidgets and Bostock's "let's make a map" or similar. I imagine that one of you could whip up a tool with pre-canned data, and maybe I can help generalize the part where we get those data from R?
I'm not super enamored with GeoJSON and it seems we can shortcut to D3 a little better rather than go through serializations like so many tools seem to, even TopoJSON is not so much "topology" as scaled/offset-integer encoding of floats (though that is readily "topologized" since there's no numeric fuzz to get in the way) - would being able to generate that "live" be helpful? (The auto-densification that D3 does with TopoJSON is a clear winner for solving many projection issues, and learning to use that will be important for supporting curve geometries that we should be able to access via sf now, too).
@mdsumner this kind of problem solving approach sounds familiar to me :-) I absolutley agree with your position. A lot of magic is possible but it is not worthwhile to produce it again and again from scratch and outside the mapview framwork. In my opinion the bottleneck is to communicate via htmlwidgets in both directions. If somebody (@timelyportfolio ) is able to tackle this general problem it seems to be fairly ok to integrate some really nice to have stuff in mapview
Happy to work on this, but I suffer from an ignorance of common tasks in the geo world, so I will lean on y'all to give me some direction.
Should we start with a D3 based equivalent of plot(breweries91, pch = 20)? In mapview or an extra package (D3geo)?
I would strongly recommend not building our own plotting library unless absolutely essential to have custom functionality. Building and maintaining even hyper-focused plotting libraries is a massive effort. I would suggest we find a JavaScript plotting library (canvas and/or svg) which we can use as a platform.
Not sure I understand, D3js is a JavaScript platform, isn't it? And it does also work with canvas as far as I've seen
Yes, but d3.js does not just draw data for you. To go from data to plot/vis requires manual translation and programming so for a generalized workflow quickly becomes overwhelming. Would think leveraging plotly, vega, plottable, dimple, or some other flexible framework will be much more beneficial.
Ok, after a good discussion last night with @gisma over a few beers, we kind of have decided to put this on hold until we formulate a good requirement description for mapview in general. So for now, if someone comes across something interesting regarding plotting spatial data with JS please post here so we can collect ideas.