QWCII: A new QGIS Web Client
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.
Neumann, Andreas (Kanton Zug, GIS-Fachstelle)
Jönsson, Karl-Magnus (Kristianstads kommun)
QGIS Web Client (QWC) is a Web-GIS client based on OpenLayers 2 and ExtJS and tailored to use special extensions of QGIS Server, such as extracting information from QGIS Project settings, extended GetFeatureInfo Requests, GetPrint and DXF export. It uses standard WMS/WFS commands, but extends them where needed. QWC is used by several cities and provinces in Europe. There are four main reasons why QWC needs to be overhauled: The code structure is not very modular and should be better structured. QWC only works well on Desktops. Despite a separate mobile web client based on OpenLayers 3 and jQuery Mobile, for maintenance reasons it would be much better to have a single web client that uses responsive design and works for all devices from a single viewer. The base libraries ExtJS 3.4 and Openlayers 2 have been phased out and there are newer versions available. However, the upgrade to the newer versions is not trivial. Having a more modern foundation based on newer web technologies This presentation discusses the requirements, the progress of this project, technical decisions taken and challenges solved during the project. While the first goal of the project is to establish a modern foundation for the coming years and reach feature parity with the old QWC project, it is already planned to implement a QWCII python plugin that offers a GUI and assists with the global configuration of the client. This tool should also facilitate the management of topics and projects.
 This is the final presentation in this session, also about QGIS, but this time it's about the new QGIS client, web client. The presentation is with Andreas Neumann and Pierre Mencalper from Switzerland. We actually have a third person on the slide, which is Karl Magnus, he's in the middle. He's also part of our project team. But as it's not so useful to present with three people, we decided to do it just this too. QGIS web client, a quick look back. It was introduced in 2009 and the goal was to have, as with the previous presentations, being able to transport the QGIS desktop project and publish it on the web. So the whole idea is not having to edit map files or SLDs or whatever complicated formats there are to configure or CSS or to configure web mapping applications. Make it really easy for users to publish a map they already have in the local GIS infrastructure. The QGIS web client one was a few only and it's built upon OpenLayers 2, which is already faced out as you know, and XJS3, which is already faced out as you know, and GX2, which is also has a successor. The bad thing with libraries is they are not compatible with the next version. Basically it means you have to rewrite the whole system because X3 to X5 you cannot port easily or the same with OpenLayers. It's specifically the client was built around the extended capabilities of QGIS server. QGIS server as you may know is a WXS server, so WMS, WFS and so on, but it has few extra extensions mainly for stuff that is not in the standard. Things like printing, if you want to use printing from the printing template you already have in QGIS, WMS doesn't have a printing standard, so this is one of the extensions we are using. Or some other extensions, they get feature info command for example is not very standardized in WMS, which means if you want to have some additional functions in a get feature info you have to amend something yourself. It was starting 2009 in Usta, then others joined in, translated into 15 languages meanwhile and it's available on GitHub at the, oh I forgot the address. Why is it not here? It's actually in a QGIS web where you can find it. This is how it looked like and one of the reasons we want to replace it, a colleague in Switzerland always tells me this looks so much like the 90s. Looks like Windows 95 or something. So it's not up to the modern design that people are used to with mobile devices. So you can see the feature info queries, you can see search function, printing, export, peer management and so on. What's going on? Okay, thanks. This is a recap of what QGIS web client one did and the goal is to, if you want to introduce web client two that it should at least do the same functionality this web client one did. I won't read it all. These are the web client one users. I'm aware of, I'm sure there are more out there but these are the ones I also collaborate with. Many of them also help to finance or organize the new project. Speaking about QGIS server, this is what QGIS server currently supports to serve from your QGIS desktop project. I put WPS in parentheses. I'm not so sure how far it is developed. It's probably work in progress or some alpha version. But there is an idea to use QGIS processing and publish it as a WPS service. I know that the French company Twilies, they're working on it. Yeah, that one I already mentioned, the easy configuration of projects in QGIS desktop. The symbology will always be the same between your server web map and your desktop. QGIS server has an extension called get project settings. What it does is it tries to transport additional information also not available in the WMS standards. For example, information on the attributes, on the field widgets that may be useful for a web mapping client to display, for example, feature info data. PDF printing and it has filter and selection commands. Now the new project, the reasons for that is I already mentioned, libraries are phased out and another drawback of the old project was that they had separate versions for desktop and mobile. There was another mobile web client made by SourcePool that we used built around Open Layer 3 and Chakevary. But the Chakevary is not very well performing, especially on tree structures. There are faster options out there. And we'd like to have one client for desktop and mobile, which is fully responsive as you change windows sizes or have different device ratios. And we want it to be built on top of modern web frameworks. And we mainly looked at Angular and React.js as the two main options that we considered. Of course I mentioned a new fresh look and feel that we want. And one goal is to make it quite modular. And maybe who of you went to the MapStore 2 presentation this morning? Some of you showed how you can enable disabled components. That's something we want to have for QQS web client too as well. So every user can configure it to his own which actually the SPMN will say later we want to reuse the same stuff from MapStore 2. Those are core requirements. And of course one of the main goals is again make it suitable for the QQS server extensions. That's why we cannot just use out of the box any web client which doesn't support it. And further into the project one of the goals is make it very easy to deploy. So a deploy script should take all the required modules and deploy it in a minified, compressed version so you don't have to either serve big versions that are too bloated or do it manually yourself. And the idea is to have at the later in probably next year have a QQS plugin or a web version like we've seen today in the MapStore presentation where you can select components you want and configure them. Also the partners, City of Ooster which is my former employer. I changed meanwhile to Kanton of Zug at the beginning of January but they are one of the first to finance the project and will deploy it next year. Then the Kanton of Klarus, City of Wolfsburg in Germany and the Swedish community will be joining later and Jena and most likely my new employer as well. And the developer company will start the first version will be Suspol which we collaborate for some time already and later on Invit in Sweden will also provide some modules. And once the first version is out there it will be published in the QQS repo so other companies or developers could also join in and help. Now I want to hand over to Pyramin and explain why we chose ReactJS. I will tell you a few things about the technical background. As Andrea said we have chosen the ReactJS framework from Facebook which has some major things we were looking for. It is strictly component based which means you can develop components which are really not tightly coupled. They are very independent. It's not a full featured MVC framework like Angular. It's basically centered on the view part of an application and a map client is mostly view and not so much business logic in the background. And the concepts are easier than other frameworks have. It is performance optimized as a nice concept about updating the DOM in the browser and has a good tooling, development tools, the whole minimizing stuff, minification is you can get it out of the box. So this is a major JavaScript framework we are using and the other one is OpenLayer3. We built on which is very powerful as most of you know it has all the features we need for professional GIS. And it's still fast and modular so you can compile your own version with only the parts you need and this is even built in in this development chain. You get an optimized OpenLayers plus the viewer framework around it. And it's usable on mobile and on the desktop. And the non-technical reason is also that many of these partners already investment in OpenLayer3 development. We started with mockups thanks to Peter Staub from Canon of Claros heavily inspired by the Swiss Topo design. So this is how it should look like. These are three different mockups, the desktop mockup covering the whole screen size, the tablet and the mobile viewer. There are slight differences. You will notice up there the text is not there anymore on the left side. The logo gets smaller. Some buttons disappear. But it's basically the same. And the second page is about the tools. So we have two menus which look very similar on all three platforms and can be popped out making bigger get more space when you go on one of these tools. We have buttons for background maps, the usual things. That's the goal we have. And that's the plan in terms of time. So we started on a prototype and as Andri has mentioned, we don't start from scratch. We want to build on MapsR2. We talked to the developers of MapsR2 and we will collaborate with them. And MapsR2 is a new framework exactly with the technology we wanted to use. And the difference is that it's targeted to a Geo server as a back end. So one part of the work will be to adapt it to QG server on the back end. On the front end, we can use most of it. So we started a few weeks ago and we will already have a code base ready for other developers in September that's the earliest, maybe better to step in later, but it's possible in September. And the first deployments are planned in early 2017 and development will go on next year. So I can show you the current version which is basically MapsR2. That's not the next version, that's the current QG's web client. And what I want to show is the same map in the new viewer and that's a basic MapsR2 viewer. We start, that's our starting point. We build on. Another tool, not exactly the look we want. Now I have a difficult operation over my shoulder. I can show you the same map. The same map to the map from QG's cloud which is QG server map. I select this map and here I have the same map served from QG server. Some tools are included. It's a layer tool, background, selection, and so on. So these are the existing tools. We start our work. I have some more time. We have also identified functionality. We have zooming. We have, we can collapse here, locate on the map, go back and forth, zoom to max extent, all the stuff. Which is needed and here are some more and maybe the biggest difference or one of the first things is printing because that's completely different. With QG server we can use the print layout from the QG project. So we need less work on server side and also on client side but we also need tools to rotate the map in the print layout so there is much work for printing and other things are really are usable and we only have to adapt to the look and feel. So that's the current development. And so the last slide is about how you can help. So you saw this organization sponsoring this first part of the work. That's the financial side. You can also help testing. We will publish regularly on GitHub. And as I said, everybody is welcome to develop. But one of our first steps will be to make it easier for QG developers to start with that framework. So really concentrate on that viewer that you can start and write your own components or adapt it for your needs. And all these things are coordinated by Andreas Neumann so contact him if you want to do one of these three things. So I think it's time for questions. Thank you. Thank you for the presentation and questions. Anyone? Karl Maunus. I know you were supposed to be a presenter here too. How are you using this web here? OK. We're not using it yet. But I've been working with Andreas with requirements documents since last year. And now we have a contract with a developer. So we are getting in with developing resources into the project this autumn. And we'll hope it will work out well for our local municipal in Kyrgyzstan, Sweden. I'd like maybe to make it clear that most of the work was really done by Geosolutions here. We've seen the client not to make false impression that we did the client. So we're just starting built on that client and then we'll move on to develop additional components and integrate it with QGIS server very well. And another question? In the past when I tried to run QGIS server, it was always quite complex task to get it up and running. It worked in the end, but it took a bit of time always. So I wonder if you have any plans to ship Docker containers, pre-configured ones, or similar possibilities to get something which is pre-configured to run quickly? I don't think it's part of that project, of course, someone is welcome to do that, but it's not our main task. We as organizations, we already have it set up. But I think I agree it could be easier to deploy the QGIS map server. It's not talking about the whole framework. But it's not a goal of this project. If someone else wants to do it, you're welcome to reuse it. This is sort of some of the last question. You're using QGIS server because of enhancements to standard OGC services. Is there any, those services are again community driven and able to be improved? Is there any feedback or loop you have for improving the specifications for things like WFS by identifying the Lex you see in it and how you're meeting those and improving the standards to address those Lex? For the first part, it's not just the standard extensions that we are using, but we also like the fact that it's easy to configure. So the styling a map in QGIS is very easy and people do it sometimes anyway because they need it in the office. So that's one of the main reasons I think. But feeding the improvements back to the standardization organization, I actively did not do it because I didn't see any activity with WMS so far in the latest years. Is there any? It's a good idea, yeah. Do you want to comment on it? I mean, other map service they have a rest interface with additional functionality and this isn't standardized either. So maybe there will be some standard in the future. I mean, all these projects they have additional functionality and they want to expose that to the user so they extend the interface. But they lose something when there is a standard because then you have like a common denominator for everyone. So maybe it happens, maybe not. Will you in the future, will you collaborate with the Italian company that's, oh, it's Geosolution to further develop the core code base for the two projects so what? That's definitely planned. Yeah, that this our work is also fed back into MapStore 2 and usable with GeoServer as well. So you could have the same interface with GeoServer maybe. So that should be possible. Thank you for your presentation and now it's time for coffee break.
 This is the final presentation in this session, also about QGIS, but this time it's about  the new QGIS client, web client.  The presentation is with Andreas Neumann and Pierre Mencalper from Switzerland.  We actually have a third person on the slide, which is Karl Magnus, he's in the middle.  He's also part of our project team.  But as it's not so useful to present with three people, we decided to do it just this  too.  QGIS web client, a quick look back.  It was introduced in 2009 and the goal was to have, as with the previous presentations,  being able to transport the QGIS desktop project and publish it on the web.  So the whole idea is not having to edit map files or SLDs or whatever complicated formats  there are to configure or CSS or to configure web mapping applications.  Make it really easy for users to publish a map they already have in the local GIS infrastructure.  The QGIS web client one was a few only and it's built upon OpenLayers 2, which is already  faced out as you know, and XJS3, which is already faced out as you know, and GX2, which  is also has a successor.  The bad thing with libraries is they are not compatible with the next version.  Basically it means you have to rewrite the whole system because X3 to X5 you cannot port  easily or the same with OpenLayers.  It's specifically the client was built around the extended capabilities of QGIS server.  QGIS server as you may know is a WXS server, so WMS, WFS and so on, but it has few extra  extensions mainly for stuff that is not in the standard.  Things like printing, if you want to use printing from the printing template you already have  in QGIS, WMS doesn't have a printing standard, so this is one of the extensions we are using.  Or some other extensions, they get feature info command for example is not very standardized  in WMS, which means if you want to have some additional functions in a get feature info  you have to amend something yourself.  It was starting 2009 in Usta, then others joined in, translated into 15 languages meanwhile  and it's available on GitHub at the, oh I forgot the address.  Why is it not here?  It's actually in a QGIS web where you can find it.  This is how it looked like and one of the reasons we want to replace it, a colleague  in Switzerland always tells me this looks so much like the 90s.  Looks like Windows 95 or something.  So it's not up to the modern design that people are used to with mobile devices.  So you can see the feature info queries, you can see search function, printing, export,  peer management and so on.  What's going on?  Okay, thanks.  This is a recap of what QGIS web client one did and the goal is to, if you want to introduce  web client two that it should at least do the same functionality this web client one  did.  I won't read it all.  These are the web client one users.  I'm aware of, I'm sure there are more out there but these are the ones I also collaborate  with.  Many of them also help to finance or organize the new project.  Speaking about QGIS server, this is what QGIS server currently supports to serve from  your QGIS desktop project.  I put WPS in parentheses.  I'm not so sure how far it is developed.  It's probably work in progress or some alpha version.  But there is an idea to use QGIS processing and publish it as a WPS service.  I know that the French company Twilies, they're working on it.  Yeah, that one I already mentioned, the easy configuration of projects in QGIS desktop.  The symbology will always be the same between your server web map and your desktop.  QGIS server has an extension called get project settings.  What it does is it tries to transport additional information also not available in the WMS  standards.  For example, information on the attributes, on the field widgets that may be useful for  a web mapping client to display, for example, feature info data.  PDF printing and it has filter and selection commands.  Now the new project, the reasons for that is I already mentioned, libraries are phased  out and another drawback of the old project was that they had separate versions for desktop  and mobile.  There was another mobile web client made by SourcePool that we used built around Open  Layer 3 and Chakevary.  But the Chakevary is not very well performing, especially on tree structures.  There are faster options out there.  And we'd like to have one client for desktop and mobile, which is fully responsive as you  change windows sizes or have different device ratios.  And we want it to be built on top of modern web frameworks.  And we mainly looked at Angular and React.js as the two main options that we considered.  Of course I mentioned a new fresh look and feel that we want.  And one goal is to make it quite modular.  And maybe who of you went to the MapStore 2 presentation this morning?  Some of you showed how you can enable disabled components.  That's something we want to have for QQS web client too as well.  So every user can configure it to his own which actually the SPMN will say later we  want to reuse the same stuff from MapStore 2.  Those are core requirements.  And of course one of the main goals is again make it suitable for the QQS server extensions.  That's why we cannot just use out of the box any web client which doesn't support it.  And further into the project one of the goals is make it very easy to deploy.  So a deploy script should take all the required modules and deploy it in a minified, compressed  version so you don't have to either serve big versions that are too bloated or do it  manually yourself.  And the idea is to have at the later in probably next year have a QQS plugin or a web version  like we've seen today in the MapStore presentation where you can select components you want and  configure them.  Also the partners, City of Ooster which is my former employer.  I changed meanwhile to Kanton of Zug at the beginning of January but they are one of the  first to finance the project and will deploy it next year.  Then the Kanton of Klarus, City of Wolfsburg in Germany and the Swedish community will  be joining later and Jena and most likely my new employer as well.  And the developer company will start the first version will be Suspol which we collaborate  for some time already and later on Invit in Sweden will also provide some modules.  And once the first version is out there it will be published in the QQS repo so other  companies or developers could also join in and help.  Now I want to hand over to Pyramin and explain why we chose ReactJS.  I will tell you a few things about the technical background.  As Andrea said we have chosen the ReactJS framework from Facebook which has some major  things we were looking for.  It is strictly component based which means you can develop components which are really  not tightly coupled.  They are very independent.  It's not a full featured MVC framework like Angular.  It's basically centered on the view part of an application and a map client is mostly  view and not so much business logic in the background.  And the concepts are easier than other frameworks have.  It is performance optimized as a nice concept about updating the DOM in the browser and  has a good tooling, development tools, the whole minimizing stuff, minification is you  can get it out of the box.  So this is a major JavaScript framework we are using and the other one is OpenLayer3.  We built on which is very powerful as most of you know it has all the features we need  for professional GIS.  And it's still fast and modular so you can compile your own version with only the parts  you need and this is even built in in this development chain.  You get an optimized OpenLayers plus the viewer framework around it.  And it's usable on mobile and on the desktop.  And the non-technical reason is also that many of these partners already investment  in OpenLayer3 development.  We started with mockups thanks to Peter Staub from Canon of Claros heavily inspired by the  Swiss Topo design.  So this is how it should look like.  These are three different mockups, the desktop mockup covering the whole screen size, the  tablet and the mobile viewer.  There are slight differences.  You will notice up there the text is not there anymore on the left side.  The logo gets smaller.  Some buttons disappear.  But it's basically the same.  And the second page is about the tools.  So we have two menus which look very similar on all three platforms and can be popped out  making bigger get more space when you go on one of these tools.  We have buttons for background maps, the usual things.  That's the goal we have.  And that's the plan in terms of time.  So we started on a prototype and as Andri has mentioned, we don't start from scratch.  We want to build on MapsR2.  We talked to the developers of MapsR2 and we will collaborate with them.  And MapsR2 is a new framework exactly with the technology we wanted to use.  And the difference is that it's targeted to a Geo server as a back end.  So one part of the work will be to adapt it to QG server on the back end.  On the front end, we can use most of it.  So we started a few weeks ago and we will already have a code base ready for other developers  in September that's the earliest, maybe better to step in later, but it's possible in September.  And the first deployments are planned in early 2017 and development will go on next year.  So I can show you the current version which is basically MapsR2.  That's not the next version, that's the current QG's web client.  And what I want to show is the same map in the new viewer and that's a basic MapsR2 viewer.  We start, that's our starting point.  We build on.  Another tool, not exactly the look we want.  Now I have a difficult operation over my shoulder.  I can show you the same map.  The same map to the map from QG's cloud which is QG server map.  I select this map and here I have the same map served from QG server.  Some tools are included.  It's a layer tool, background, selection, and so on.  So these are the existing tools.  We start our work.  I have some more time.  We have also identified functionality.  We have zooming.  We have, we can collapse here, locate on the map, go back and forth, zoom to max extent,  all the stuff.  Which is needed and here are some more and maybe the biggest difference or one of the  first things is printing because that's completely different.  With QG server we can use the print layout from the QG project.  So we need less work on server side and also on client side but we also need tools to rotate  the map in the print layout so there is much work for printing and other things are really  are usable and we only have to adapt to the look and feel.  So that's the current development.  And so the last slide is about how you can help.  So you saw this organization sponsoring this first part of the work.  That's the financial side.  You can also help testing.  We will publish regularly on GitHub.  And as I said, everybody is welcome to develop.  But one of our first steps will be to make it easier for QG developers to start with  that framework.  So really concentrate on that viewer that you can start and write your own components  or adapt it for your needs.  And all these things are coordinated by Andreas Neumann so contact him if you want to do one  of these three things.  So I think it's time for questions.  Thank you.  Thank you for the presentation and questions.  Anyone?  Karl Maunus.  I know you were supposed to be a presenter here too.  How are you using this web here?  OK.  We're not using it yet.  But I've been working with Andreas with requirements documents since last year.  And now we have a contract with a developer.  So we are getting in with developing resources into the project this autumn.  And we'll hope it will work out well for our local municipal in Kyrgyzstan, Sweden.  I'd like maybe to make it clear that most of the work was really done by Geosolutions  here.  We've seen the client not to make false impression that we did the client.  So we're just starting built on that client and then we'll move on to develop additional  components and integrate it with QGIS server very well.  And another question?  In the past when I tried to run QGIS server, it was always quite complex task to get it  up and running.  It worked in the end, but it took a bit of time always.  So I wonder if you have any plans to ship Docker containers, pre-configured ones, or  similar possibilities to get something which is pre-configured to run quickly?  I don't think it's part of that project, of course, someone is welcome to do that, but  it's not our main task.  We as organizations, we already have it set up.  But I think I agree it could be easier to deploy the QGIS map server.  It's not talking about the whole framework.  But it's not a goal of this project.  If someone else wants to do it, you're welcome to reuse it.  This is sort of some of the last question.  You're using QGIS server because of enhancements to standard OGC services.  Is there any, those services are again community driven and able to be improved?  Is there any feedback or loop you have for improving the specifications for things like  WFS by identifying the Lex you see in it and how you're meeting those and improving the  standards to address those Lex?  For the first part, it's not just the standard extensions that we are using, but we also like  the fact that it's easy to configure.  So the styling a map in QGIS is very easy and people do it sometimes anyway because  they need it in the office.  So that's one of the main reasons I think.  But feeding the improvements back to the standardization organization, I actively did not do it because  I didn't see any activity with WMS so far in the latest years.  Is there any?  It's a good idea, yeah.  Do you want to comment on it?  I mean, other map service they have a rest interface with additional functionality and  this isn't standardized either.  So maybe there will be some standard in the future.  I mean, all these projects they have additional functionality and they want to expose that  to the user so they extend the interface.  But they lose something when there is a standard because then you have like a common denominator  for everyone.  So maybe it happens, maybe not.  Will you in the future, will you collaborate with the Italian company that's, oh, it's  Geosolution to further develop the core code base for the two projects so what?  That's definitely planned.  Yeah, that this our work is also fed back into MapStore 2 and usable with GeoServer  as well.  So you could have the same interface with GeoServer maybe.  So that should be possible.  Thank you for your presentation and now it's time for coffee break.
foss4g-2016-1138-qwcii_a_new_qgis_web_client-hd_0_335.png foss4g-2016-1138-qwcii_a_new_qgis_web_client-hd_336_743.png foss4g-2016-1138-qwcii_a_new_qgis_web_client-hd_744_791.png foss4g-2016-1138-qwcii_a_new_qgis_web_client-hd_792_851.png foss4g-2016-1138-qwcii_a_new_qgis_web_client-hd_852_983.png foss4g-2016-1138-qwcii_a_new_qgis_web_client-hd_984_1367.png foss4g-2016-1138-qwcii_a_new_qgis_web_client-hd_1368_6767.png foss4g-2016-1138-qwcii_a_new_qgis_web_client-hd_6768_19871.png foss4g-2016-1138-qwcii_a_new_qgis_web_client-hd_19872_24803.png foss4g-2016-1138-qwcii_a_new_qgis_web_client-hd_24804_28751.png foss4g-2016-1138-qwcii_a_new_qgis_web_client-hd_28752_28835.png foss4g-2016-1138-qwcii_a_new_qgis_web_client-hd_28836_32591.png foss4g-2016-1138-qwcii_a_new_qgis_web_client-hd_32592_34571.png foss4g-2016-1138-qwcii_a_new_qgis_web_client-hd_34572_34667.png foss4g-2016-1138-qwcii_a_new_qgis_web_client-hd_34668_35051.png foss4g-2016-1138-qwcii_a_new_qgis_web_client-hd_35052_37739.png foss4g-2016-1138-qwcii_a_new_qgis_web_client-hd_37740_38483.png foss4g-2016-1138-qwcii_a_new_qgis_web_client-hd_38484_38651.png foss4g-2016-1138-qwcii_a_new_qgis_web_client-hd_38652_38879.png foss4g-2016-1138-qwcii_a_new_qgis_web_client-hd_38880_39037.png