Here you can find a simple demo showing GBKN/topographical data of a part of Weesp, The Netherlands.

The demo is a show-case for three key points:

1. The demo is fully client-side with regard to data-processing;
2. A GBKN/NEN1878 file is read and parsed in the browser itself;
3. A map, with scales and different styles for the objects, as usually seen in a GIS-application, is built.

In point 1, the web-server only serves (uploads) files and does no processing. Usually, you see solutions where a map is pre-generated at the server as images. These images are then uploaded to a client through, for example, WMS. Or in other cases, the features (things you see on the map, with additional attributes) of the map are sent to the client in a format such as GML, by use of WFS. In this case, the client downloads a GBKN file (in the NEN1878 format) and parses this file.

For point 2, the Client has GBKN data downloaded (see point 1) and uses the JavaScript-library nen1878reader to parse the GBKN data. The GBKN data is transformed to GeoJSON features. These GeoJSON features are then fed to OpenLayers; see point 3.

Note that the nen1878reader library is used for more projects. In another project, the GBKN data is parsed and directly fed to Oracle with Oracle Spatial. In turn, this database serves as a base maps source ESRI ArcGIS.

For point 3, OpenLayers is used to display the map. The only data visible in the map are the features found in the GBKN data file. In OpenLayers, several layers are created to hold the different features. Each layer can be turned on or off.

You can use your mouse to pan around the map. Use your mouse wheel to zoom in and out. Click on the little + on the right to expand the layer-overview.

Unfortunately, OpenLayers does not seem to support the rotation of text-features. In the map, labels can be overlapping, while this usually is not the case if the map is rendered according to the GBKN specifications.

The plus side of doing this on the client is that the client does all the hard work. The web server does not have to perform any geo-spatial operations as would be the case in a WFS server. This relieves the server of doing some of the hard work.

The down side of doing this on the client is that the client becomes ‘fat’. The client needs to do all the things. On a slow client, such as an older smartphone, this can be a daunting task. Fortunately, on most tablets and smartphones, this is no longer a daunting task due to the ever-increasing processing power.

Also, when different clients for different platforms are required, multiple clients have to be developed. Fortunately, HTML5/JavaScript is becoming better adopted every day on the different mobile (and non-mobile) platforms. Using HTML5/JavaScript, the client now only has to be developed once.

At loading time, the whole map is transformed and added to OpenLayers. This is not a realistic thing to do when the map covers a city, or even a whole country. The clients' browser will be brought down to its knees.

To keep the server light, a different approach can be taken, however. As you can clearly see in Google Maps, areas are split up in different tiles. We can use this technique to create ‘feature-tiles’ which will hold the features for that tile. Using this technique, we can still keep the server light while the client never needs to hold too many features in memory at once. KothicJS already seems to support this technique.