[R-sig-Geo] Javascript All The Things!

[Michael Sumner]

I'm really sorry to Barry and the list, this was really rude and
inappropriate.

I appreciate the stimulus for discussion, and I have some contributions but
will leave them for now.

Apologies. Mike

On Sun, 31 May 2015 at 01:04 Michael Sumner <mdsumner at gmail.com> wrote:

> Surely you understand that standard x-y polygon operations are
> fundamentally simplistic? Polygons are a special case where you dumb down a
> 2D topology into a 1D geometry.
>
> This is no surprise, how many tracking packages are there (dozens), how
> many surface packages are there (rgl).
>
> Javascript has a few shining lights in D3 and htmlwidgets. It's not an R
> revolution it's a latent GIS one.
>
> What are you really talking about?
>
> Cheers, Mike.
>
> On Fri, 29 May 2015 at 20:13 Barry Rowlingson <
> b.rowlingson at lancaster.ac.uk> wrote:
>
>> [Apologies for the memey subject:
>> http://knowyourmeme.com/memes/x-all-the-y]
>>
>> Developers can't fail to have noticed the rise of Javascript, both in
>> the browser and outside of it. But it has now crept into R, and into
>> R-spatial packages.
>>
>> Javascript, like most languages, has its right to exist and its place.
>> I'm just not sure that using it to call functionality that exists
>> perfectly well elsewhere in R is the place.
>>
>>  For example, there is a Javascript library called "turf.js" that does
>> GIS operations like polygon overlay, buffering, point-in-polygon etc.
>> That's great, because now my web mapping interface can do those in the
>> browser. The user can draw a polygon, the browser can select the data
>> and do something with it without a round-trip and a load on the
>> server. Brilliant. That same Javascript can also run perfectly well
>> outside a browser via a JS interpreter such as node or V8, so its
>> possible to use turf.js to write javascript scripts to do GIS
>> operations. Again, brilliant. If you are a JS programmer developing
>> systems in JS that need this, you've now got it.
>>
>>  Now there is a package (V8) to run Javascript in  R. Great. If
>> there's some JS functionality you want to call. But why should you use
>> it to access functionality you've got in a perfectly good R package
>> already? The turf.js code has been wrapped in the "lawn" package, so
>> you can call turf's GIS functions from R. Some people on twitter seem
>> to think this is novel, and suddenly you can now do "GIS in R!". They
>> seem to have not noticed we've been doing it for the past umpteen
>> years with things like gpclib, and lately rgeos.
>>
>>  Why use "lawn" instead of "rgeos"? Twitter isn't a good place for
>> such discussions, and all I've got out of people there are things like
>> "but if you have a geoJSON workflow". I'm not sure that makes sense.
>> geoJSON, if you don't know, is the lingua franca of spatial data in JS
>> (and is supported by GDAL/OGR). But if you are going to read your data
>> into R at some point its going to get converted out of geoJSON into
>> native R formats. There's overheads both ways. I've not benchmarked
>> any of this yet, but I have a hunch data conversion and interfacing to
>> JS is going to be slow compared to native rgeos calculations. The lawn
>> package web page seems to concur.
>>
>>  Another example of "JS All The Things"  manifested today. The rgbif
>> package uses rgeos to read WKT data. But a recent change from the
>> author replaced that with some JS code. So now instead of calling
>> rgeos::readWKT, this happens:
>>
>> read_wkt <- function(wkt) {
>> terr$eval(sprintf("var out = terrwktparse.parse('%s');", wkt))
>> terr$get("out")
>> }
>>
>> where `terr` is a handle to the JS code. Again, I've not benchmarked
>> it, but there appears to be a lot of string conversion and passing of
>> data from one world to another. Plus there's the overhead of loading
>> in a completely new language interpreter via a dependency on the V8
>> package, compared to loading in some clean C code.
>>
>>  So I'm mind-boggled. Why is this happening? Is it just that JS is
>> trendy? Is it that there is a surfeit of JS programmers? Is it
>> speculative "because I can" development? Should R-spatial data look at
>> this as evolution and consider the future of sp classes?
>>
>>  Discuss. Maybe its something those of us at the Geostat Summer School
>> in August can have a good chat about, although I don't think anyone
>> from the JS side of things will be there... Maybe in 2016....
>>
>> Barry
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> R-sig-Geo at r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>

	[[alternative HTML version deleted]]