Hi @kardemummabulle 

You raise an interesting question! I hope that anyone from safe  @dmitribagh , @markatsafe @debbiatsafe can comment on this

BR

Felipe Verdú

Hi @kardemummabulle,

I had a lot of fun playing with some R libraries such as rayshader, rayrender, brickr, even raybonsai, and my main struggle was inability to use snippets generated in other places of a workspace for inclusion and execution inside the RCaller. It really feels like not that many people are interested in using R with FME - I never heard back from anybody after all my demos, presentations, and tweets about R integration. Maybe it’s because we have so many Python fans in the FME Universe?

In order to move the R integration forward, we need to hear from you, our customers, that you need it - with enough demand, we can begin working on the necessary improvements.

Dmitri

Hi @dmitribagh,

Thanks on following up on my question. I would guess that Python wins in terms of number of fans and users, and it is so much easier with Python in FME compared to R, so I am not surprised at all that RCaller and PythonCaller are at totally different levels It is just way easier to do exact same thing in Python I assume...

I feel like just making FME recognize output from R in a simple manner would be a tremendous improvement. Something like:

fmeOutput=dataset # dataset being the output of R

without explicitly telling FME in advance if it is a dataframe, a raster, raster list or whatever… There is gotta be a way to make it happen, I think :)

-Sveta

Hi @kardemummabulle,

How do you get around the limitations now?I checked my R scripts (I didn’t touch R for 5 years, and don’t have all the details on top of my head), and found that I was generating a temp path, which I was passing to the script, which saved the results, and then I used FeatureReader to bring the result back into FME. Not the most optimal way, but it worked for me.

Dmitri

Hi @dmitribagh,

That would be the easiest workaround I guess. This solution works, but as you mentioned it is not optimal if one for example wants to continue with the workflow and have a more or less connected pipeline…

The last thing I have done with raster list output from R is writing the path and explicitly telling FME that fmeOutput contains 4 rasters (kindly see picture attached). Then you can sort of continue your analysis, like with CoordinateSystemSetter in my example (though it is also a question why FME lost the projection that I set in my R script which works otherwise in R or RStudio), and FeatureReader and so on… It took a bit of time to make this work and FME really did not want to cooperate (mostly because I was not really understanding what it wanted; I know R (I think), but I don’t really know FME that well) :)

If this is something that can be solved in a more elegant way in FME or if there is way to make FME and R communicate with each other better than they do now, then I think it would be so much easier to integrate more complex R-based analyses inside FME…

With Posit growing so fast, R has really developed a lot over past few years (Markdown, Quatro, Shiny, all the hyped packages for geospatial analysis)… Just imagine how cool it can be if R and FME were compatible… Btw regarding compatibility, currently to make FME “accept” output from R that contains more than 1 cell and 1 row, one needs to have R version 4.1.3, which is like a “prehistoric” version of R, from 2022 or so… There is a potential for improvements for sure, the question is if Safe wants to continue with RCaller and to develop it further…