A shallow dive into Web Map Servers
I am sure you have used Google Maps/Apple Maps or any other map utility at least once. More experienced readers might have built such utilities with services such as ArcGIS, OpenStreetMap, Google Maps API etc. These services are examples of Web Map Services. In this blogpost, I have tried to throw some light into this amazing class of softwares which power majority of maps on the web.
Web Map Servers
These are servers which specifically serve/handle Map based interaction with the user. Some of very intuitive functionalities include
- serving updated map when user pans/zooms the map.
- serving geographical coordinates in (latitude/longitude) form when a local (x/y) coordinate is given relative to the map.
- draw a line on the map marking your path to a coordinate
For most sections of the blog, we can refer to MSS’ wms.py which can be taken as a superficial template to understand Web Map Servers.
Unlike other web services, the interface of an WMS is defined by Open Geospatial Consortium in WMS standards document available here. It’s necessary that the WMS you develop should comply with the rules mentioned in the document. The standards were made to ease the development of WMS and map clients by making them independent of each other. Following description is a prelude to ‘WMS standards document’.
Components of WMS
Following are some important components of a Web Map Server.
GetCapabilities
This is a service used as the first interaction between a Web Map Client and Server. Here is an example of a GetCapabilities request result. If you look closely, GetCapabilities’ result gives metadata about the WMS and the services it offers. Some important tags one can explore are the following.
shows the different types of requests we can make to the WMS. shows different layers the WMS can handle. ( Layers can be described as distinguishable features in map, for example forest cover, and demographic data can be stored in different layers. Read more about layers here. represent various Coordinate Reference System interpreted by the WMS - <EX_GeographicBoundingBox> represents the gepgraphical boundaries of a layer. If a GetMap request is made for area out of this box, it will lead to a 404 error.
GetCapabilites in MSS is implemented here.
GetMap
After GetCapabilities request, once the information about different layers and bounding boxes are saved, the client can query for maps. A dummy request has been made here. Some important parameters are as follows:
- Layers: List of layers to be present in the output image. (One can experiment this by verifying this link that by removing ’nationalparks’ from URL gives a different layer.) The map image is dynamically generated in the WMS after parsing the request queries
- CRS: The coordinate reference system.
- BBOX: This is the bounding box of the map queried to the user, this depends on CRS and coordinates of the places. Read more on BBOX here
- There are other self explanatory parameters like width, height, type of image, etc.
GetMap in MSS is implemented here.
Other
There are other type of requests like GetFeatureInfo(Information about a point in a particular layer, corresponding to a particular point), GetVSec(Get 2D images or sideview of a topography, used in atmospheric/pedology research), GetLegend(Get legend image describing icons and other short representation of features, scale), and many more which can be referred externally.
GetVSec is implemented in MSS here. 
Notes and References
These are the core concepts to build a WMS, however a lot of work is to be done to design data-storage, map construction, network I/O, etc. It is recommended to use publicly available map servers, if the usage is experimental, building a WMS is preferred if your usage is customized and used for production.
Following are list of publicly available WMS
Here are implementation of some sample WMS in Python:
The following documents can be referred for a better understanding of WMS and other Map related services mentioned in the blog.