Controls and projections in OpenLayers

OpenLayers has a huge advantage as a Web GIS GUI over Leaflet. It can handle any projection, which can be described by Proj.4. Leaflet supports only two projections (the WGS84 and the Web Mercator). These projections are natively supported in most of the GUIs. As Leaflet is a plugin based, modular library, it has a plugin to use Proj.4 capable projections, but it makes a reverse transformation. It transforms the input coordinates with Proj4js from the defined projection to geographic coordinates. OpenLayers on the other side is capable to handle any coordinate system, so the input maps will be rendered in a projection defined by the developer.

OpenLayers layer management

In the previous post I wrote about layer creation. This is only a part of the capabilities of a good GIS application. A good application can also manage layers in an efficient way. Fortunately, OpenLayers libraries have predefined functions for layer management. They provide a great base to build upon and create dynamic Web GIS applications. Some of the basic tasks of layer management are adding and removing layers, changing layer order, listing rendered layers, and changing layer styles. Off course, they have to do it during the workflow, without reloading the page. I will show a few of these functions with a live example in this post.

OpenLayers layer creation

Layers are a core concept in every GIS software. They are collections of contiguous spatial data. You can stack layers on each other, perform an operation on them, style them individually, etc. Fortunately, OpenLayers is outstanding with its layer management. Every raster dataset is contained in a layer. For vector data, you can group features to as many layers as you like. Layers can be accessed, modified or removed after they are constructed. As the layer changes, the map object will track the changes, so it will take effect on the visualization, too. In the following post, I will write about OpenLayers layers.

Getting started with OpenLayers

In the world of open source web mapping interfaces, the biggest and most robust one is OpenLayers. OpenLayers was first released in 2006 by MetaCarta Labs. After 2007, it became an OSGeo project maintained by the OpenLayers Developer Team. It is still under development in these days. The two well-known and widely used branches of this project are OpenLayers 2 and OpenLayers 3. The third version was officially released this year (August, 2014.), and OpenLayers 3.1 has been announced. This also means, that OpenLayers 2 got out of development and the current version is its final form. OpenLayers 3 on the other hand is under constant development, so applications written with it may require frequent maintenance. In return we will get an interface armed with the capability of using up-to-date formats (e.g. TopoJSON), having beautifully rendered maps (WebGL) or in the future providing 3D maps (based on Cesium).

Web mapping interfaces

When you start to develop your web GIS application, the first consideration will be the the interface you wish to work with. There is a wide range of open source GUIs. There are a lot of similarities in them, like they are written in JavaScript (the library which you will use to publish your maps if not the whole software), they use similar sets of values, they use similar methods to reach servers or handle geospatial data. There are lot of comparisons between various GUIs, but in reality there isn't such a thing like best and worst interfaces. Well, maybe there are worse ones, but I won't write about all of them. I will show some of the most popular ones, without attempting to be comprehensive. This post will be a prelude to using these interfaces, showing general considerations and methods to use them.

Map server basics

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.

Apache optimization for a map server

The previous article covered most of the basics installing a simple Apache web server. With a working web server setup, you can make more specific considerations for a map server. There are simpler cases, like what kind of content you would like to serve or what kind of scripts and programs you will need. If you don't want an audiovisual wonder with something like flash, then the content mostly will consist of images and plain text. On the scripting side you will surely need JavaScript and Python. You may use some kind of shellscript on your way to build a map server, but you don't have to put any extra effort in optimizing that part. A bit more complicated list of considerations are, how to optimize the web server itself. You have to choose and set up the best MPM, set up privileges to various directories, choose the modules you have to use and throw away the unwanted ones, all in all, fine-tune the whole system.