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

[Edzer Pebesma]

Barry, nice observation.

I've also seen some student groups do amazing things with the MEAN
stack, meaning javascript everywhere (JSON database, server side, client
side).

I think that one of the reasons many people now choose to work with R is
that you can do your complete workflow in it. Convenient. However, a lot
of scripts and packages written Today are utterly unreadable [*],
terribly inefficient, or both. There are still people programming
everything in FORTRAN, because they believe it is the best. It is the
best for them, which means they are right.

Right now, when you receive a Spatial* object from someone, you pretty
well know what it is. At least you could know. If you'd receive a JSON
object that claims to have a lot of (multi)polygons with holes, you may
still need to do quite a bit of checking. But then, if this is enough of
a nuisance, it might improve pretty quickly. There will always be people
trying to push new technologies beyond their limits. Whether they
succeed will depend on community and industrial support.

The Google Earth Engine API is an example where remote sensing
researchers with very little programming experience can do computations
on massive earth observation data sets (complete Landsat and MODIS
archives) within no time, most of them using the javascript API.

In http://journal.r-project.org/archive/2013-1/ooms.pdf Jeroen Ooms
makes some good remarks about package versioning, something that the JS
people seem to have done well in some respects (learning from Java).

Thanks for the x-all-the-y meme link!

[*] unintended, or even intended, full with %>% and . symbols.

On 05/29/2015 12:13 PM, Barry Rowlingson 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
> 

-- 
Edzer Pebesma
Institute for Geoinformatics (ifgi),  University of Münster,
Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081
Journal of Statistical Software:   http://www.jstatsoft.org/
Computers & Geosciences:   http://elsevier.com/locate/cageo/
Spatial Statistics Society http://www.spatialstatistics.info

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <https://stat.ethz.ch/pipermail/r-sig-geo/attachments/20150531/a09dbea0/attachment.bin>