The fate of this blog

GeoJSON Lite

GeoJSON is one of the most widely used vector formats in the web mapping, and WebGIS world. It has a nice, robust way of storing various feature types along with their coordinates, and properties. On the top of that, it can be parsed as an ordinary JSON object, thus JavaScript has a native support for it. This is the format supported by every client side web mapping library (I have come across so far), thus it is the perfect candidate for testing the feature parsing, and rendering performance of them. However, what is the best way of generating random features in arbitrary numbers? There were two paths I seriously considered:

• Use an existing client side GeoJSON library. There is the NPM package geojson, which could have been a potential candidate. However, writing a wrapper around it, which have a random generator seemed to be as troublesome as writing a new library for this purpose.
• Generate the features on the server side. There is the Python package geojson, which is perfect, as it has a random feature generator. The downside of this path is the involvement of a server. I would rather have a library, which can generate the features on the client side, thus showcasing the results is not bound to a specific server.

By measuring the benefits, and disadvantages of using one of the two methods, I quickly decided to write my own library for this purpose. It is dead simple, small (11.6 KB compiled), and capable of validating GeoJSON objects (based on the official specs), and generating random ones. As a consequence of its small size, and limited capabilities, it is called GeoJSON Lite.

Switching coordinate order in OpenLayers 3

In this post we will discuss a small, but quite annoying bug/lack of feature in OpenLayers 3. Working with WFS was never one of the strengths of the library. It offers some base classes, but you have to build a complete program on it, with tons of considerations. On the top of that, you can't easily declare the axis orientation you would like to use with your WFS request. If you have tested your WFS app with the OpenGeo demo services, you may have already bumped into this problem. Maybe, you are reading this post, because you would like to fix the issue. Well, the good news are, you can fix it manually with some JavaScript magic, but the are also some bad news. You can't implement a simple validating system on it, as it is not version specific. From some GeoServers the coordinates in EPSG:4326 come in reverse order, while in others they are perfect with the same WFS version.

WebGIS application with OpenLayers 2 - Part 3: Data management

In the last part of the series, we will cover data management in OpenLayers 2. It is a quite difficult part, as browsers mostly don't have native support for relational databases. The only exceptions are browsers powered by WebKit. This way, we have to make sure manually, that our data is stored in a consistent way. ASCII geodata formats, which are mainly used in web mapping environments don't support databases. We can store different attributes for every geometry in a layer/dataset. This doesn't seem to be an issue on the first glance, as web mapping libraries can handle object-oriented databases very well. However, if you declare attributes arbitrary, in an inconsistent way, you will have a hard time when you try to process it with a RDBMS. As the server side processing GIS softwares (e.g. QGIS, GRASS, PostGIS) will put these datasets into a relational database, it might be a wise consideration to handle features like they were in a relational table on the frontend.

WebGIS application with OpenLayers 2 - Part 2: Map controls

So far we have created the basic container for a web mapping application GUI. The key aspect in a good application is user experience. This mostly depends on how easily a user can utilize the application, and how smoothly can accomplish a workflow. For a decent user experience, one should think as a user when designing the appearance and mechanics of the application. To make things go right in a WebGIS application powered by OpenLayers 2, the library offers a wide variety of controls. As developers, the responsibility is on us, if we get the most out of it, or not. This is the part where OpenLayers 2 shows its advantages even against its successor. The following post will demonstrate how we can extend our application with minimal programming, and mostly controls offered by OpenLayers 2.

WebGIS application with OpenLayers 2 - Part 1: Layer tree

Creating a whole WebGIS application is a time-consuming task, which can be eased with toolkits, like GeoExt or Heron MC. However, using such a toolkit, has some disadvantages. For example, you can't keep step with the evolution of the mapping libraries, as the toolkits can't develop so rapidly. If you want to use the most recent features, and don't want to wait for the developers of your favourite toolkit to come up with a new version, you have to build your application just on the library.
From another point of view, learning how a web mapping library works can be rewarding. If you build your WebGIS application, you can easily come across a situation, where you have to customize it in a way, that hasn't been implemented in your toolkit. At this point, you will need to learn how to use the native library anyway (and consider yourself lucky, if you don't work with a deadline). To avoid such a case, it is considerable to get acquainted with the library in time and use toolkits later. In the next few posts, I will demonstrate how to build a basic WebGIS application with only HTML, JavaScript, and OpenLayers 2. I will try to summarize the content of the last few posts, and show how to handle browser events with the library.

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.