How to Manage a Map Server


An overview of the issues involved in managing a Map Server

There are a number of components that make up a map server.  It is important that you understand what you re dealing with in order to make good management decisions.  This article is a bit long, but it is important to understand these issues.  If time is limited, a few critical sentences are in bold.  Read them. 


Multiple Servers

First you may already have multiple servers, and be reluctant to manage another one.  Sadly in the corporate IT world, it is a normal thing to have multiple servers.   There was this excellent video about distributed CMS.

And his book.

And his free blog:


The Hosting Provider

I am a huge fan of  Sure FreeBSD is more secure, but the world has standardized on the less secure and hard to upgrade linux, so lets go with an ISP that supports Linux well.  I recommend Linode (starting at $5.00 / month) Linode has nightly backups (Starting at $2.00/month).  Their backups have saved me many times.  .  Their tech support is quite brilliant.  I will admit that Digital Ocean has better documentation, but reportedly their backup only runs weekly.  And to save costs, their servers share parts of the operating system, so you cannot upgrade it.  That is a securiy vulnerability.  Most sites do not care.  but if you are running a server challenging power structures then you should care hugely about security. 


Docker is a packaging technology for software.  In traditional linux software packages could conflict, docker puts them all in their own package.  In particular these mapping servers are written in Python.  Python is included as party of linux, but usually the system version and hte mapping version are different.  And the maps install a ton of Python libraries.  To keep all of that clean and separate, it is good to use Docker.  Then when a new software release occurs, it is easy to upgrade.  

Of course Docker is a bit painful for the developers.  It slows new releases.  So I tend to do the development and testing on my servers, and only when it is ready to go, release a new docker container. 

The Forest Wiki

The mapping docker containers are called the Forest Wiki. There is a lot of great software in here, written by some very smart people.  You will never see most of it.  You will just find that when you need a change, it happens quite quickly.  When Alex just wanted the map content, and not the whole page, the correct URL for that already existed.  A few minutes later and by appending ./wp-content to any page, it had the right libraries, and could be imported into a WordPress site.  But he decided to use iFrames, so a few minutes later, ./html-content, gave him pages which were properly structured html pages. 

The Forest Wiki is a complete content management system.  Organizations can manage their own pages, secure from the other organization's changes. Email notifications are included.  Google Sign ups are included.  Accessing a map tile database is included.   One can see the most recent changes.  One can use a slider interface on cell phones. YouTube videos are supported.  State maps are about to be supported.  That took about 2 days work. 

Web Server

Caching Web Server

Python is hugely flexible software, but it is a bit slow.  If your site is going to have a large amount of traffic, you need a caching web server.  There are three caching web servers you could use.  Apache, NGINX, and Caddy. 

Apache was the first web server. It used to be the leading web server.  It's named this way, because it was built by patching previous versions.   I have used it.   I find it hugely painful to configure.  Which means it wastes developers time.  

NGINX is the current leading web server.  It scales much better than Apache.  It has a simpler model.  Apache does everything, Nginx just does file and port serving.  The Russian author just sold it for $700 Billion, then got arrested and put in jail, presumably for not sharing the profits with the appropriate people. 

Caddy Server is the newest web server.  Written in the hot Go language.  It is trivial to use.  More importantly, it does a lot more than Nginx.  In particular it manages lets encrypt certificates painlessly. 

So the caching web server has a difficult job to do.  For anonymous users, it has to return the cached results.  For logged in users, it has to recognize a login cookie, and pass them on to the mapping server to custom render a page, based on the logged in users permissions.   Configuring this functionality in Caddy is trivial.  I can include the  caddy server in the docker container, but it likes to live on port 80.  Configuring it in NGINX, I have the code for.  I have no idea how to configure this in Apache.

Lets Encrypt. 

 The mapping server requires Let's Encrypt certificates.  It is a CMS, people login.  You do not want the login credentials to be transmitted in the clear.  It is possible for the map server to include the caddy server, and generate its own Lets Encrypt credentials, but for that it needs access to port 80.  

Map Tile Server

To display maps, we need a source of map data.  Google maps is the leading map vendor, the software does support google maps, but it has a number of problems.  First of all they track everyone who uses the maps.  Not good.  Then they are starting to get quite expensive, and worse yet their API is so complex to use. 

Better to use OpenStreetMap.  The software is called Leaflet.  So easy to use, even for clickable state or country GeoJson boundaries.  The software is provided by MapBox.   One just needs a MapBox account and a license key.  

Google  Login

The map servers are content management systems.  People can login .  Currently it supports Google Login. Google confirms their email address, and presumably limits attempts on brute force password attacks. But to use the Google login,  a map server needs to be registered with Google.  Google site verification is easy to do.  Getting OAuth credential is a bit tricker.  One needs a privacy policy, and terms of use.  Make sure not to submit a logo, or they take forever to confirm it. 

Bottom Line

In a resource limited organization it takes a long time to get all of this mapping server management right.  You really have a range of choices. 

1. We could run these docker containers on your servers, and hold off on putting them in production until you figure out how to configure apache correctly. 

2. We could use a completely separate mapping server.  It is quite easy for me to set up a Linode mapping server for you with everything.  I just need a Linode account, a mapbox account, and domain pointed at that Linode server.  Strategically I am very interested in packaging this software as a Linode One Click App.  In the long run that is the easiest for you to administer.  Lots of Green parties will want their own mapping server.  But you may not like this approach. 

3. Some middle ground.  We can negotiate something in between these two extremes.  

Anyhow, this is what you need to know for the next phase in this project.  Back to getting the details fixed.