Crunching Data In GeoServer: Mastering Rendering Transformations, WPS Processes And SQL Views
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.
Aime, Andrea
This presentation will provide the attendee with an introduction to data processing in GeoServer by means of WPS, rendering transformations and SQL views, describing real applications and how these facilities were used in them. We'll start with the basic WPS capabilities, showing how to build processing request based on existing processes and how to build new processes leveraging scripting languages, and introducing unique GeoServer integration features, showing how processing can seamlessly integrate directly in the GeoServer data sources and complement existing services. We'll also discuss how to integrate on the fly processing in WMS requests, achieving high performance data displays without having to pre-process the data in advance, and allowing the caller to interactively choose processing parameters. While the above shows how to make GeoServer perform the work, the processing abilities of spatial databases should not be forgotten, so we’ll show how certain classes of processing can be achieved directly in the database. At the end the attendee will be able to easily issue WPS requests both for Vectors and Rasters to GeoServer through the WPS Demo Builder, enrich SLDs with on-the-fly rendering transformations and play with SQL views in order to create dynamic layers. Andrea Aime
 So, Andrea is going to present some work on WPS, which actually started back then in that code sprint. Yes. You were working on that, yeah. And SQL views. We have 20 minutes, then five minutes for presentations. Okay, so, processing data in GeoServer with WPS on SQL views. As you already know, my name is Andre Aime. I work for Geosolutions. It's a company based in Italy. We provide support for GeoServer, GeoTools, GeoNetwork and so on. And not just support for use, we are actually core developers in each and every of these projects. Meaning, we can push changes into them and improve them, and we do so regularly. So today's presentation is about, well, WPS and web mapping. So many years ago, doing web mapping basically meant to push a map on the net, do some styling and maybe some editing, maybe some PDF printing, and that was most, all of it. Since a few years ago, it's almost impossible for Geosolutions to make a web application without having some processing into it. Most of the new applications we make are not just mere visualization and data instruction tools, but they are actually providing some capability in terms of processing. So this presentation is about showing how we use GeoServer WPS to power several types of applications. So first, some quick reminders about WPS. WPS stands for Web Processing Service. It's the OGC way to expose for a change, not data, but processes to the web. And the web can then provide the data. The WPS does the computation and provides back results. Simple example here, applying a buffer to a line. I have the line which is an input. I invoke a buffer asking for a distance of two, whatever, two meters maybe, and I get back a buffer geometry. This is sort of the simplest example I can think that's also Geospatial. WPS can do also non-Geospatial calls like I could write an L award process if I want to, but wouldn't be very meaningful. WPS is one of the few OGC protocols that supports asynchronous requests, which is very important for a number of cases, and we are going to see some of them. So in most OGC protocols, you make a synchronous request. You send an HTTP request to the server and you wait for the request to come back. When it comes back, you get the answer, period, which is nice. It's simple. It doesn't work if you have to wait for minutes to get the request back because the HTTP connection is going to rot in the meantime, probably get severed. In a synchronous, you send a request. You get back right away a response that says, okay, I took care of that request. I'm going to process it and here is a URL that you can pull to verify how far along I am. Maybe you pull it. It's queued. It's queued. It started 10%, 50%, 90%. Oh, look, here is the result. The common WPS setup, well, the basic one assumes that the WPS has no data, no local data, and it's going to fetch it from other OGC services or from random HTTP server calls. It's going to fetch the data, process it, and then return it back to the client, which is a sort of limiting if you have to play with the very large amounts of data. In GUServer, the WPS is integrated in an ecosystem. GUServer has its own local layers, has its own local services, and so on. The WPS can play in this ecosystem. So in GUServer, the WPS, you can fetch data from local layers just by using their names instead of passing around the data. There is a nice integration with WMS with rendering transformations, which are a way to put in your style a directive that will call to a WPS process before rendering the data, so you can transform the data on the fly. One example, contour extraction. We have an integration with the GUServer UI, so we have a demo page to try out the WPS request, and so on. So we got a bit more connections in our WPS than normal. This is the demo request builder. I'm not going to spend time on it. It's not particularly interesting. Rendering transformation, as I said, one example of, as I said, applying a transformation on the fly while we render stuff so that we don't have to keep 10, 15, 100 versions of the same data processed in a different way. We just always do it on the fly. The rendering transformation are particularly optimized in such a way that they only process the area that's visible in the current get map request and only at the resolution requested. So we never work at the native resolution. If you are looking at a giant digital elevation model of the entire world at 10 meters, when you look at it, you are looking at it at, I don't know, 30 kilometers per pixel, and that's the resolution we use to extract the contour line for that zoom level. That makes for fast extraction. It gives us the best of both worlds. So before we dive into WPS, let's take one step back to the processing you don't always need the WPS. There are spatial DBMSs that you can use. Spatial DBMSs such as post-GIS can do computation on the fly in SQL. It's pretty efficient. It has all the data locally. It can do several type of computations. So why not leverage it? And the answer is, well, if it fits your purpose, do it. In GeoServer, we have a notion of parametric SQL view. So the normal SQL view would be that instead of pointing GeoServer to a table, you give GeoServer an SQL statement to run as the data source. And with that, you can already do some processing. What makes it more interesting is that in that SQL, I can embed parameters that will come from the client, from the web, to control how the computation is done. Of course, you have to protect yourself against SQL injection attacks. So we have some validation going on. But generally speaking, if your data is only in a spatial database and you can express your processing as a query, maybe with some parameters to control it, by all means, do your processing this way. It's probably one of the most efficient ways to do it. It's not always the best. I'm going to show you some cases in which different approaches are required. This is an example of a query that builds using a steam acline lines out of sets of points over time. So let's have a look at some examples. Some applications that we built, the GeoSolutions that are using either WPS or SQL views or both. First example, the soil monitor. It's a pure local WPS. So the soil monitor, first let me take a step back. In WPS, processes are provided with your server. We have like 80 simple processes already available. But you can write your own and plug your own. And this is what we normally do when we have a specific customer project. We build our own WPS processes. In this case, we had to compute at the Italy level some indices, some processing of the soil ceiling and a change of matrix in terms of land use. So this is a heavy raster computation. To accelerate to this one, we use the J-Cuda to integrate the GeoServer WPS with the graphic card and speed up the computation. Doing it is possible. Doing it is often not trivial because you basically have to take an entire large image, throw it at the graphic card, and make sure that you do all the steps of the computation within the graphic card before coming back. If you try to start to do it back and forth and doing it in steps, the graphic card is actually going to be slower. But if you do it right, it's fast. So we had to compute a number of soil ceiling algorithms, all calculated with J-Cuda. This is an example of a change of matrix. So I have two raster maps with the land use in two different years. And the matrix shows me how much of the water bodies became agricultural land and so on. Of course, I got a bunch of zeros, but if I look at agricultural areas, then I can see that some of them became artificial surfaces over time. And if I choose a particular type of soil, I can also build a chart of where the land, of how the land transformed over time in other types. So all of this is done via WPS, as I said, most of the heavy computation is done with J-Cuda. We do also some bits in Java to perform the final aggregation and visualization. All these processes are running asynchronously, because even with J-Cuda, they take time. So in the client, we also built a visualization of the processes that are running when they started, how far along they are, and so on. So you can track each computation. Another example, completely different, this one. This one is pure SQL user, so not WPS involved. It's the Tuna Atlas from FAO. In this case, we have a large database. Each cell contains the catchment of tunas classified by species and by the technique used to fish them. And we have an historical perspective on this data, so we have a time dimension, quarter by quarter for a number of years. And with this user interface, you can build a map, choosing, filtering the type of fish, the type of fishing technique, and so on, and get a distribution map as a result. What powers this map is a very simple query that we are running in Oracle, in this case. And as you can see, there are a few parameters in it, they are the ones between percentage signs. One of them is the actual aggregation function, that op percentage op, which allows us to do average sum on the fly. Of course, we define the regular expressions to make sure that we cannot be attacked. So for example, for the op, the default is sum, and the regular expression says it's either AVG or sum. And it works fine, it's processing on the fly without WPS. In this project, we also created the animator tool, which allows us to specify a certain number of years and quarters and get back an animated gif of these maps. So it shows evolution over time. So this is one example of the URL calling the animator. We are specifying the view param here TA, and then its values, and each value will generate a frame. This is another interesting example, this is another pure WPS example, in which case, in this case, we are doing just downloading. So you might say, wait, wait a second, WFS and WCS are meant for raw data extraction, so why are you not using those protocols? Well for a very simple reason, these extractions can take time, because we are talking about extracting hundreds of megabytes of data, if not more, so we cannot just wait for the WCS or the WPS to do their merry job and get us back the data, the HTTP request would expire. So instead we have created a process and we leverage WPS asynchronous calls to do the large extraction and get back the data to the client in a more manageable way, and of course we can ensure that the data gets back to the client. This works for backdoor layers, it works for raster layers, you can find it in the community section of GeoServer, so it's not part of the releases, but if you check the nightly builds you'll find it, you can do clipping, this is a user interface on top of the process, it's using the buffer process to depict a buffering area, if you define one in the UI, like you can say, okay, I'm going to draw a polygon or a line and then I want to buffer it and then give me the clip inside the buffer, and it's possible to track the download status, again via async WPS, and this is more or less the structure of the system, so we have an app store at the front, it fetches the list of layers from the WMS get capabilities, and then it can call buffer to do the buffering, it calls a process called download estimator because we have limits on how much data you can extract, and via get status it gets to know how far along we are. Another interesting example, this one, it's pure WPS, but it's against remote processes, so processes that are not run locally but on another machine, typical case scientific data processing, you have someone that wrote a Python, Octave, MATLAB, whatever procedure to do heavy processing on the data, it's meant to be run on another machine, not the WPS one, you might have a cluster in between and so on, so we put together another community module that you can find, which is called WPS remote, by which a remote Python or command line tool can be invoked, it uses XMPP as the communication method between the remote process and GeoServer, XMPP is a protocol thought thought out for charts, but it works very well for this case as well, and I have some sequence diagrams, but basically the idea is that you can stand up a new processing node, it will register to the chatroom, GeoServer will recognize this, will fetch the processes that the new node can run and then expose them as WPS processes on the web, when they are called, it will pass all the parameters down, track the execution and eventually get back the results via some shared file system, so the idea is that your GeoServer data directory is shared on the file system somewhere, and well, this is one example of change detection and core registration algorithms that we are running off another machine. Sometimes it's best to do both, so sometimes you have to run both WPS and SQL views, this is a project in which we have to calculate the vulnerability of people and the environment against accidents involving transport of dangerous goods like I don't know, liquid oxygen, petrol, gases and so on. So you can imagine there is a large number of layers, there is a large number of tiny segments throughout, because for each segment every 500 meter segment, we know how likely it is to have a car accident in there. And then we have some buffer distances depending on the kind of goods you transport, a different area is computed and we actually have 51 buffer distances for each and every segment and we have millions and millions of segments on the map. The risk formula is really, really complicated and it's so complicated that actually some parts of it have a meaning of their own, so you can compute it all or you can compute part of it and it has like, I don't know, 20, 30 parameters that you can set up in the client. Visually the result looks like a rendering transformation, so depending on the zoom level we display the result either as a faster grid or if we are close enough to the ground we display the single segments showing the probability, sorry, the vulnerability of the target in that segment, so as you can see some are red, so very vulnerable. How do we compute this very efficiently given the large number of data and the large number of dynamic parameters? We cannot compute all on the fly, we cannot compute all with SQL views because there are too many combinations, we cannot compute everything in Java because there is too much data, so what do we do? We mix and match. So the parametric queries are actually stored in a database and we compose them like a Lego kit and there's a WPS process that builds on the fly the right parametric view and runs it and we have a pre-processed a number of, so part of the computation can actually be pre-processed, not all of it, but we pre-processed as much as we could and the result is that we compute as efficiently as possible in the database on the fly, driven by a WPS process but most of the actual calculation is done by the database. In the database we also do cross-layer filtering, so let's find me whatever intersects these features in another layer and yeah, we also had to work a bit on computing 51 different buffer distances on top of so many layers. This one I'm going to skip, it's not really adding much to the presentation and so this is the end. Thank you. Some questions from the room? Is there any configurable timeout until which the results of the processes are kept? So if you look into your server 2A29, sorry the current stable and maintenance, you will find a maximum execution time which is the total of queuing and running. If you look into your server 210 which is going to be released in October, you will actually find separate controls for maximum queuing time and maximum execution time. So in WPS we have limits for pretty much everything, so not just computation but you can also enable and disable processes and then you can go in the process and say, okay, this geometry cannot be more than 10 megabytes and this value which is a number of contours cannot go beyond 100 and so on and so on. So you can control a bit how much CPU and resources you're going to use. GPU processing, are you using for visualization or for computation? We are using it for computation. This one is actually computing the change matrices and the soils feeling so it's going from data to data, not data to visualization. Actually the last part of the visualization we do with this library called JFO that allows us to apply some raster algebra on the fly and give us a nice output to display. Anything else? Apparently it was all clear. Even I don't have a question. Okay, thank you. Let's wait another five minutes for the next speaker. Johanna, are you already here? Ah, you're there. Thank you.
 So, Andrea is going to present some work on WPS, which actually started back then in  that code sprint.  Yes.  You were working on that, yeah.  And SQL views.  We have 20 minutes, then five minutes for presentations.  Okay, so, processing data in GeoServer with WPS on SQL views.  As you already know, my name is Andre Aime.  I work for Geosolutions.  It's a company based in Italy.  We provide support for GeoServer, GeoTools, GeoNetwork and so on.  And not just support for use, we are actually core developers in each and every of these  projects.  Meaning, we can push changes into them and improve them, and we do so regularly.  So today's presentation is about, well, WPS and web mapping.  So many years ago, doing web mapping basically meant to push a map on the net, do some styling  and maybe some editing, maybe some PDF printing, and that was most, all of it.  Since a few years ago, it's almost impossible for Geosolutions to make a web application  without having some processing into it.  Most of the new applications we make are not just mere visualization and data instruction  tools, but they are actually providing some capability in terms of processing.  So this presentation is about showing how we use GeoServer WPS to power several types  of applications.  So first, some quick reminders about WPS.  WPS stands for Web Processing Service.  It's the OGC way to expose for a change, not data, but processes to the web.  And the web can then provide the data.  The WPS does the computation and provides back results.  Simple example here, applying a buffer to a line.  I have the line which is an input.  I invoke a buffer asking for a distance of two, whatever, two meters maybe, and I get  back a buffer geometry.  This is sort of the simplest example I can think that's also Geospatial.  WPS can do also non-Geospatial calls like I could write an L award process if I want  to, but wouldn't be very meaningful.  WPS is one of the few OGC protocols that supports asynchronous requests, which is very important  for a number of cases, and we are going to see some of them.  So in most OGC protocols, you make a synchronous request.  You send an HTTP request to the server and you wait for the request to come back.  When it comes back, you get the answer, period, which is nice.  It's simple.  It doesn't work if you have to wait for minutes to get the request back because the HTTP connection  is going to rot in the meantime, probably get severed.  In a synchronous, you send a request.  You get back right away a response that says, okay, I took care of that request.  I'm going to process it and here is a URL that you can pull to verify how far along  I am.  Maybe you pull it.  It's queued.  It's queued.  It started 10%, 50%, 90%.  Oh, look, here is the result.  The common WPS setup, well, the basic one assumes that the WPS has no data, no local data, and  it's going to fetch it from other OGC services or from random HTTP server calls.  It's going to fetch the data, process it, and then return it back to the client, which  is a sort of limiting if you have to play with the very large amounts of data.  In GUServer, the WPS is integrated in an ecosystem.  GUServer has its own local layers, has its own local services, and so on.  The WPS can play in this ecosystem.  So in GUServer, the WPS, you can fetch data from local layers just by using their names  instead of passing around the data.  There is a nice integration with WMS with rendering transformations, which are a way  to put in your style a directive that will call to a WPS process before rendering the  data, so you can transform the data on the fly.  One example, contour extraction.  We have an integration with the GUServer UI, so we have a demo page to try out the WPS  request, and so on.  So we got a bit more connections in our WPS than normal.  This is the demo request builder.  I'm not going to spend time on it.  It's not particularly interesting.  Rendering transformation, as I said, one example of, as I said, applying a transformation  on the fly while we render stuff so that we don't have to keep 10, 15, 100 versions of  the same data processed in a different way.  We just always do it on the fly.  The rendering transformation are particularly optimized in such a way that they only process  the area that's visible in the current get map request and only at the resolution requested.  So we never work at the native resolution.  If you are looking at a giant digital elevation model of the entire world at 10 meters, when  you look at it, you are looking at it at, I don't know, 30 kilometers per pixel, and  that's the resolution we use to extract the contour line for that zoom level.  That makes for fast extraction.  It gives us the best of both worlds.  So before we dive into WPS, let's take one step back to the processing you don't always  need the WPS.  There are spatial DBMSs that you can use.  Spatial DBMSs such as post-GIS can do computation on the fly in SQL.  It's pretty efficient.  It has all the data locally.  It can do several type of computations.  So why not leverage it?  And the answer is, well, if it fits your purpose, do it.  In GeoServer, we have a notion of parametric SQL view.  So the normal SQL view would be that instead of pointing GeoServer to a table, you give  GeoServer an SQL statement to run as the data source.  And with that, you can already do some processing.  What makes it more interesting is that in that SQL, I can embed parameters that will  come from the client, from the web, to control how the computation is done.  Of course, you have to protect yourself against SQL injection attacks.  So we have some validation going on.  But generally speaking, if your data is only in a spatial database and you can express  your processing as a query, maybe with some parameters to control it, by all means, do  your processing this way.  It's probably one of the most efficient ways to do it.  It's not always the best.  I'm going to show you some cases in which different approaches are required.  This is an example of a query that builds using a steam acline lines out of sets of  points over time.  So let's have a look at some examples.  Some applications that we built, the GeoSolutions that are using either WPS or SQL views or  both.  First example, the soil monitor.  It's a pure local WPS.  So the soil monitor, first let me take a step back.  In WPS, processes are provided with your server.  We have like 80 simple processes already available.  But you can write your own and plug your own.  And this is what we normally do when we have a specific customer project.  We build our own WPS processes.  In this case, we had to compute at the Italy level some indices, some processing of the  soil ceiling and a change of matrix in terms of land use.  So this is a heavy raster computation.  To accelerate to this one, we use the J-Cuda to integrate the GeoServer WPS with the graphic  card and speed up the computation.  Doing it is possible.  Doing it is often not trivial because you basically have to take an entire large image,  throw it at the graphic card, and make sure that you do all the steps of the computation  within the graphic card before coming back.  If you try to start to do it back and forth and doing it in steps, the graphic card is  actually going to be slower.  But if you do it right, it's fast.  So we had to compute a number of soil ceiling algorithms, all calculated with J-Cuda.  This is an example of a change of matrix.  So I have two raster maps with the land use in two different years.  And the matrix shows me how much of the water bodies became agricultural land and so on.  Of course, I got a bunch of zeros, but if I look at agricultural areas, then I can see  that some of them became artificial surfaces over time.  And if I choose a particular type of soil, I can also build a chart of where the land,  of how the land transformed over time in other types.  So all of this is done via WPS, as I said, most of the heavy computation is done with  J-Cuda.  We do also some bits in Java to perform the final aggregation and visualization.  All these processes are running asynchronously, because even with J-Cuda, they take time.  So in the client, we also built a visualization of the processes that are running when they  started, how far along they are, and so on.  So you can track each computation.  Another example, completely different, this one.  This one is pure SQL user, so not WPS involved.  It's the Tuna Atlas from FAO.  In this case, we have a large database.  Each cell contains the catchment of tunas classified by species and by the technique used to fish  them.  And we have an historical perspective on this data, so we have a time dimension, quarter  by quarter for a number of years.  And with this user interface, you can build a map, choosing, filtering the type of fish,  the type of fishing technique, and so on, and get a distribution map as a result.  What powers this map is a very simple query that we are running in Oracle, in this case.  And as you can see, there are a few parameters in it, they are the ones between percentage  signs.  One of them is the actual aggregation function, that op percentage op, which allows us to  do average sum on the fly.  Of course, we define the regular expressions to make sure that we cannot be attacked.  So for example, for the op, the default is sum, and the regular expression says it's  either AVG or sum.  And it works fine, it's processing on the fly without WPS.  In this project, we also created the animator tool, which allows us to specify a certain  number of years and quarters and get back an animated gif of these maps.  So it shows evolution over time.  So this is one example of the URL calling the animator.  We are specifying the view param here TA, and then its values, and each value will generate  a frame.  This is another interesting example, this is another pure WPS example, in which case,  in this case, we are doing just downloading.  So you might say, wait, wait a second, WFS and WCS are meant for raw data extraction,  so why are you not using those protocols?  Well for a very simple reason, these extractions can take time, because we are talking about  extracting hundreds of megabytes of data, if not more, so we cannot just wait for the  WCS or the WPS to do their merry job and get us back the data, the HTTP request would  expire.  So instead we have created a process and we leverage WPS asynchronous calls to do the  large extraction and get back the data to the client in a more manageable way, and of  course we can ensure that the data gets back to the client.  This works for backdoor layers, it works for raster layers, you can find it in the community  section of GeoServer, so it's not part of the releases, but if you check the nightly  builds you'll find it, you can do clipping, this is a user interface on top of the process,  it's using the buffer process to depict a buffering area, if you define one in the UI,  like you can say, okay, I'm going to draw a polygon or a line and then I want to buffer  it and then give me the clip inside the buffer, and it's possible to track the download status,  again via async WPS, and this is more or less the structure of the system, so we have an  app store at the front, it fetches the list of layers from the WMS get capabilities, and  then it can call buffer to do the buffering, it calls a process called download estimator  because we have limits on how much data you can extract, and via get status it gets to  know how far along we are.  Another interesting example, this one, it's pure WPS, but it's against remote processes,  so processes that are not run locally but on another machine, typical case scientific  data processing, you have someone that wrote a Python, Octave, MATLAB, whatever procedure  to do heavy processing on the data, it's meant to be run on another machine, not the WPS  one, you might have a cluster in between and so on, so we put together another community  module that you can find, which is called WPS remote, by which a remote Python or command  line tool can be invoked, it uses XMPP as the communication method between the remote  process and GeoServer, XMPP is a protocol thought thought out for charts, but it works  very well for this case as well, and I have some sequence diagrams, but basically the  idea is that you can stand up a new processing node, it will register to the chatroom, GeoServer  will recognize this, will fetch the processes that the new node can run and then expose  them as WPS processes on the web, when they are called, it will pass all the parameters  down, track the execution and eventually get back the results via some shared file system,  so the idea is that your GeoServer data directory is shared on the file system somewhere, and  well, this is one example of change detection and core registration algorithms that we are  running off another machine. Sometimes it's best to do both, so sometimes you have to  run both WPS and SQL views, this is a project in which we have to calculate the vulnerability  of people and the environment against accidents involving transport of dangerous goods like  I don't know, liquid oxygen, petrol, gases and so on. So you can imagine there is a large  number of layers, there is a large number of tiny segments throughout, because for each  segment every 500 meter segment, we know how likely it is to have a car accident in there.  And then we have some buffer distances depending on the kind of goods you transport, a different  area is computed and we actually have 51 buffer distances for each and every segment and we  have millions and millions of segments on the map. The risk formula is really, really  complicated and it's so complicated that actually some parts of it have a meaning of their own,  so you can compute it all or you can compute part of it and it has like, I don't know,  20, 30 parameters that you can set up in the client.  Visually the result looks like a rendering transformation, so depending on the zoom level  we display the result either as a faster grid or if we are close enough to the ground we  display the single segments showing the probability, sorry, the vulnerability of the target in  that segment, so as you can see some are red, so very vulnerable.  How do we compute this very efficiently given the large number of data and the large number  of dynamic parameters? We cannot compute all on the fly, we cannot compute all with SQL  views because there are too many combinations, we cannot compute everything in Java because  there is too much data, so what do we do? We mix and match.  So the parametric queries are actually stored in a database and we compose them like a  Lego kit and there's a WPS process that builds on the fly the right parametric view and runs  it and we have a pre-processed a number of, so part of the computation can actually be  pre-processed, not all of it, but we pre-processed as much as we could and the result is that  we compute as efficiently as possible in the database on the fly, driven by a WPS process  but most of the actual calculation is done by the database.  In the database we also do cross-layer filtering, so let's find me whatever intersects these  features in another layer and yeah, we also had to work a bit on computing 51 different  buffer distances on top of so many layers. This one I'm going to skip, it's not really  adding much to the presentation and so this is the end.  Thank you. Some questions from the room? Is there any configurable timeout until which  the results of the processes are kept?  So if you look into your server 2A29, sorry the current stable and maintenance, you will  find a maximum execution time which is the total of queuing and running. If you look  into your server 210 which is going to be released in October, you will actually find  separate controls for maximum queuing time and maximum execution time.  So in WPS we have limits for pretty much everything, so not just computation but you  can also enable and disable processes and then you can go in the process and say, okay,  this geometry cannot be more than 10 megabytes and this value which is a number of contours  cannot go beyond 100 and so on and so on. So you can control a bit how much CPU and  resources you're going to use.  GPU processing, are you using for visualization or for computation?  We are using it for computation. This one is actually computing the change matrices  and the soils feeling so it's going from data to data, not data to visualization. Actually  the last part of the visualization we do with this library called JFO that allows us to  apply some raster algebra on the fly and give us a nice output to display. Anything else?  Apparently it was all clear. Even I don't have a question. Okay, thank you. Let's wait  another five minutes for the next speaker. Johanna, are you already here?  Ah, you're there.  Thank you.
foss4g-2016-1093-crunching_data_in_geoserver_mastering_rendering_transformations_wps_processes_and_s_0_215.png foss4g-2016-1093-crunching_data_in_geoserver_mastering_rendering_transformations_wps_processes_and_s_216_323.png foss4g-2016-1093-crunching_data_in_geoserver_mastering_rendering_transformations_wps_processes_and_s_324_707.png foss4g-2016-1093-crunching_data_in_geoserver_mastering_rendering_transformations_wps_processes_and_s_708_791.png foss4g-2016-1093-crunching_data_in_geoserver_mastering_rendering_transformations_wps_processes_and_s_792_839.png foss4g-2016-1093-crunching_data_in_geoserver_mastering_rendering_transformations_wps_processes_and_s_840_3359.png foss4g-2016-1093-crunching_data_in_geoserver_mastering_rendering_transformations_wps_processes_and_s_3360_11639.png foss4g-2016-1093-crunching_data_in_geoserver_mastering_rendering_transformations_wps_processes_and_s_11640_15011.png foss4g-2016-1093-crunching_data_in_geoserver_mastering_rendering_transformations_wps_processes_and_s_15012_19451.png foss4g-2016-1093-crunching_data_in_geoserver_mastering_rendering_transformations_wps_processes_and_s_19452_24875.png foss4g-2016-1093-crunching_data_in_geoserver_mastering_rendering_transformations_wps_processes_and_s_24876_25967.png foss4g-2016-1093-crunching_data_in_geoserver_mastering_rendering_transformations_wps_processes_and_s_25968_30011.png foss4g-2016-1093-crunching_data_in_geoserver_mastering_rendering_transformations_wps_processes_and_s_30012_30323.png foss4g-2016-1093-crunching_data_in_geoserver_mastering_rendering_transformations_wps_processes_and_s_30324_30815.png foss4g-2016-1093-crunching_data_in_geoserver_mastering_rendering_transformations_wps_processes_and_s_30816_30899.png foss4g-2016-1093-crunching_data_in_geoserver_mastering_rendering_transformations_wps_processes_and_s_30900_31367.png foss4g-2016-1093-crunching_data_in_geoserver_mastering_rendering_transformations_wps_processes_and_s_31368_32087.png foss4g-2016-1093-crunching_data_in_geoserver_mastering_rendering_transformations_wps_processes_and_s_32088_32195.png foss4g-2016-1093-crunching_data_in_geoserver_mastering_rendering_transformations_wps_processes_and_s_32196_32339.png foss4g-2016-1093-crunching_data_in_geoserver_mastering_rendering_transformations_wps_processes_and_s_32340_33701.png