Choosing WebGIS full stack architecture

Question

I need to build a WebGIS service. I work in Linux platforms with open-source software.

I have some experience of GIS now (PostGIS, QGIS), but GIS web publishing is new to me, although I have some previous experience with non-GIS web servers (Apache/Tomcat, html / Java / MySQL).

---

The roles of the various components of a WebGIS full stack are still not very clear to me and I am still looking for good web resources that explain it.

This Wikipedia diagram is still the best explanation I found so far. The roles of the various components of the WebGIS stack, as I understood them so far, are :

• The database holds the data (or it could be just files : .shp, .geojson, .gml,.kml, ...)
• The application server, also called web framework, in a programing language like Python or Java, provides services such as templating so that the web pages content is dynamicaly altered. This includes the user control. Examples: Django, Ruby on Rails.
• The HTTP server (Apache, Nginx ....), in response to HTTP requests from the user, serves the web pages items : HTML, CSS, images, etc ... These items are either static or dynamic, in which case they are provided by the application server to the web server.
• The client-side libraries (OpenLayers, Leaflet, ...) do the actual work of displaying the maps in the web browser using data sent by the HTTP server.

But now, where does GeoServer fit in this ? What does it do exactly ? I believe it transforms the GIS data into other formats suitable for web publishing (WMS / WFS / etc ...). But how does this integrate with the database, the application server, the HTTP server and the client-side libraries ?

In understand that MapServer and QGIS Server play the same role as GeoServer ? So I guess you choose one or another ?

---

Choosing my components :

The GIS data I must publish on the web is first prepared on an existing offline server with a Postgreql/PostGIS database where it is processed (a lot of GIS calculations). Once it's ready, it can be Extracted-Transfered-and-Loaded into another server that will take care of the web publishing.

It is this web server I need to set up now. I have a single map with a single layer with about 200,000 features right now and it will probably expand up to 1 million in the future.

The web site ought to have certain key functionalities :

• Strong user control : users must be registered and authenticated. Also, their actions must be logged. We also need a control of to which GIS data users have access and log it.
• The users must be able to user filters on the Features displayed in the maps. The database has already been designed to easily perform efficient SQL queries corresponding to the different possible filters.
• Each Feature must be linked to a specific web content (i.e. : the user must be able to open a page that displays a detailed content for each feature).

So far, I have been working with the following components and made the following choices :

• The data store for the web server is a Postgresql/PostGIS database. It seems an obvious best choice.
• The ETL is a Python batch system. It uses the ORM from the application server (Django) to feed the web server database.
• The application server is Django. I have set up GeoDjango with Leaflet for the admin part of the web site and it works fine but this is only because, in the admin side I only need to display a single feature at the time on the map. My attempts to use Leaflet by serving it all the 200,000 features in GeoJson at once proved it is not a viable solution (really, really slow ; almost crashed down the computer).
• The GIS data should better be served as WMS (or WMTS ?) rather than WFS because of the concern for controlling and logging what the users see and have access to ?

Please note that I might change one of these components for something else if I am convinced it is the right choice, but that would mean throwing away weeks of work, so I'd prefer if I can keep them.

My understanding is that I must now :

• add a component like GeoServer / QGIS Server / MapServer but I don't know which one.
• make this component work with the application server (for user control, as stated previously).
• also pick up an HTTP server and a lient-side library and also make them work with that.

Answer 1

In the end, what I did was :

• Set up a WMS server (QGIS server).
• Use Leaflet on the client side for displaying the map (WMS overlay layer and the background layers - Google Maps, OpenStreetMap) in the browser.
• Use Django as a proxy for the WMS server : the queries from Leaflet are hence sent to the Django server who does the user authentication and rights controls before sending forward the query to the WMS server, which is otherwise not visible for the client.

Answer 2

Yep looks good. Geoserver is probably a bit more mature than QGIS server and may give you a bit more robustness and flexibility for scaling/load balancing etc etc. But I haven't implemented QGIS Server at scale yet, so my opinion is a bit speculative.

Leaflet is pretty good client tool as well and is my preference over Openlayers, or others. But again - thats just personal preference!

WMS essentially gives you simple map and single feature query capability....... WFS will give you editing/multi-record querying, etc, StackExchange Article here - they used your same diagram as well!

With regards to your diagram, it suggests that all access to the datastores must be through the 'middleware' so to speak. This isn't necessarily always 100% true or required. An alternative architecture approach would be to implement client side mapping with direct access to the database. A good article here Client side mapping

I have seen a similar approach using slightly different programming languages, where the SQL requests are made using python, which is wrapped up to be exposed via javascript - which ties in nicely with your Leaflet.js. Neat stuff aye!

Alternatively, why not have both! You could combine the above approach I mentioned, with a Geoserver implementation. Geoserver could handle simple WMS and maps, whilst your embedded SQL-in-python can handle complex client database queries (like searching or data editing). Personally, in my opinion, handling data transactions through Feature services - especially large data editing - is fraught with problems.

All of the above depends on your business requirements of course.