Before getting started

In the previous chapters, we discussed the HTML and CSS parts quite thoroughly. From now on, we will focus on the JavaScript part of the application. We will use native JavaScript (no jQuery, ExtJS, or other libraries) to build our application. This way, we will have a better understanding of the native language, rather than a library's abstraction methods. Eventually, our code will be more verbose, but this is a price we are willing to pay in order to gain better insight into JavaScript.

Using a proxy

For this chapter, I have adapted a simple Python proxy file to use from the one made by the OpenLayers Contributors for OpenLayers 2. As we will use AJAX requests to fetch features and metadata, we can easily bump into real CORS restrictions. These restrictions can only be resolved by a server-side proxy script, which requests the data from the target server and forwards it to us. From this moment on, the data will be from the same origin as the proxy script on the same server, which is similar to our application.

To use the proxy script, we will need two things: a Python interpreter and a running web server. If you don't have both of these, you won't be able to use the proxy. In this case, you will have to use a map server, which allows CORS requests.

Tip

If you've used a Python server before, it won't be sufficient now. We need to access a CGI script; therefore, you have to start a different Python server. If you use Python 2, you can create CGIHttpServer. With Python 3, you just have to start your server with the --cgi flag.

If you have a web server and Python installed in it, you can find the proxy file in the code appendix as proxy.py. Copy the file into your server's cgi-bin folder. Note that you may have to modify the relative paths in the examples that are based on your server's layout.

Note

If your web server is public, don't use the proxy script! It is a dead simple script without any validation, sanitization, or security checks. If people can access your server from the Internet, they can use it for bad purposes, and as a consequence, charges can even be brought against you.

Resources to use

Through the examples used in this book, we will build a complete GUI for layer management. This involves adding layers from different sources with the help of forms. As some of the forms need valid resources to work with, called map servers, we will need some URLs to test our application on. The two most common open source map servers are MapServer and GeoServer. They have slightly different semantics that need some consideration when we automatize the data requesting process. We will use the following demo servers, layers, and projections for testing purposes:

• For WMS, refer to the following:
  • http://demo.opengeo.org/geoserver/wms (GeoServer without the CORS restriction)
  • http://demo.mapserver.org/cgi-bin/wms (MapServer with the CORS restriction)
• For WFS, refer to the following:
  • http://demo.opengeo.org/geoserver/wfs (GeoServer with the CORS restriction)
  • Layers: topp:states and osm:water_areas
  • Projection: EPSG:3857
  • http://demo.mapserver.org/cgi-bin/wfs (MapServer with the CORS restriction)
  • Layers: cities and continents
  • Projection: EPSG:4326

Note that these demo servers are made available for use free of cost by Boundless and the University of Minnesota Twin Cities. Respect them by using their servers responsibly and not exploiting their services.

Basic considerations

The layer tree will consist of two parts: the layer container with the layer elements and the control buttons. The buttons will be responsible to add and remove layers. The layer container will contain the layers in reverse order, which are as usual in the GIS software. Some of the layers' attributes will be ported to the elements, giving us the ability to change them through the GUI. The layer tree will have a reference to the map object and message bar, giving it the capability of making changes in the map and notifying us of every significant change.