The goal of this article 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.
TL;DR
In summary, 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), and a Database(e.g PostGIS). Below is a graphic that explains the 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, they'll process 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, it's installed on or connected to a server such as Apache tomcat installed on a Linux machine that 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 web-map libraries such as Leaflet, OpenLayers and displays it beautifully in the browser.
Okay, let's look at it again. Let's assume you want to order a pizza. The first thing you'll probably do is to pick up your mobile phone or your computer, open your browser(the client) and type in the URL(dominos.com). Do you know what you just did is make a request to the server where dominos.com website files are stored? The word "Server" is actually a system too, that's probably in a faraway location from you. The server would return the response in HTML, CSS, and JavaScript files to the client (your browser) since that's the only language your browser understands, it'll read them and display it to you in nice layouts that we see on a website, then you proceed to make your order.
Additionally, while navigating the websites, they're a lot of requests and response operations that happens in the background. For example, when you make an order, the order details and information are sent to the server to get the order processed and packaged for delivery. 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 return a response to the client for display. Sometimes if a request is frequent the response is cached to reduce latency and for a better user experience.
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. Thanks!
This article was originally published on hashnode on Dec 22, 2020.
