Open christophfriedrich opened 2 years ago
The reason is that underlying components have been updated, while the openeo GRASS driver at https://openeo.mundialis.de has not been updated. @m-mohr is it ok if we update the openeo GRASS driver at https://openeo.mundialis.de? The updated version would conform to the openEO API v1.0.
Sure, why not? Actually, I'm not exactly sure why you ask me whether it's okay to update your service?! 😅
Asking you because https://openeo.mundialis.de was our reference implementation for the official openEO project and we were not sure, if or for how long we should keep this reference implementation running as is after the end of the project. Thanks for your answer!
Alright, I was not sure and thought you were updating that implementation also for your other projects. Wasn't aware that these are separate. I guess at some point it would be nice to replace the reference implementation with what you use and develop in other projects (e.g. DLR)?! Is that a public interface?
https://openeo.mundialis.de is updated to latest release. Please try again @christophfriedrich
@m-mohr yes the interface is the same, only underlaying functionality is growing, e.g. we work on exposing all t
(time) modules of GRASS GIS as /processes
to use them for processing and registering STAC collections via actinia which can then be used as /collections
.
Okay, good to know. I'm not sure how useful it is to have separate instances running, in principle I think this could be replaced with your new instance.
TODO: Compare implemented error handling with https://api.openeo.org/#tag/EO-Data-Discovery/operation/list-collections
Currently, https://openeo.mundialis.de/api/v1.0/collections replies with:
Aside from that it would be nice if this error wouldn't be there at all (:wink:), there are a couple of issues with that error response:
400
) is meant to be a HTTP status code, it is a wrong one because "internal error" should result in something in the 5xx range.200 OK
.