In previous sections, we introduced GIS and WebGIS, and provided an overview on some tools and libraries used for WebGIS. We explained what a GIS is and dived a little into the core of WebGIS. Next, we went further to categorically introduce some of the open-source tools that are used in WebGIS projects.
A picture is worth a thousand words, they say. In that light, my goal in this section is to explain the architectural workflow of a WebGIS without being verbose. It is expedient we understand that there is no de facto WebGIS architecture, workflows are dependent on their application context, however, they all rely on a three-tier client/server architecture.
Implementing a WebGIS relies on the client/server model. The whole operation is broken down into client facing side and the server-side. The client can be a web browser or a desktop GIS software and the server-side consists of a Web Server (e.g Apache Tomcat), Web GIS server (e.g GeoServer or MapServer), and a Database (e.g PostGIS). Below is a graphic that illustrates the whole process.
What is a Client/Server Architecture?
Leaving all the technicality aside, let me try to explain it to you using an example I think we could all relate to. Let’s look at it in this direction, a customer (client) visits a restaurant to make some orders. The waiter (server) is always listening to customer orders or requests. Once the request is received, waiter processes it, communicate with the chefs (database ) to prepare the client’s request/order and return a response to the client.
This is tantamount to how WebGIS works and even the web generally. We have a database that stores our spatial data e.g PostGIS, which is installed on or connected to a server, such as Apache Tomcat for example, that’s installed on a Linux machine and always listens to requests, on the server is also a Web GIS server such as a GeoServer instance installed to handle OGC services requests such as WFS and WMS, these requests are processed and sent back to the browsers via the frontend libraries such as Leaflet, OpenLayers that makes the requests and displays it beautifully in the browser.
All these happen in a jiffy, and depends on a lot of factors, for example, your internet connectivity and of course, there are a lot of processes that occur in the background, but since the goal is to make us understand the whole process with minimal words I won’t scare us away with super complex technical details.
Still don’t get it yet?
Additionally, while navigating the websites, they’re a lot of requests and response operations that undergoes in the background. For example, when we make an order, the order details and information are sent to the server to get the order processed and packaged for delivery. (This is a typical POST request). That process is similar to what happens in WebGIS. A user pans around the map, the browser or the GIS software sends a request to the server, the server process it, and returns a response back to the client to display. Sometimes if a request is frequent the response is cached to reduce latency and for a better user experience.
Phew! that’s a lot, I know. Thanks so much for sticking around! I do hope it’s comprehensive enough. I promised not to be verbose so I’ll drop my pens here. Please do not forget to share if you find this article helpful.
Finally, future sections are more of coding, software, and library installation. I would be demonstrating these activities on my youtube channel. Kindly subscribe if you haven’t. Thanks! And see you in the next section!
This article has been republished with permission from the author. See the original article here.