OpenEO: Earth Observation data cubes
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 295 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Germany: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/43452 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
00:00
Information securityProjective plane
00:31
Computing platformProcess (computing)Projective planeShift operatorProgramming paradigmBuildingDisk read-and-write headSelf-organizationComputing platformProcess (computing)State observerPoint cloudBitComputer animationLecture/Conference
01:03
Process (computing)Computing platformInstance (computer science)Interface (computing)TelecommunicationStandard deviationAngleGraph (mathematics)CubePixelComputer fileMultiplicationScalabilityPixelScalabilityOpen setProcess (computing)MereologyCore dumpLatent heatImplementationClient (computing)Projective planeStandard deviationFront and back endsMultiplicationINTEGRALOpen sourceComputer fileRepository (publishing)Electronic mailing listWritingCategory of beingWhiteboardCubeScaling (geometry)SoftwareState of matterInstance (computer science)Data fusionComputer animation
04:01
Demo (music)Process (computing)DisintegrationGroup actionSurfaceAlgorithmAreaDirected setCASE <Informatik>Metric systemInformationProgrammable read-only memorySeries (mathematics)Cantor setRule of inferenceEstimationMusical ensembleWell-formed formulaCubePrice indexLemma (mathematics)Point cloudAcoustic shadowLevel (video gaming)Operator (mathematics)CASE <Informatik>Demo (music)Process (computing)Web serviceSystem callBitWorkstation <Musikinstrument>Drill commandsGoogolMereologyGraph (mathematics)Client (computing)Medical imagingWell-formed formulaConstructor (object-oriented programming)ResultantRepresentation (politics)Point (geometry)Connected spaceElement (mathematics)Software developerVideo gameCodeGoodness of fitUniform resource locatorWeb 2.0Subject indexingComputer animationLecture/Conference
07:16
Total S.A.BefehlsprozessorPoint cloudRaster graphicsKernel (computing)CodeFunction (mathematics)Binary fileMotion blurFuzzy logicMusical ensembleDistanceImage resolutionComputer-generated imageryAreaAcoustic shadowPixelSummierbarkeitProcess (computing)Graph (mathematics)StapeldateiIndependent set (graph theory)CubeWeb serviceLetterpress printingMathematical analysisSeries (mathematics)Disk read-and-write headTime zoneAuditory maskingAlgorithmBounded variationPlot (narrative)SmoothingInterpolationDigital filterPrice indexUser-defined functionHausdorff dimensionRun time (program lifecycle phase)Revision controlBlock (periodic table)Electronic visual displayTemporal logicIterationSample (statistics)ImplementationoutputShape (magazine)Electronic signatureDefault (computer science)Parameter (computer programming)Element (mathematics)Error messageContrast (vision)Electronic meeting systemEvent horizonInfinite conjugacy class propertyPoint cloudAuditory maskingRaw image formatCodeMedical imagingPixelKernel (computing)BitTime seriesPolygonFeld <Mathematik>outputAverageCubeDimensional analysisSmoothingAlgorithmPresentation of a groupLevel (video gaming)Fuzzy logicConvolutionMultiplication signRight angleSeries (mathematics)Functional (mathematics)Term (mathematics)Computer filePlotterResultantGoodness of fitAreaOperator (mathematics)Web serviceCore dumpDemosceneLine (geometry)Complex (psychology)Ferry CorstenLibrary (computing)Doubling the cubeGoogolSystem callVideo gameVotingLattice (order)Real-time operating systemKey (cryptography)Negative numberField (computer science)Diagram
12:15
Process (computing)Demo (music)StapeldateiMachine learningLevel (video gaming)AlgorithmBitOperator (mathematics)StapeldateiAlgorithmInformation retrievalVirtual machineState observerWeb 2.0Medical imagingFront and back endsObservational studyTime seriesNumeral (linguistics)1 (number)Machine learningLevel (video gaming)Process (computing)Instance (computer science)Category of beingComputer animation
13:48
Computing platformGrass (card game)Server (computing)Gamma functionGeometryNormed vector spacePlanar graphText editorWorld Wide Web ConsortiumHill differential equationWeb serviceFunctional (mathematics)Connectivity (graph theory)GoogolInstance (computer science)MereologyLevel (video gaming)Chief information officerGroup actionLibrary (computing)Open sourceComputing platformInterface (computing)Process (computing)Uniform resource locatorFront and back endsGraph (mathematics)Software developerText editorSlide ruleComputer animation
15:32
Latent heatInstance (computer science)AlgorithmVirtual machineNeuroinformatikMoment (mathematics)Data centerInterface (computing)Front and back endsComputer animation
17:45
GoogolProjective planeMereologyFront and back endsBitInterface (computing)Universe (mathematics)Open sourceSpring (hydrology)Source codeComputer animationLecture/Conference
Transcript: English(auto-generated)
00:07
All right, awesome. OK, well, welcome. Without further ado, this is Jeroen from OpenEO. And he's going to be talking about some cool stuff.
00:21
Yeah, hi. Thanks for coming. So OpenEO, quick recap of what it is and why we started the project. It's an H2020 project funded by European Union. And it started when, of course, you do the paradigm shift that we had in our observation of processing,
00:43
moving towards the data, and moving towards cloud. You see multiple organizations starting to build processing platforms on their respective clouds. And of course, that ends up with a bit of a problem because users are isolated in the platform that they use.
01:01
But they cannot easily switch platforms. It's harder to reproduce work, et cetera. It's a fairly well-known problem. And also, the solution is fairly well-known. That is, of course, to build a standard. So that's the core of OpenEO. It's an API specification.
01:22
But when we conceived the project, we immediately said, OK, no, we don't want just the API. It's very important that we, from the start, start building back-end software, multiple back-end implementations, actually, and also multiple client implementations.
01:41
Because that's what you need to get a standard that actually works. You can only verify it by implementing it. And so when we talk about OpenEO, it's also that part that we think is very important. Another important part is, of course, the open part.
02:03
We conceived it as basically an open source project. So the community was very important to us, and also the aspect of community building. Therefore, one example of that is that also the API itself is developed in GitHub as a project there in the open source
02:24
way. And it's based on open API specification. So while normally, when you think of a standard, it's lots of documents. We tried, well, it's still documented, of course. That's important. But we tried to make it easier for users.
02:41
So from the open API specification, we generate the nice documentation with examples. We try to explain it very well. And also, a very important part of the OpenEO specification is actually the processes itself. So whereas, for instance, in WPS,
03:02
you know how to invoke a process and how to define it, but they don't define the processes. And an integral part of OpenEO is actually the processes themselves. So you see them here. We have a whole list of them. And they're also in the repository.
03:24
Another aspect that we took into account is, of course, data cubes. Everybody knows they're quite convenient. For us, it means that you're not dealing with files anymore. You don't have to open files and write files. You get pixels being aligned automatically
03:42
when, for instance, doing multi-sensor data fusion. And of course, scalability is also important. That is, of course, not a property of a standard, but more of a back-end implementation. But at least the standard tries not to get in the way of scalability.
04:02
So that's enough for the maybe more boring stuff. So let's try to show what it actually looks a little like at this stage. So I built a demo in my Jupyter lab. That's where I usually do my small code experiments.
04:25
The demo is also available online. And in this demo, it's about trying to process some Sentinel-2 data for an agriculture use case and mostly about the pre-processing part because the other stuff simply isn't finished yet.
04:42
In the demo, I will be using the back-end that we host at VITO. Wait, I have to see how to scroll down here. Good. And the first thing you do when, yeah, first you need to have a back-end URL. OpenEO is a web service, so you need to paste URL.
05:02
You specify the web service. Then you can list collections if you want. And the collection is like a Google Earth Engine image collection or a layer. You find the ID, and you connect to it. It's lazy, so I just did that.
05:21
But nothing really important happened because we are still specifying what data we want to access and so on. The next thing I want to do in the demo is I want to use a nice vegetation index called the enhanced vegetation index, which has still a relatively simple mathematical formula.
05:43
And the Python client of OpenEO allows me to use mathematical operators to express that. So we were a bit inspired by tools like NumPy and Pandas to really make the client-side code look very elegant and normal to researchers
06:03
that like to work like this. When we run this cell, in fact, we don't really do any processing yet. This is, again, what's happening in the background. What OpenEO does for us is it constructs what we call a process graph, which
06:23
is just a graph representation of our small workflow. And if we draw it like this, then yeah, you really see it that multiple elements are combined. And that's what makes it possible to send the same graph to multiple back ends that
06:41
should give the same result. So that's how it looks like internally. It's more complex than the client-side code. So this is mostly for the developers working on the OpenEO tools themselves. OK, now I want to actually see my image.
07:03
I have a nice download method for that. I'm not going to be adventurous and run it live, given that the connection may not be so good here. And I get this image. At this point, there is a bit of a problem. You see that there are some white areas.
07:21
That's clouds being removed. But there are still some cloud left at the edges. That's a well-known problem with Sentinel-2. If you use the center core scene classification, then you don't get, not all clouds are filtered out. So a very traditional step is then to use some cloud masking.
07:43
I have the scene classification layer available. And I also have these nice logical operators that I can apply to construct my mask. That gives me a simple binary mask. And now I'm going to do something more complicated. Because if I use this, then still I
08:01
will have cloud in my image. So I'm going to blur it out a bit to extend the mask beyond the pixels that are marked as cloud into the pixels that are maybe clouds. So it's a bit of fuzzy logic here. And I'm going to apply a caution using
08:22
a 2D convolution operation. And in OpenEO, that's just called apply kernel. And the kernel itself is constructed using SciPy. So when we look at that result here,
08:44
here you see that my raw image is on the right. And in the middle, you see that I now have some more clouds removed. And here is the fuzzy mask that I applied. So OpenEO allows me to retrieve that all
09:01
in real time. So I actually have the timings here in the notebook. So that's on image level. Actually, OpenEO also allows me to create a viewing service. That's quite nice. So you can say, hey, OpenEO, give me a WNTS
09:20
so I can browse my map a bit. That's not in the demo yet. But I'm going to continue with looking at some time series. So now I'm going to look into time. And first, I will aggregate, take the average pixel values inside a polygon that corresponds
09:40
to an agricultural field and plot that somewhere here. And I plot the data with my mask applied and without. And although my mask values are a bit better, it's not yet smooth. So now I wanted to go for a more complex
10:02
smoothing operation. But I'm lazy. I don't like complex. So I'm going to use something that's already available in SciPy, which is an algorithm called the Savitsky-Kolai filter. Now, the thing is, well, first, let's apply it
10:24
on the time series. So the green line looks a bit smoother already. So I'm happy with that. But now I want to do that on the pixel level but without actually having to re-implement it in terms of OpenEO predefined functions.
10:40
And for that, OpenEO has a very nice feature called user-defined functions, or UDFs, where you can simply write a piece of Python code that can reuse libraries and send that to the backend, which is then run either on a single pixel or on a time series of pixels, depending on how you specify
11:04
or which function you use. So I'm going to show the UDF. I load it from a file here. It's a bit of Python code. The input is actually NumPy arrays. It can use pandas, and it can use the SciPy
11:22
Savitsky-Kolai filter. And I have this nice apply dimension method available in OpenEO that I'm going to run on my data cube and then extract the time series. And then we get this result.
11:42
Maybe I should have compared it with applying it on the polygon, but actually, it's already, again, a bit better. And the nice thing is that if I now download an image, ah, no, that's gone. Normally here, there should be an image,
12:01
but that's probably not going to happen anymore. Yeah, time is short, so let's not wait for that. Good. Back to the presentation. So those were already a few important features,
12:22
capabilities of OpenEO. But there is more that's already implemented or planned to be implemented. An important one is batch processing. All of the operations I showed was happening on the fly because they were small, working on smaller bits of data. Although the backend that I used is using geotralis
12:41
and Spark, so it's scalable. It can process more. But, of course, a web request can time out. So if you have requests going on, that will take multiple minutes, and you can do batch processing. And there we are looking at, for instance, retrieving time series for 10,000s of fields
13:02
by running a batch process. Machine learning is, of course, something very important. Another nice one is that we are connecting with Sentinel Hub. Those guys have done a ton of work in integrating numerous Earth observation data layers, and we don't want to re-do that,
13:20
so we just integrate it into the backend so that we can offer layers that will fetch the data from there. And another one is, of course, integrating more higher-level algorithms than the ones you have seen here. So maybe doing image segmentation, a lot of machine learning algorithms are in that category,
13:44
or maybe atmospheric correction, typical Earth observation things. To wrap up, there's also some other nice tooling being developed. One is the Hub that lists all of the available backends.
14:02
And the nice thing about these backends is that a lot of them are really built on open-source components. For instance, the URAC-WCPS backend is built on Resdaman. We have Mundialis running on the Actinia platform that uses CROSS internally.
14:21
And ours is built on top of the Geotravis library, which is also a location tech project. And we aggregate all of them into the Hub to make it easy for users to find. Then there's the editor of OpenEO.
14:45
That's also a nice tool. There, people can have an online workspace where they can also construct these process graphs.
15:02
Here, using the boxes, it's clear over there. And then they can create, for instance, a web service out of that and browse a map. This one is using the Google Earth Engine. So we also expose some of the functionality that's in Google Earth Engine,
15:20
but through the open interface. Okay. Yep. Back to the slide show. And that's it. Thank you. Any questions?
15:50
I don't see the audience so well, so... All right. Okay, so the question was...
16:04
Yeah, the question was if there's any way to run the computations on the GPU. Currently, there's no backend that does that, to my knowledge. But the nice thing is, of course, that we can...
16:21
Yeah, indeed. And also machine learning, for instance. So that's what we are looking at at Vito and are very interested in. So we already have some custom Spark algorithms that use GPU, but exposing that through the OpenEO interface,
16:40
maybe even in a very transparent manner, would really be nice to have. Yep, that's another one.
17:03
Actually, not already at the moment, but we hope to have it in two weeks or so. So we've been working on it for some months. And actually, that's also the Vito backend that we are deploying there. So some backends are more tied
17:21
to a specific data center than others because they already have a lot of infrastructure in there. But we are also looking at deploying it on Dias. So it should hopefully not take too long anymore.
17:52
So the question was that we indeed expose Google Earth Engine layers and how we integrate. So the nice thing is actually that Google is part of the project,
18:05
although they are not funded, but they are a partner. So they were so nice to help us out a little bit by basically answering our questions. So the Google Earth Engine backend is built by Munster University.
18:21
And they were, I mean, Google was helping them out, telling them how to best interface. But basically, they are translating to the Earth Engine web API, I believe. And that backend is also available open source, so I think you can even look it up. Thank you.