Functionality for the first example of proof-of-concept

[GreatEmerald]

It would be useful to have an overview of what is available and what is still missing in order to be able to perform the first example of the proof-of-concept.

The data is there, the processes seem to be there now, generating the process graph in the client works, but I can't get a result from the backend (possibly due to issue #1). Is it intended to be functional already? Are lazy and synchronous methods of processing implemented, or not yet?

It would help to also include some sort of status overview in the repository (in the readme or a separate file).

[flahn]

The first use case should work with synchronous execution. However, when I started the implementation on that the process graph used the parameter name "imagery" and i adopted that into the code for evaluating the process graph. This needs to be fixed at some point.

In the "old" graph definition it should look like this:

task = collection("sentinel2_subset", id_name="product_id") %>% 
  process("filter_daterange",prior.name = "imagery", from="2017-04-01", to="2017-05-01") %>% 
  process("calculate_ndvi",prior.name = "imagery", nir=8,red=4) %>% 
  process("find_min",prior.name = "imagery")

[GreatEmerald]

Hm, I just updated both the backend and client packages (develop branches), and now I can't seem to be able to start up the server correctly (I think?): the client just says "Login failed."

It's also very weird in that if I try to start the server using the snippet of code you have in the README (set the workspace path to /tmp/openeo), I seem to be able to start the server if I run it from Rscript but not from an R GUI. The latter gives me an error:

Error: lexical error: invalid char in json text.
             /tmp/openeo/openeo.sqlite/user.j
(right here) --^

Either way I can't log in, though.

[flahn]

Oh, I just saw that my start script looks different than the README one. I will update that. As a quickfix: you should run the follwing to start the server:

library(openEO.R.Backend)
rm(openeo.server)
openeo.server$data.path =  paste(system.file(package="openEO.R.Backend"),"extdata",sep="/")
openeo.server$workspaces.path = "C:/code/openeo-r-workspace"
openeo.server$initEnvironmentDefault()
openeo.server$initializeDatabase()

openeo.server$createUser(user_name="test", password="test")
openeo.server$loadDemo()
openeo.server$startup(port = 8000)

The reason for this is the switch to a sqlite data storage for users, jobs and such, rather than storing them in individual json files.

[GreatEmerald]

Right, that works, at least on the master branch of the backend. But I take it I should use develop. I'll try that.

But on the master branch, the synchronous job succeeds, yet what is returned is a raw object:

[1] 7b 22 6a 6f 62 5f 69 64 22 3a 22 46 74 4a 37 52 6c 64 73 72 48 30 34 39 4f
[26] 66 22 7d

That looks too small to be a raster.

[flahn]

That looks indeed odd. I guess, that this is an base64 encoded json error response. The executeTask method will return raw data as a default. Calling it with a valid GDAL write format should result an image.

res = con %>% executeTask(task,"GTiff")

[GreatEmerald]

Reran it on develop, the response is exactly the same. I do already pass format="GTiff to it... I'm literally running the commands on the Jupyter Notebook, in this case Result = executeTask(conn, Task, format="GTiff") which is functionally identical.

[GreatEmerald]

Huh. I used a hex to ASCII converter, and this actually is:

{"job_id":"FtJ7RldsrH049Of"}

But that's synchronous, why is it giving a job ID?

[flahn]

OK. I messed up. I haven't connected the "sync" operation with the download function (accessable via GET /api/download/{job_id}, which was not specified by the api). I have implemented that before we had the discussions about synchronous jobs and i simply forgot to chain it, now. I will fix it asap.

[GreatEmerald]

Huh, so you mean the sync method is currently going through the lazy method, so it keeps track of state in either case?

In which case, that makes me wonder why queueTask and orderResult are returning NULL. Not implemented yet there, or am I doing something wrong?

[flahn]

No the other ones are not implemented yet. Since I, currently, have no counterpart for that on the backend.

[GreatEmerald]

OK, good to know.