If you would like to build your own map server, you have to think it through carefully first. Do you need a complete map server or you can stack with an existing one? Is Google Maps good for you or you need more control on your maps? There are several options on the internet and with some of them, you just have to write a brief JavaScript code and voilà, you have a well-visualized map. In the next few articles I will show some options which won't need an independent map server, but learning at least one of them will be inevitable if you have to build one.
The meaning of WMS and WFS
In web GIS, it doesn't enough if one just uploads some kind of geospatial data. The datasets will be used by clients and must be prepared to be accessed by some kind of visualization and/or data management frameworks. There are a wild palette of geospatial formats out there and it wouldn't be effective if the frameworks had to do all the work. The OGC (Open Geospatial Consortium) came with the solution with writing standards on how to serve geospatial data. They have a broad list of standards, but only the WMS, the WFS and maybe a little later the WPS standards fit in the scope of this blog.
The WMS (Web Map Service) is the standard for publishing raster datasets. The two basic tasks a WMS server must handle, is answering a GetMap and a GetCapabilities HTTP request. The GetCapabilities function handles the properties of the map server and handles them out in an xml format. You map server states the layers, the rendering options, the query options, the extent, the predefined zoom levels (if you have any) and all kind of other optional options your server can handle. You can manually ask any map server's capabilities with the URL: www.somemapserver.com?request=GetCapabilities. The GetMap function gives out the tiles you have requested with your favourite visualization framework. Your framework will make the proper request for you with your- or with the default options. An average GetMap request is a few lines long, so there isn't any sense in typing it manually.
WFS (Web Feature Service) is a little bit more complicated. A WFS server must provide feature data in some kind of ASCII format (some of the popular formats are GML, KML, GeoJSON, WKT). It must respond to the basic GetCapabilities request and besides of that, the feature database must be queryable with XML or KVP (key-value pair) requests.
All things considered, WMS is the standard for publishing raster data, while WFS is the standard for publishing vector data. Fortunately map servers are created to handle all these data and provide them properly for the users. You can define which version of these standards you want your map server to work with, then it will do the rest of the work.
Structure of a map server
There are three vital and one optional part of every map server. These parts are layered on each other. The outermost part is where the user communicates with the server. This is called GUI (graphical user interface). There are several frameworks to create user readable maps from datasets of map servers. The GUI's main task is visualization and with a simple GUI, you can do most of the work. You can draw base maps, overlays, markers and some features. You can use custom styles and events to make beautiful and dynamic visualizations. There are only a few exceptions where you need a separate map server storing geospatial data locally. Some of the most popular GUIs are Google Maps, OpenLayers, Leaflet, Mapbox, GeoExt. In the next few articles I will show how to use the API of these GUIs and make some basic maps.
The next part is the optional layer, called tile cache. Tile caches are tend to be used with raster datasets and they have two main functions. The more obvious function is to cache the most widely used tiles or extents (future link here to future post explaining) so you can make free system resources and your server won't overload so easily. The less obvious function is to hide your geospatial data from accessing directly. This can be a great security consideration to make sure, no one will overload your server with an endless loop in their code or just for fun. Most of the map servers are capable of caching tiles, but there are standalone programs for this purpose, too, like TileCache or MapProxy.
The third layer is the map server. They can render raster and feature data to various formats satisfying the WMS and WFS requirements. They can handle a wide variety of inputs from GeoTiff to Shapefiles and convert them to GUI compatible outputs like png or GML. They have a capability to assign styles and filters to their outputs. The smoothness of the outputs depends on the map server used by the process. Some of the most popular ones are MapServer, GeoServer and Mapnik.
The last layer in a map server is the geospatial data itself. Their format depends on the usage of the map server. It is a healthy consideration to use consequent data types and not to mix them. There are conversion tools available, like ogr2ogr, gdal2tiles, imagemagick, etc. This layer is a must have and you have to take care of it particularly, when you use a DBMS (database management system) to store your data, like PostGIS or SpatiaLite.
For further details please read the following articles:
P. Smith: Take Control of Your Maps, 2008.
L. Hsu - R. Obe: Integrating PostGIS in Web Applications, 2010.
No comments:
Post a Comment