Web GIS Data Flow Architecture

Hello! We’ll start with the blueprint of a web GIS application. Over this course, you’ll build the skills to create its interface, write its server-side logic, store spatial data, and put an interactive map in front of users. For now, you do not need to install anything or write code: the goal is to diagram the parts and explain what data passes between them.

Your QGIS experience provides a useful starting point: a layer has geographic features and attributes, and a map displays them. In a web GIS, those jobs can happen on different computers. The browser displays the map, while servers may retrieve, process, or draw the layers.

The parts of a web GIS

Imagine a website that shows clinics in a city. A visitor opens the site, chooses an area, and sees clinic locations over a map. Five parts matter to our diagram:

• Browser: The program on the visitor’s device, such as Chrome or Edge.
• Frontend: The website code running inside that browser. HTML structures the page, CSS styles it, and JavaScript handles interactions. A mapping library such as Leaflet helps JavaScript display and control the map. Browser and frontend are not two separate servers.
• Backend API: Server-side code that receives requests from the frontend, applies application rules, queries data, and sends a response. We’ll eventually build one using Python and FastAPI. An API endpoint is an address the frontend can request to perform a particular operation.
• Spatial database: Storage for records that include geographic information. PostgreSQL with PostGIS can store clinic attributes and locations and answer spatial queries.
• GIS server: Software such as GeoServer that publishes geographic layers for clients to request. It can read from the spatial database and serve a rendered map image or geographic features.

Read Felipe Limeira’s WebGIS: Architecture, Development, and Applications for an initial view of the request-and-response pattern and the roles of these components. Treat its technology choices as examples, not as a list of languages you must learn at once.

One distinction is especially important: the frontend usually does not connect directly to the database. A request normally goes to the backend API or a GIS service. Those server-side components decide what to retrieve and what to return.

Two ways to deliver geographic data

An API and a GIS server can both help put data on a map, but they need not handle the same request. The clinic application might ask its backend API for clinic records so the frontend can show individual markers and popups. It might separately ask GeoServer for an image of administrative boundaries.

GeoServer uses standard service interfaces for this work. Read the OSGeoLive overview, paying particular attention to the difference between an image and geographic features.

For this first diagram, remember just two service names: WMS typically supplies a rendered map image, whereas WFS can supply geographic features for a client to use. You will work with these services much later in the course.

The following illustration shows clients on one side and server-side components on the other. It includes QGIS as a possible desktop client; in our clinic website, the relevant client is the browser-based map.

Draw the application boundary

Here is our working architecture diagram. The connecting lines show which parts communicate; the labels name the data exchanged. A request travels from the frontend to a server-side component, and a response returns along the same connection.

                  VISITOR'S DEVICE
        +---------------------------------------+
        | Browser                               |
        |   Frontend: HTML, CSS, JavaScript,    |
        |   and a Leaflet map                   |
        +---------------+-----------+-----------+
                        |           |
             HTTP: clinic request   | HTTP: layer request
             JSON/GeoJSON response  | WMS image or WFS features
                        |           |
              +---------+----+   +--+-------------+
              | Backend API  |   | GIS server     |
              | FastAPI      |   | GeoServer      |
              +---------+----+   +--+-------------+
                        |           |
                 Database query     | Published-layer data
                        |           |
                        +-----+-----+
                              |
                    +---------+-----------+
                    | Spatial database    |
                    | PostgreSQL + PostGIS|
                    +---------------------+

The browser must first receive the frontend files—HTML, CSS, and JavaScript—from a web server or hosting service. That file-delivery step is omitted from the drawing so we can focus on what happens after the page loads. At that point, JavaScript in the browser can make further HTTP requests for map data.

Notice the branch: a clinic request can go to FastAPI, while a map-layer request can go to GeoServer. A request does not have to pass through both. Both server-side components may read the same PostGIS database, but they produce different responses for different purposes. Not every web GIS needs a separate GIS server; it is part of this diagram because the course will later integrate GeoServer.

Follow one visitor interaction

Suppose the visitor pans the clinic map to a new area. Here is one possible exchange, written as a sequence rather than as another diagram:

1. JavaScript in the frontend notices that the visible map area changed. It sends an HTTP request to an endpoint such as GET /api/clinics?city=Pune. The address and city parameter tell the API what is being requested; they do not themselves contain clinic records.
2. The backend API interprets the request and queries the spatial database. The database returns matching stored records to the API—not directly to the visitor’s browser.
3. The API packages the result as a response. One useful format is GeoJSON, which can contain both a feature’s location and its properties, such as a clinic name.
4. The frontend receives the response and uses its JavaScript map code to display clinic markers and popup information.

Separately, the map may request a boundary layer from GeoServer. GeoServer reads its published data source—possibly that same PostGIS database—and responds with a WMS image. The frontend displays that image as a map layer. If the frontend needs the boundary features rather than a rendered image, a WFS request is another option.

This explains why “the map came from the database” is incomplete. The database stores data; the API or GIS server retrieves and prepares it; the frontend receives a response; and the browser displays the result. QGIS can help you prepare or inspect a layer during development, but a visitor does not need QGIS installed to use the finished website.

For a hands-on check, sketch the clinic architecture on paper. Put the frontend inside the browser, place the API and GIS server in separate boxes, and connect both to PostGIS. Label one browser–API connection “request / GeoJSON response” and one browser–GIS-server connection “request / WMS image response.” That sketch is the foundation for the applications you’ll build later.

What to carry forward

You should now be able to identify the five parts of a web GIS and trace a complete request: a browser frontend asks for data, a server-side component obtains it—often from a spatial database—and sends back something the frontend can display. The backend API commonly returns application-specific data; a GIS server specializes in publishing geographic layers. They can work alongside each other without every request passing through both.

Next, you’ll begin the developer setup module’s practical tools by navigating files and folders in Windows PowerShell. Those skills will let you create and organize the frontend and backend projects shown in today’s diagram.