One Geonode, many Geonodes
Allegri, Giovanni
Fabiani, Allessio
GeoSolutions has been involved in a number of projects, ranging from local administrations to global institutions, involving GeoNode deployments, customizations and enhancements. A gallery of projects and use cases will showcase the versatility and effectiveness of GeoNode, both as a standalone application and as a service component, for building secured geodata catalogs and web mapping services. GeoNode is a Web Spatial Content Management System based entirely on Open Source tools whose purpose is to promote the sharing of data and their management in a simple environment where even non-expert users of GIS technologies can view, edit, manage, and share spatial data, maps, prints, and documents attached. GeoNode was initiated in 2009 by the World Bank and OpenGeo but from 2011 is entirely run by the developer community that the project has been able to attract. It claims some large organizations among its contributors such as the United Nations, the World Bank and the European Commission as well as many NGOs and private companies. GeoNode is based on a set of robust and widespread open source components as Django as a basic framework, GeoServer for geospatial data management and OGC services and MapStore as mapping application. It can also communicate with PostgreSQL for vector data management. GeoSolutions has been involved in a number of projects, ranging from local administrations to global institutions, involving GeoNode deployments, customizations and enhancements. A gallery of projects and use cases will showcase the versatility and effectiveness of GeoNode, both as a standalone application and as a service component, for building secured geodata catalogs and web mapping services. Lastly, ongoing and future developments will be presented ranging from the upcoming integration with MapStore to the monitoring and analytics dashboard or the support for time series data. Authors and Affiliations – giovanni.allegri@geo-solutions.it alessio.fabiani@geo-solutions.it Track – Use cases & applications Topic – Software/Project development Level – 1 - Principiants. No required specific knowledge is needed. Language of the Presentation – English
 I'm hearing several sounds. Sorry for this. Yeah, welcome everyone. This morning's session and we'll look in real world application and usage of maybe OSGeo software. And without further ado, our first speaker is Giovanni Allegri. He's from the beautiful Tuscany, Italy. He works at Geosolutions Group as an architect and product manager and he's known under his username Geohappy. And he's in the GeoNode project steering, I like the username. GeoNode project steering committee and a long time contributor and GeoNode, by the way, is a, or I should say the open source geospatial content management system. And Giovanni will take us through a gallery of projects and use cases to showcase the versatility and effectiveness of GeoNode. So Giovanni, the floor is yours. Okay, thanks, Joss. Hello everybody. And yep, the introduction was done by Joss. So I'm the product manager in Geosolutions for GeoNode. So in this presentation, I would like to share some cases where GeoNode has been customized, adapted and bent to specific requirements. So you know, GeoNode, well, this is our company, which is a core maintainer of GeoNode, beyond my store, just ever and so on. We are working hard. We have quite a big team on GeoNode. And so our experience in GeoNode has been wide in these five, six years we've been working with it. As anybody, we started with one GeoNode, which is the one that you find in the releases that you find inside the main repository. So the one GeoNode is a so-called vanilla GeoNode, which is the core of GeoNode, which has everything that is needed. It's the Django application that provides all the functionalities and services for GeoNode. I think, well, I will go quickly through the features of GeoNode. I think many of you already know it, so I won't spend much time on these. But it's a content management system for just partial datasets, including some documents, media assets that let you compose applications on top of this data. But the core is sharing, collecting and using these data in many different ways. It's open source, yes, it's open source license. And well, it's a well-established platform with a mature set of libraries where GeoNode uses lots of the GeoNode and open source, your special software. It's built on top of Django, so it's Python application. And this is a platform that is targeting many use cases, both for users, administrators, but also developers. So developers are welcome into GeoNode because it can be easily extended. From the beginning, GeoNode was designed to be as open as possible to additions, extensions, customizations. This is provided by the Django platform itself. I mean, it's a framework with a lot of facilities to extend and integrate additional functionalities. And GeoNode inherits all these capabilities from Django. Currently, Django is a suite of services. This is just the main ones. So it's a Django application which provides by itself a client which is built on MapStore, which is a framework for potential solutions, and React. MapStore is built on top of React. Behind the scenes, we have just server which provides the OJC services on top of Django. We have PyCSW, and we have PostGIS and PostgreSQL and the GDAL libraries for all the processing behind the scenes. So there's in general, when we deploy it, we have other services too, but mainly these are the main components. So in a very quick overview of the workflow, we have files, remote services, remote files, which is a work in progress, but it's in a good shape already. So any kind of resource, be it a document or a special layer, can be imported or uploaded into GeoNode, either as a local resource. So you physically copy the data into GeoNode, and it will be stored as a file system stored or PostGIS database data. Or in case of remote services, you have situations where the data is referring to the remote resource. So with the local data, the data set and the documents are ready to be used to build applications on top of them, or to be used, it's not mentioned here, but of course, when the data inside GeoNode are ready to be used as OJC services directly, CSW services. So the catalog already provides the data sets and all the metadata for the data sets. But you can go on and build other applications on top of these base resources, these resources, which are maps, GeoStories, dashboards, and whatever other GeoApp. GeoStories and dashboards are GeoApps. So this is a concept which is generic in GeoNode. So any other module can implement a specific job. So GeoStories and dashboards, for example, are GeoApps implementations provided by the so-called MapStore client application, which is the one that provides also the new client, the client to GeoNode. It provides the client, the default client, the front-end application, but it also provides these implementations for two kinds of GeoApps. GeoStories and dashboards are already available in the 3.3x branch, the development branch of the series 3 of GeoNode. So at the end, you can use this data, both the the resources and the applications built on top of the resources as OJC services through Arrest API, or you can embed because all these resources provide a view, a way to be viewed inside third-party HTML application to HTML pages, so it has embedded viewers. So as you see, beyond being a management platform, so where you can manage permissions, you can manage users, people, you can manage workflows, publishing workflows, authorize, approval workflows. In the end, for the end users or the developers, it's a platform that can provide all the kind of services that you might need from a third-party app. This is the core of GeoNode, but on top of this core, on top of these capabilities, often we need to build custom applications. And we have a large experience on this. GeoNode by itself cannot address all use cases, of course. So the general approach is to wrap GeoNode inside the so-called GeoNode project. So a GeoNode project is a container, is a Django project, which contains GeoNode as an app. We have the so-called the GeoNode project repository, which is a template, a GeoNode project. With a command coming from Django, you can materialize this project and so build, generate a project like, you know, if you are from React, you know, you have generators for create React app and so on. So it's a generator, okay, we have a generator that creates a project and with the right domain, the name of the project and so on. So it's a custom Django app. With this app, you can follow all the patterns provided by Django. So you can use the overloading of templates, you can make extensions to the modus, you can even include apps that are your own apps that either interact or not with GeoNode. So you can create your Django project bundled with GeoNode itself. And we did it several times. I mean, to say the truth, the GeoNode project is the way we deploy GeoNode always. So we never deploy GeoNode vanilla, we always deploy a GeoNode project instance. Even the demo that you can see online, the stable demo, the development demo, they are GeoNode projects. So from the past, we have, you see, these are old projects, but I mean, it's a quick overview of some examples of the customizations. You will see here, you have a view that is not from GeoNode. We have buttons, actions, tabs, views that are not provided by GeoNode, they are provided by the custom application. And but they are integrated both functionally and visually integrated into GeoNode. So you see in the top and the bottom, you see this, it's a GeoNode. For UNESCO, we started the work that is being the first test to review the homepage for GeoNode and all layouts of GeoNode. So you see a grid system, a grid of cards in the homepage. And this is what you will see in the master branch of GeoNode now. So also in this case, this is a GeoNode 3, but with a custom homepage and with a custom react application that drives this homepage. But all the rest is other templates and the Chang of views that you know from GeoNode. In this case, we completely changed also the UI, so you cannot say that it's GeoNode if you don't know it. But behind the scenes, it's GeoNode. So only the back end is GeoNode and the front end is completely custom. And for this case, for GFDRR, this is a client built on top of Map Store client, but with the custom table of contents, custom explorers of data and the histogram charts. So as you see, I mean, with the infrastructure provided by the Django framework, you have the freedom to do whatever you want, I mean, extending, replacing, back end and front end. Okay, and just keep what you need in the end. This is another example where we have also changed the filtering on the side, the facets, filtering in a custom template. So we have added filtering tabs that are not available in a standard GeoNode. And with new menus on the top, some of these customizations are available from the Django admin. So you can change the logo, you can change the main color of the web of GeoNode directly from the Django administration. So without having to change the templates or the source code, of course, these are just the basic changes that you can do. If you want to do more, we will see later there are more advanced ways to do that. Next to platform is the current, I mean, it's a client for us, a GF solutions client. And this has given us the opportunity to start the GeoNode master branch. So what will become the four series of GeoNode? And it's a complete refactoring of the front end and of some important pieces and components of the back end. The storage system, the resource management system, the remote services system. So all these services have been completely refactored. The UI has been optimized a lot. It's a mix of single page application and Django templates. I will show you briefly. And we have reduced a lot the number of clicks to perform the usual actions on resources. You have quick previews of resources without having to dig into the hierarchy of resources. So bring your own GeoNode. So that's what I was saying. You have a GeoNode project. You have a GeoNode Django app. You can put any app that you want behind. And then this is a MapStore client. The MapStore client is exactly an app inside the Django project, which provides the client, the MapStore front end client, which is the default client for GeoNode now. It provides its own REST API. And this is used, for example, for the dashboards and GeoStories resources that I was showing before. And it interacts with GeoNode. So you see that if you want to change the back end of the front end, you can just take away MapStore and redo it as you prefer. I mean, you have everything to manage GeoNode through REST API and so on. So from the point of view of customizing GeoNode, what are the objectives for the next major versions? We want to improve the uploaded storage. And this is a work in progress. Resource cloning, meaning versioning of resources, is already done. We have abstract map, big engine. So GeoNode, just ever is an abstract element now. We have a harvester and extended permission systems and so on. But what I really want to say now is that you have a new SP client, custom templates, support and an extended REST API. The REST API v2 is almost complete and it really gives you the ability to interact however you want with GeoNode, both for the, for viewing resources, searching resources, but also managing GeoNode itself, if you have, of course, the credentials to do that. And most of these is already available to test the master branch. So yeah, it's in a good shape. But we have a brand new front end with the React, with everything, all the tool set coming from Map Store. The home page, SP Refactor, we have a single page with infinite scrolling, which works also as a workspace for users where you can manage your own resources. We have a single view of the resource. So without, it's an editor, which is the viewer, full screen viewer of any resource, just partial or document or whatever. And it's also an editor if you have the permissions. And the back office is, well, we are, for the moment, we are reusing the legacy pages, even though integrated, visually integrated with the new styling, the new front end style. And we are, I mean, during the next months and next years, we will probably transition all the back office to the new front end. One of the things that have been discussed with the community was the ability to maintain the ability for developers to use Django templates, because not everybody is able to work with React or wants to work with React. Oh, maybe they already have a lot of custom applications and it's not feasible to port these applications to a JavaScript client, a React client. So we did, we reworked the architecture of the front end so that now you can mix React clients, your own React components with standard old Django apps. So there's a template, a base template that is wrapping both the React client and the old Django templates here. So you have the best of the two worlds. Even it's a bit strange. I mean, someone doesn't like these kind of hybrid approaches, but this is the best of the two worlds in this moment. So we can support any scenario and any context. So if you don't want to use React client, you can go on with the standard Django templates. No problem. We have broken the standard, the Django templates into snippets, very granular snippets, so that you can change the single pieces of the templates and you can work on the styling of various in a granular way. So you can just override this custom or provide your custom theme and you can change any single piece of these snippets. You can also the configuration of the client has been made overriding. So you have many ways to provide this configuration from static JavaScript, template, settings, whatever, and everything is merged dynamically. So you can have many channels to configure your application or provide custom configurations to your application. And this is an example. I won't dig into the details, but I mean, the documentation will tell you all of this. So the future, well, we will work on enforcing much more the privacy and provide the privacy API to custom applications in a better, simpler way. And also we have the ability to provide dynamically map store plugins inside the client, so without having to bundling custom plugins into the map store bundle. So you can create plugins. We have an example. I will show you here. I will go fast forward because I see that time is passing. This is a custom map store plugin for meteorology of data. And this has been put into the application without having to rebundle the map store client. So it's just a simple plugin, an extension. It uses a map store extension concept to bundle your own plugin. And the other thing that I was saying, yes, other big changes, the dataset style editor, but I think it, I mean, I can skip these. I mean, it's more about new ways to style your resources in an efficient way. I don't know if I have more time. I mean, I have really gone fast over the presentation, but I don't know. Yeah. Okay. Okay. I will go to the end. So the future, this is not a work in progress right now. We want to extend the permission system for styles and data exports, because this is really important to provide security on top also of the styles and the data exports, because I mean, every context has its policies for on these things. And this is not strong enough. I mean, you have a permission system, but it's quite hidden. So you don't have the means to control it easily. Completely support for non default, just partial, worst basis on just ever. So you can compartmentize, you can already do it, but we are improving that to the compartment compartmentization of data on the back end services. And then also we are planning to work on a new roles management on just ever, which can pool the rules from external services, so an authorization service that can provide the rules to just ever services. So improve also the integration inside multi services infrastructure with custom policies. So you just have to provide the permissions for Geofence and just ever as they understand them, but the way you build these rules is up to you. So you have the freedom to even beyond what John O'Donnell does. Yeah, we have data sharding, we have back end services. This is what I was saying before, users and group partitioning. We already have all these concepts, but in most complex scenarios, if in particular what someone calls the multi tenancy scenarios, maybe John O'Donnell is not ready to be used in a multi tenancy environment or to provide multi tenancy services. You can get there with some effort, you can more or less have it, but it's probably not the right way to do that. So probably the best way is to deploy multiple genode nodes and make them share with single sign on, shared authentication, authorization services, share just ever with data sharding and so on. And maybe you get better results. So by the way, many of these improvements are only ideas for the moment, because I mean of course they are ideas that are coming from our experience on deploying genode, even in complex and enterprise level scenarios. And so we have the pieces, even if they're not built in right to be used in genode. Of course, these customization, the way you deploy the customizations that you want to deploy, including secrets, including customizations to the services, I mean services like the salary service, which is the broker of the task manager for the synchronous task manager, all the way you want to expose just ever through NGINX. You might want to change this. So this is doable because the genode project provides all the Docker files and the Docker images that you can tweak to your special needs. And that's what we do. We leverage in our deployment custom Docker overrides and Docker images. This is the way to go and this is the way we are improving. Okay, thank you Giovanni. Yeah, for the sake of time keeping and there's some questions still. Thank you very much. I'm very impressed each year with how genode progresses. I see there are at least two questions. We have two minutes so that you can do so here I put it on screen and I read it for listeners is due server always required for genode deployment. Can you also use map server instead of server? At the moment, yes, I mean, just every is the only one. But the architecture is open to other back-end implementations but they must be implemented. Okay, because you recently switched from let's say to your network to PyCSW for instance? I understood. Yeah, also geo network was removed. The support for geo network was removed from the master branch because there wasn't enough maintenance resources for it. So by the way, in both cases the architecture still supports implementing custom back-ends for the server. Okay, that's good to hear. Let's have one last question. We've heard about geo storage but can it also be created via the geo node REST API? Yes, in particular not the genode REST API but the map store client REST APIs. So the map store client as I was showing before provides the REST APIs for this particular kind of geo app. So by the way, it's a very thin, very thin REST API. So I would say yes, I mean, the genode as you have it with the genode with map store client and so on provides the REST API to build geo storage and the dashboards. Okay, thank you very much. Yeah, we have to move on. Well, thanks again, Giovanni and I hope more people get inspired now with using geo nodes. Thanks.
 I'm hearing several sounds. Sorry for this. Yeah, welcome everyone. This morning's session  and we'll look in real world application and usage of maybe OSGeo software. And without  further ado, our first speaker is Giovanni Allegri. He's from the beautiful Tuscany,  Italy. He works at Geosolutions Group as an architect and product manager and he's known  under his username Geohappy. And he's in the GeoNode project steering, I like the username.  GeoNode project steering committee and a long time contributor and GeoNode, by the way, is a,  or I should say the open source geospatial content management system. And Giovanni will take us  through a gallery of projects and use cases to showcase the versatility and effectiveness of  GeoNode. So Giovanni, the floor is yours. Okay, thanks, Joss. Hello everybody. And yep, the introduction  was done by Joss. So I'm the product manager in Geosolutions for GeoNode. So in this presentation,  I would like to share some cases where GeoNode has been customized, adapted and bent to specific  requirements. So you know, GeoNode, well, this is our company, which is a core maintainer of  GeoNode, beyond my store, just ever and so on. We are working hard. We have quite a big team on  GeoNode. And so our experience in GeoNode has been wide in these five, six years we've been working  with it. As anybody, we started with one GeoNode, which is the one that you find in the releases  that you find inside the main repository. So the one GeoNode is a so-called vanilla GeoNode,  which is the core of GeoNode, which has everything that is needed. It's the Django application  that provides all the functionalities and services for GeoNode. I think, well, I will go quickly  through the features of GeoNode. I think many of you already know it, so I won't spend much time  on these. But it's a content management system for just partial datasets, including some documents,  media assets that let you compose applications on top of this data. But the core is sharing,  collecting and using these data in many different ways. It's open source, yes, it's open source  license. And well, it's a well-established platform with a mature set of libraries where  GeoNode uses lots of the GeoNode and open source, your special software. It's built on top of Django,  so it's Python application. And this is a platform that is targeting many use cases,  both for users, administrators, but also developers. So developers are welcome into  GeoNode because it can be easily extended. From the beginning, GeoNode was designed to be  as open as possible to additions, extensions, customizations. This is provided by the Django  platform itself. I mean, it's a framework with a lot of facilities to extend and integrate  additional functionalities. And GeoNode inherits all these capabilities from Django.  Currently, Django is a suite of services. This is just the main ones. So it's a Django application  which provides by itself a client which is built on MapStore, which is a framework for  potential solutions, and React. MapStore is built on top of React. Behind the scenes, we have just  server which provides the OJC services on top of Django. We have PyCSW, and we have PostGIS  and PostgreSQL and the GDAL libraries for all the processing behind the scenes. So there's  in general, when we deploy it, we have other services too, but mainly these are the main components.  So in a very quick overview of the workflow, we have files, remote services,  remote files, which is a work in progress, but it's in a good shape already. So any kind of  resource, be it a document or a special layer, can be imported or uploaded into GeoNode, either  as a local resource. So you physically copy the data into GeoNode, and it will be stored  as a file system stored or PostGIS database data. Or in case of remote services, you have  situations where the data is referring to the remote resource. So with the local data,  the data set and the documents are ready to be used to build applications on top of them,  or to be used, it's not mentioned here, but of course, when the data inside GeoNode are ready  to be used as OJC services directly, CSW services. So the catalog already provides the data sets and  all the metadata for the data sets. But you can go on and build other applications on top of these  base resources, these resources, which are maps, GeoStories, dashboards, and whatever other  GeoApp. GeoStories and dashboards are GeoApps. So this is a concept which is generic in GeoNode.  So any other module can implement a specific job. So GeoStories and dashboards, for example,  are GeoApps implementations provided by the so-called MapStore client application,  which is the one that provides also the new client, the client to GeoNode. It provides the  client, the default client, the front-end application, but it also provides these implementations  for two kinds of GeoApps. GeoStories and dashboards are already available in the 3.3x branch, the  development branch of the series 3 of GeoNode. So at the end, you can use this data, both the  the resources and the applications built on top of the resources as OJC services through  Arrest API, or you can embed because all these resources provide a view, a way to be viewed  inside third-party HTML application to HTML pages, so it has embedded viewers.  So as you see, beyond being a management platform, so where you can manage permissions,  you can manage users, people, you can manage workflows, publishing workflows,  authorize, approval workflows. In the end, for the end users or the developers, it's a platform  that can provide all the kind of services that you might need from a third-party app.  This is the core of GeoNode, but on top of this core, on top of these capabilities,  often we need to build custom applications. And we have a large experience on this.  GeoNode by itself cannot address all use cases, of course. So the general approach is to wrap  GeoNode inside the so-called GeoNode project. So a GeoNode project is a container,  is a Django project, which contains GeoNode as an app. We have the so-called the GeoNode project  repository, which is a template, a GeoNode project. With a command coming from Django,  you can materialize this project and so build, generate a project like, you know, if you are  from React, you know, you have generators for create React app and so on. So it's a generator,  okay, we have a generator that creates a project and with the right domain, the name of the project  and so on. So it's a custom Django app. With this app, you can follow all the patterns provided by  Django. So you can use the overloading of templates, you can make extensions to the modus, you can even  include apps that are your own apps that either interact or not with GeoNode. So you can create  your Django project bundled with GeoNode itself. And we did it several times. I mean, to say the  truth, the GeoNode project is the way we deploy GeoNode always. So we never deploy GeoNode vanilla,  we always deploy a GeoNode project instance. Even the demo that you can see online, the stable  demo, the development demo, they are GeoNode projects. So from the past, we have, you see,  these are old projects, but I mean, it's a quick overview of some examples of the customizations.  You will see here, you have a view that is not from GeoNode. We have buttons, actions, tabs,  views that are not provided by GeoNode, they are provided by the custom application.  And but they are integrated both functionally and visually integrated into  GeoNode. So you see in the top and the bottom, you see this, it's a GeoNode.  For UNESCO, we started the work that is being the first test to review the homepage  for GeoNode and all layouts of GeoNode. So you see a grid system, a grid of cards in the homepage.  And this is what you will see in the master branch of GeoNode now.  So also in this case, this is a GeoNode 3, but with a custom homepage and with a custom  react application that drives this homepage. But all the rest is other templates and the  Chang of views that you know from GeoNode. In this case, we completely changed also the UI,  so you cannot say that it's GeoNode if you don't know it. But behind the scenes, it's GeoNode.  So only the back end is GeoNode and the front end is completely custom.  And for this case, for GFDRR, this is a client built on top of Map Store client,  but with the custom table of contents, custom explorers of data and the histogram charts.  So as you see, I mean, with the infrastructure provided by the Django framework,  you have the freedom to do whatever you want, I mean, extending, replacing,  back end and front end. Okay, and just keep what you need in the end.  This is another example where we have also changed the filtering on the side, the facets,  filtering in a custom template. So we have added filtering tabs that are not available in a  standard GeoNode. And with new menus on the top, some of these customizations are available  from the Django admin. So you can change the logo, you can change the main color of the web  of GeoNode directly from the Django administration. So without having to change the templates or  the source code, of course, these are just the basic changes that you can do. If you want to do  more, we will see later there are more advanced ways to do that. Next to platform is the current,  I mean, it's a client for us, a GF solutions client. And this has given us the opportunity to start  the GeoNode master branch. So what will become the four series of GeoNode? And it's a complete  refactoring of the front end and of some important pieces and components of the back end.  The storage system, the resource management system, the remote services system. So all these  services have been completely refactored. The UI has been optimized a lot. It's a mix of single  page application and Django templates. I will show you briefly. And we have reduced a lot  the number of clicks to perform the usual actions on resources. You have quick previews of resources  without having to dig into the hierarchy of resources. So bring your own GeoNode. So that's  what I was saying. You have a GeoNode project. You have a GeoNode Django app. You can put any app  that you want behind. And then this is a MapStore client. The MapStore client is exactly an app  inside the Django project, which provides the client, the MapStore front end client,  which is the default client for GeoNode now. It provides its own REST API. And this is used,  for example, for the dashboards and GeoStories resources that I was showing before. And it  interacts with GeoNode. So you see that if you want to change the back end of the front end,  you can just take away MapStore and redo it as you prefer. I mean, you have everything to manage  GeoNode through REST API and so on. So from the point of view of customizing GeoNode, what are  the objectives for the next major versions? We want to improve the uploaded storage.  And this is a work in progress. Resource cloning, meaning versioning of resources, is already done.  We have abstract map, big engine. So GeoNode, just ever is an abstract element now. We have  a harvester and extended permission systems and so on. But what I really want to say now is that  you have a new SP client, custom templates, support and an extended REST API. The REST API v2  is almost complete and it really gives you the ability to interact however you want with  GeoNode, both for the, for viewing resources, searching resources, but also managing  GeoNode itself, if you have, of course, the credentials to do that. And most of these is  already available to test the master branch. So yeah, it's in a good shape.  But we have a brand new front end with the React, with everything, all the tool set coming from  Map Store. The home page, SP Refactor, we have a single page with infinite scrolling, which works  also as a workspace for users where you can manage your own resources. We have a single view of the  resource. So without, it's an editor, which is the viewer, full screen viewer of any resource,  just partial or document or whatever. And it's also an editor if you have the permissions.  And the back office is, well, we are, for the moment, we are reusing the legacy pages,  even though integrated, visually integrated with the new styling, the new front end style.  And we are, I mean, during the next months and next years, we will probably transition all the  back office to the new front end. One of the things that have been discussed with the community  was the ability to maintain the ability for developers to use Django templates,  because not everybody is able to work with React or wants to work with React. Oh, maybe they already  have a lot of custom applications and it's not feasible to port these applications to  a JavaScript client, a React client. So we did, we reworked the architecture of the front end  so that now you can mix React clients, your own React components with standard old Django apps.  So there's a template, a base template that is wrapping both the React client and the old Django  templates here. So you have the best of the two worlds. Even it's a bit strange. I mean, someone  doesn't like these kind of hybrid approaches, but this is the best of the two worlds in this moment.  So we can support any scenario and any context. So if you don't want to use React  client, you can go on with the standard Django templates. No problem. We have broken the standard,  the Django templates into snippets, very granular snippets, so that you can change  the single pieces of the templates and you can work on the styling of various in a granular way.  So you can just override this custom or provide your custom theme and you can change any single  piece of these snippets. You can also the configuration of the client has been made  overriding. So you have many ways to provide this configuration from static JavaScript,  template, settings, whatever, and everything is merged dynamically. So you can have many channels  to configure your application or provide custom configurations to your application.  And this is an example. I won't dig into the details, but I mean, the documentation will tell you  all of this. So the future, well, we will work on enforcing much more the privacy and provide  the privacy API to custom applications in a better, simpler way. And also we have the ability to  provide dynamically map store plugins inside the client, so without having to bundling custom  plugins into the map store bundle. So you can create plugins. We have an example. I will show  you here. I will go fast forward because I see that time is passing. This is a custom map store  plugin for meteorology of data. And this has been put into the application without having to rebundle  the map store client. So it's just a simple plugin, an extension. It uses a map store extension  concept to bundle your own plugin. And the other thing that I was saying, yes,  other big changes, the dataset style editor, but I think it, I mean, I can skip these. I mean,  it's more about new ways to style your resources in an efficient way. I don't know if I have more  time. I mean, I have really gone fast over the presentation, but I don't know. Yeah. Okay.  Okay. I will go to the end. So  the future, this is not a work in progress right now. We want to extend the permission system  for styles and data exports, because this is really important to provide security on top also  of the styles and the data exports, because I mean, every context has its policies for on these  things. And this is not strong enough. I mean, you have a permission system, but it's quite hidden.  So you don't have the means to control it easily. Completely support for non default,  just partial, worst basis on just ever. So you can compartmentize, you can already do it, but  we are improving that to the compartment compartmentization of data on the back end services.  And then also we are planning to work on a new  roles management on just ever, which can pool the rules from external services, so an  authorization service that can provide the rules to just ever services. So  improve also the integration inside multi services infrastructure with custom  policies. So you just have to provide the permissions for Geofence and just ever  as they understand them, but the way you build these rules is up to you. So you have the freedom to  even beyond what John O'Donnell does.  Yeah, we have data sharding, we have back end services. This is what I was saying before,  users and group partitioning. We already have all these concepts, but in most complex scenarios,  if in particular what someone calls the multi tenancy scenarios, maybe John O'Donnell is not  ready to be used in a multi tenancy environment or to provide multi tenancy services. You can get  there with some effort, you can more or less have it, but it's probably not the right way to do that.  So probably the best way is to deploy multiple genode nodes and make them share  with single sign on, shared authentication, authorization services, share just ever with  data sharding and so on. And maybe you get better results.  So by the way, many of these improvements are only ideas for the moment,  because I mean of course they are ideas that are coming from our experience on deploying  genode, even in complex and enterprise level scenarios. And so we have the pieces, even if  they're not built in right to be used in genode. Of course, these customization, the way you deploy  the customizations that you want to deploy, including secrets, including customizations to  the services, I mean services like the salary service, which is the broker of the task manager  for the synchronous task manager, all the way you want to expose just ever through NGINX.  You might want to change this. So this is doable because the genode project provides  all the Docker files and the Docker images that you can tweak to your special needs.  And that's what we do. We leverage in our deployment custom Docker overrides and Docker images.  This is the way to go and this is the way we are improving.  Okay, thank you Giovanni. Yeah, for the sake of time keeping and there's  some questions still. Thank you very much. I'm very impressed each year with how  genode progresses. I see there are at least two questions. We have two minutes so that  you can do so here I put it on screen and I read it for listeners is due server always  required for genode deployment. Can you also use map server instead of server?  At the moment, yes, I mean, just every is the only one. But the architecture is open to other  back-end implementations but they must be implemented. Okay, because you recently switched  from let's say to your network to PyCSW for instance? I understood. Yeah, also geo network  was removed. The support for geo network was removed from the master branch because  there wasn't enough maintenance resources for it. So by the way, in both cases the architecture  still supports implementing custom back-ends for the server. Okay, that's good to hear. Let's  have one last question. We've heard about geo storage but can it also be created via the  geo node REST API? Yes, in particular not the genode REST API but the map store client REST  APIs. So the map store client as I was showing before provides the REST APIs for this particular  kind of geo app. So by the way, it's a very thin, very thin REST API. So I would say yes,  I mean, the genode as you have it with the genode with map store client and so on provides the  REST API to build geo storage and the dashboards. Okay, thank you very much. Yeah, we have to move  on. Well, thanks again, Giovanni and I hope more people get inspired now with using geo nodes.  Thanks.
FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_0_359.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_360_2831.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_2832_3251.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_3252_3323.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_3324_4319.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_4320_5171.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_5172_5291.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_5292_5879.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_5880_7079.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_7080_8447.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_8448_9719.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_9720_12323.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_12324_14003.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_14004_14459.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_14460_16055.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_16056_17507.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_17508_18479.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_18480_19655.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_19656_20123.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_20124_20447.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_20448_20999.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_21000_21551.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_21552_23855.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_23856_24035.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_24036_24131.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_24132_25187.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_25188_27095.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_27096_28679.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_28680_30815.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_30816_31595.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_31596_32303.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_32304_32519.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_32520_33299.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_33300_33359.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_33360_33407.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_33408_33803.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_33804_33851.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_33852_34091.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_34092_34703.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_34704_34799.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_34800_35015.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_35016_35111.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_35112_37847.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_37848_40679.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_40680_42335.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_42336_44363.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_44364_45803.png FOSS4G_2021_-_One_Geonode__many_Geonodes_bvZg4I8DHY8_45804_46149.png
I'm hearing several sounds. Sorry for this. Yeah, welcome everyone. This morning's session and we'll look in real world application and usage of maybe OSGeo software. And without further ado, our first speaker is Giovanni Allegri. He's from the beautiful Tuscany, Italy. He works at Geosolutions Group as an architect and product manager and he's known under his username Geohappy. And he's in the GeoNode project steering, I like the username. GeoNode project steering committee and a long time contributor and GeoNode, by the way, is a, or I should say the open source geospatial content management system. And Giovanni will take us through a gallery of projects and use cases to showcase the versatility and effectiveness of GeoNode. So Giovanni, the floor is yours. Okay, thanks, Joss. Hello everybody. And yep, the introduction was done by Joss. So I'm the product manager in Geosolutions for GeoNode. So in this presentation, I would like to share some cases where GeoNode has been customized, adapted and bent to specific requirements. So you know, GeoNode, well, this is our company, which is a core maintainer of GeoNode, beyond my store, just ever and so on. We are working hard. We have quite a big team on GeoNode. And so our experience in GeoNode has been wide in these five, six years we've been working with it. As anybody, we started with one GeoNode, which is the one that you find in the releases that you find inside the main repository. So the one GeoNode is a so-called vanilla GeoNode, which is the core of GeoNode, which has everything that is needed. It's the Django application that provides all the functionalities and services for GeoNode. I think, well, I will go quickly through the features of GeoNode. I think many of you already know it, so I won't spend much time on these. But it's a content management system for just partial datasets, including some documents, media assets that let you compose applications on top of this data. But the core is sharing, collecting and using these data in many different ways. It's open source, yes, it's open source license. And well, it's a well-established platform with a mature set of libraries where GeoNode uses lots of the GeoNode and open source, your special software. It's built on top of Django, so it's Python application. And this is a platform that is targeting many use cases, both for users, administrators, but also developers. So developers are welcome into GeoNode because it can be easily extended. From the beginning, GeoNode was designed to be as open as possible to additions, extensions, customizations. This is provided by the Django platform itself. I mean, it's a framework with a lot of facilities to extend and integrate additional functionalities. And GeoNode inherits all these capabilities from Django. Currently, Django is a suite of services. This is just the main ones. So it's a Django application which provides by itself a client which is built on MapStore, which is a framework for potential solutions, and React. MapStore is built on top of React. Behind the scenes, we have just server which provides the OJC services on top of Django. We have PyCSW, and we have PostGIS and PostgreSQL and the GDAL libraries for all the processing behind the scenes. So there's in general, when we deploy it, we have other services too, but mainly these are the main components. So in a very quick overview of the workflow, we have files, remote services, remote files, which is a work in progress, but it's in a good shape already. So any kind of resource, be it a document or a special layer, can be imported or uploaded into GeoNode, either as a local resource. So you physically copy the data into GeoNode, and it will be stored as a file system stored or PostGIS database data. Or in case of remote services, you have situations where the data is referring to the remote resource. So with the local data, the data set and the documents are ready to be used to build applications on top of them, or to be used, it's not mentioned here, but of course, when the data inside GeoNode are ready to be used as OJC services directly, CSW services. So the catalog already provides the data sets and all the metadata for the data sets. But you can go on and build other applications on top of these base resources, these resources, which are maps, GeoStories, dashboards, and whatever other GeoApp. GeoStories and dashboards are GeoApps. So this is a concept which is generic in GeoNode. So any other module can implement a specific job. So GeoStories and dashboards, for example, are GeoApps implementations provided by the so-called MapStore client application, which is the one that provides also the new client, the client to GeoNode. It provides the client, the default client, the front-end application, but it also provides these implementations for two kinds of GeoApps. GeoStories and dashboards are already available in the 3.3x branch, the development branch of the series 3 of GeoNode. So at the end, you can use this data, both the the resources and the applications built on top of the resources as OJC services through Arrest API, or you can embed because all these resources provide a view, a way to be viewed inside third-party HTML application to HTML pages, so it has embedded viewers. So as you see, beyond being a management platform, so where you can manage permissions, you can manage users, people, you can manage workflows, publishing workflows, authorize, approval workflows. In the end, for the end users or the developers, it's a platform that can provide all the kind of services that you might need from a third-party app. This is the core of GeoNode, but on top of this core, on top of these capabilities, often we need to build custom applications. And we have a large experience on this. GeoNode by itself cannot address all use cases, of course. So the general approach is to wrap GeoNode inside the so-called GeoNode project. So a GeoNode project is a container, is a Django project, which contains GeoNode as an app. We have the so-called the GeoNode project repository, which is a template, a GeoNode project. With a command coming from Django, you can materialize this project and so build, generate a project like, you know, if you are from React, you know, you have generators for create React app and so on. So it's a generator, okay, we have a generator that creates a project and with the right domain, the name of the project and so on. So it's a custom Django app. With this app, you can follow all the patterns provided by Django. So you can use the overloading of templates, you can make extensions to the modus, you can even include apps that are your own apps that either interact or not with GeoNode. So you can create your Django project bundled with GeoNode itself. And we did it several times. I mean, to say the truth, the GeoNode project is the way we deploy GeoNode always. So we never deploy GeoNode vanilla, we always deploy a GeoNode project instance. Even the demo that you can see online, the stable demo, the development demo, they are GeoNode projects. So from the past, we have, you see, these are old projects, but I mean, it's a quick overview of some examples of the customizations. You will see here, you have a view that is not from GeoNode. We have buttons, actions, tabs, views that are not provided by GeoNode, they are provided by the custom application. And but they are integrated both functionally and visually integrated into GeoNode. So you see in the top and the bottom, you see this, it's a GeoNode. For UNESCO, we started the work that is being the first test to review the homepage for GeoNode and all layouts of GeoNode. So you see a grid system, a grid of cards in the homepage. And this is what you will see in the master branch of GeoNode now. So also in this case, this is a GeoNode 3, but with a custom homepage and with a custom react application that drives this homepage. But all the rest is other templates and the Chang of views that you know from GeoNode. In this case, we completely changed also the UI, so you cannot say that it's GeoNode if you don't know it. But behind the scenes, it's GeoNode. So only the back end is GeoNode and the front end is completely custom. And for this case, for GFDRR, this is a client built on top of Map Store client, but with the custom table of contents, custom explorers of data and the histogram charts. So as you see, I mean, with the infrastructure provided by the Django framework, you have the freedom to do whatever you want, I mean, extending, replacing, back end and front end. Okay, and just keep what you need in the end. This is another example where we have also changed the filtering on the side, the facets, filtering in a custom template. So we have added filtering tabs that are not available in a standard GeoNode. And with new menus on the top, some of these customizations are available from the Django admin. So you can change the logo, you can change the main color of the web of GeoNode directly from the Django administration. So without having to change the templates or the source code, of course, these are just the basic changes that you can do. If you want to do more, we will see later there are more advanced ways to do that. Next to platform is the current, I mean, it's a client for us, a GF solutions client. And this has given us the opportunity to start the GeoNode master branch. So what will become the four series of GeoNode? And it's a complete refactoring of the front end and of some important pieces and components of the back end. The storage system, the resource management system, the remote services system. So all these services have been completely refactored. The UI has been optimized a lot. It's a mix of single page application and Django templates. I will show you briefly. And we have reduced a lot the number of clicks to perform the usual actions on resources. You have quick previews of resources without having to dig into the hierarchy of resources. So bring your own GeoNode. So that's what I was saying. You have a GeoNode project. You have a GeoNode Django app. You can put any app that you want behind. And then this is a MapStore client. The MapStore client is exactly an app inside the Django project, which provides the client, the MapStore front end client, which is the default client for GeoNode now. It provides its own REST API. And this is used, for example, for the dashboards and GeoStories resources that I was showing before. And it interacts with GeoNode. So you see that if you want to change the back end of the front end, you can just take away MapStore and redo it as you prefer. I mean, you have everything to manage GeoNode through REST API and so on. So from the point of view of customizing GeoNode, what are the objectives for the next major versions? We want to improve the uploaded storage. And this is a work in progress. Resource cloning, meaning versioning of resources, is already done. We have abstract map, big engine. So GeoNode, just ever is an abstract element now. We have a harvester and extended permission systems and so on. But what I really want to say now is that you have a new SP client, custom templates, support and an extended REST API. The REST API v2 is almost complete and it really gives you the ability to interact however you want with GeoNode, both for the, for viewing resources, searching resources, but also managing GeoNode itself, if you have, of course, the credentials to do that. And most of these is already available to test the master branch. So yeah, it's in a good shape. But we have a brand new front end with the React, with everything, all the tool set coming from Map Store. The home page, SP Refactor, we have a single page with infinite scrolling, which works also as a workspace for users where you can manage your own resources. We have a single view of the resource. So without, it's an editor, which is the viewer, full screen viewer of any resource, just partial or document or whatever. And it's also an editor if you have the permissions. And the back office is, well, we are, for the moment, we are reusing the legacy pages, even though integrated, visually integrated with the new styling, the new front end style. And we are, I mean, during the next months and next years, we will probably transition all the back office to the new front end. One of the things that have been discussed with the community was the ability to maintain the ability for developers to use Django templates, because not everybody is able to work with React or wants to work with React. Oh, maybe they already have a lot of custom applications and it's not feasible to port these applications to a JavaScript client, a React client. So we did, we reworked the architecture of the front end so that now you can mix React clients, your own React components with standard old Django apps. So there's a template, a base template that is wrapping both the React client and the old Django templates here. So you have the best of the two worlds. Even it's a bit strange. I mean, someone doesn't like these kind of hybrid approaches, but this is the best of the two worlds in this moment. So we can support any scenario and any context. So if you don't want to use React client, you can go on with the standard Django templates. No problem. We have broken the standard, the Django templates into snippets, very granular snippets, so that you can change the single pieces of the templates and you can work on the styling of various in a granular way. So you can just override this custom or provide your custom theme and you can change any single piece of these snippets. You can also the configuration of the client has been made overriding. So you have many ways to provide this configuration from static JavaScript, template, settings, whatever, and everything is merged dynamically. So you can have many channels to configure your application or provide custom configurations to your application. And this is an example. I won't dig into the details, but I mean, the documentation will tell you all of this. So the future, well, we will work on enforcing much more the privacy and provide the privacy API to custom applications in a better, simpler way. And also we have the ability to provide dynamically map store plugins inside the client, so without having to bundling custom plugins into the map store bundle. So you can create plugins. We have an example. I will show you here. I will go fast forward because I see that time is passing. This is a custom map store plugin for meteorology of data. And this has been put into the application without having to rebundle the map store client. So it's just a simple plugin, an extension. It uses a map store extension concept to bundle your own plugin. And the other thing that I was saying, yes, other big changes, the dataset style editor, but I think it, I mean, I can skip these. I mean, it's more about new ways to style your resources in an efficient way. I don't know if I have more time. I mean, I have really gone fast over the presentation, but I don't know. Yeah. Okay. Okay. I will go to the end. So the future, this is not a work in progress right now. We want to extend the permission system for styles and data exports, because this is really important to provide security on top also of the styles and the data exports, because I mean, every context has its policies for on these things. And this is not strong enough. I mean, you have a permission system, but it's quite hidden. So you don't have the means to control it easily. Completely support for non default, just partial, worst basis on just ever. So you can compartmentize, you can already do it, but we are improving that to the compartment compartmentization of data on the back end services. And then also we are planning to work on a new roles management on just ever, which can pool the rules from external services, so an authorization service that can provide the rules to just ever services. So improve also the integration inside multi services infrastructure with custom policies. So you just have to provide the permissions for Geofence and just ever as they understand them, but the way you build these rules is up to you. So you have the freedom to even beyond what John O'Donnell does. Yeah, we have data sharding, we have back end services. This is what I was saying before, users and group partitioning. We already have all these concepts, but in most complex scenarios, if in particular what someone calls the multi tenancy scenarios, maybe John O'Donnell is not ready to be used in a multi tenancy environment or to provide multi tenancy services. You can get there with some effort, you can more or less have it, but it's probably not the right way to do that. So probably the best way is to deploy multiple genode nodes and make them share with single sign on, shared authentication, authorization services, share just ever with data sharding and so on. And maybe you get better results. So by the way, many of these improvements are only ideas for the moment, because I mean of course they are ideas that are coming from our experience on deploying genode, even in complex and enterprise level scenarios. And so we have the pieces, even if they're not built in right to be used in genode. Of course, these customization, the way you deploy the customizations that you want to deploy, including secrets, including customizations to the services, I mean services like the salary service, which is the broker of the task manager for the synchronous task manager, all the way you want to expose just ever through NGINX. You might want to change this. So this is doable because the genode project provides all the Docker files and the Docker images that you can tweak to your special needs. And that's what we do. We leverage in our deployment custom Docker overrides and Docker images. This is the way to go and this is the way we are improving. Okay, thank you Giovanni. Yeah, for the sake of time keeping and there's some questions still. Thank you very much. I'm very impressed each year with how genode progresses. I see there are at least two questions. We have two minutes so that you can do so here I put it on screen and I read it for listeners is due server always required for genode deployment. Can you also use map server instead of server? At the moment, yes, I mean, just every is the only one. But the architecture is open to other back-end implementations but they must be implemented. Okay, because you recently switched from let's say to your network to PyCSW for instance? I understood. Yeah, also geo network was removed. The support for geo network was removed from the master branch because there wasn't enough maintenance resources for it. So by the way, in both cases the architecture still supports implementing custom back-ends for the server. Okay, that's good to hear. Let's have one last question. We've heard about geo storage but can it also be created via the geo node REST API? Yes, in particular not the genode REST API but the map store client REST APIs. So the map store client as I was showing before provides the REST APIs for this particular kind of geo app. So by the way, it's a very thin, very thin REST API. So I would say yes, I mean, the genode as you have it with the genode with map store client and so on provides the REST API to build geo storage and the dashboards. Okay, thank you very much. Yeah, we have to move on. Well, thanks again, Giovanni and I hope more people get inspired now with using geo nodes. Thanks.
the open source geospatial content management gallery of projects and use cases to showcase the versatility and effectiveness of GeoNode. So GeoNode is a so-called vanilla GeoNode, which is needed. It's the Django application that provides GeoNode was designed to be as open as possible to which is built on MapStore, which is a framework components. So in a very quick overview of the files, which is a work in progress, but it's in a the local data, the data set and the documents which are maps, GeoStories, dashboards, and implement a specific job. So GeoStories and GeoNode. It provides the client, the default where you can manage permissions, you can manage applications. And we have a large experience on to the modus, you can even include apps that are demo, the development demo, they are GeoNode overview of some examples of the customizations. the web of GeoNode directly from the Django reduced a lot the number of clicks to perform the project, which provides the client, the MapStore interact however you want with GeoNode, both for also as a workspace for users where you can with the community was the ability to maintain templates, because not everybody is able to work this. So the future, well, we will work on plugin for meteorology of data. And this has been support for non default, just partial, worst services, so an authorization service that can improve also the integration inside multi environment or to provide multi tenancy services. authorization services, share just ever with data results. So by the way, many of these