Merge pull request #5 from Open-EO/master

sync

README.md

@@ -92,7 +92,7 @@ This R package has implemented 4 strategies for the R UDF service. All of these
 ### Performance
 Out of the strategies mentioned above, Strategy 1 is ultimately trivial since it does not offer a RESTful API. Therefore, although, faster than some of the other implementations, it is not practical in the context of openEO. Strategy 2A offers a REST interface, but as it exposes only a list of numbers (representing pixel values) to the UDF, the functionality of this strategy is limited to simple operations (e.g. aggregation over time, band etc.), similar to Strategy 1.
 
-Strategy 2B exposes the whole `stars` object to the UDF, but as the EO data has to converted from ASCII JSON arrays from the incoming POST request to binary objects and reconverted to JSON arrays from binary objects while sending the response back, it is rather slow. Strategy 3 overcomes this limitation by sending the data as a base64 encoded string representing binary GeoTIFF files and offers a much faster turnaround time for running an UDF. Furthermore, this strategy allows users to install and use any R package (from Github, CRAN etc.) in his/her UDF and also load data from online sources, therefore allowing a lot of freedom and flexibility for the user. Now, auxilliary data in the form of files/directories can also be passed from the backend to the UDF service (for Strategy 3 only) by putting the data in a directory named `/data` in the ZIP file that is passed on as a base64 encoded string. These files are made available to the UDF script locally (in the same working directory).
+Strategy 2B exposes the whole `stars` object to the UDF, but as the EO data has to converted from ASCII JSON arrays from the incoming POST request to binary objects and reconverted to JSON arrays from binary objects while sending the response back, it is rather slow. Strategy 3 overcomes this limitation by sending the data as a base64 encoded string representing binary GeoTIFF files and offers a much faster turnaround time for running an UDF. Furthermore, this strategy allows users to install and use any R package (from Github, CRAN etc.) in his/her UDF and also load data from online sources, therefore allowing a lot of freedom and flexibility for the user. Now, auxiliary data in the form of files/directories can also be passed from the backend to the UDF service (for Strategy 3 only) by putting the data in a directory named `/data` in the ZIP file that is passed on as a base64 encoded string. These files are made available to the UDF script locally (in the same working directory).
 
 Here are some test results for operations on a timeseries (3 timesteps with a temporal resolution of ~10 days) of spatially subsetted (300*300px) Sentinel-2 images containing 13 bands each illustrating the performance.