UK Ordnance Survey Map With Draggable Features

This demo is created using OpenLayers v3.8.2 unaltered from original but loading the script from own server, because later versions appear to be broken.

The former OL2 demo is here: UKOSOpenLayers2.shtml.  You can also load an OS map with Ordnance Survey's OpenSpace, currently based on OL v2.12, here: UKOSOpenSpace.shtml.

Help

This section describes how some of the less obvious interactions work, in particular that there are two that select objects, and one that drags them.

You can select objects using either an ol.interaction.Select or an ol.interaction.DragSelect, the former being unaltered from the OL original, the latter being a custom extension of ol.interaction.DragBox.  The former has the multi option enabled, which means that you can select multiple objects by Shift clicking.  The latter is invoked by Shift dragging.  The former selection is cancelled by clicking anywhere in the map outside of a feature, the latter by Shift dragging anywhere in the map outside of a feature.  It's important to understand that the collections of features so selected are now properties of the interaction objects themselves, not of the layer or the map, and consequently are different selections.  This can get sufficiently confusing to the user that an end-programmer may decide that, although both are included here for demonstration purposes, only one or the other should be used in production, not both.

Features are dragged by an ol.interaction.DragVector, which is an extension of ol.interaction.Pointer.  Where no objects are selected as above, a simple drag drags just one feature, but if Shift is applied all features beneath the start point of the drag are dragged together, while if objects are selected as above and Alt is applied, both the above selections will be dragged.  This latter is achieved by the above two interaction objects being parameters to the drag interaction's constructor.

OL 2 & 3

These are some observations on both versions, and the difficulties upgrading from 2 to 3.

The first non-obvious thing to note is that, while OL2 loads its own stylesheet in the background transparently to the end-programmer, OL3 expects the end-programmer to do this explicitly by including a suitable <link> tag, for example:
     <link rel="stylesheet" href="http://openlayers.org/en/master/css/ol.css" type="text/css">

All official OL3 examples that I've seen load other CSS and code from elsewhere, and this tends to obscure what is actually necessary to make a given example work.  (Actually, this is particularly hypocritical of the team, in that I know from sometimes exasperating experience that if I were to submit an example of a bug in such a manner, the very first thing that would happen is that I would be asked to simplify it!)

Probably the main advantage of OL3 is that its code is more compact, though how much of that saving is due to genuinely better coding and how much is due to more functionality being left for the end-programmer to provide is perhaps debatable.

Openlayers File Sizes (KB)
 DebugLiveLive (zip compressed)
OL22,874753220
OL33,654461154

A further advantage of OL3 is that initial impressions suggest that its encapsulation is improved.  To those who understand these things, one of the notable weaknesses of OL2 was that, despite having an OOP design, in places its encapsulation was poor.  By this, I mean that some of its code had 'spaghettified' across objects, and, where this was so, making bug-fixes or enhancements was intricate and difficult because desirable changes to the behaviour of one object tended to cause undesirable changes to that of others.  The handling of projections and the button controls were both examples of this.

However, a major disadvantage of a total rewrite such as OL3 is that almost everything has changed beyond recognition.  Even the most basic, fundamental objects either no longer exist or have changed in name and properties between OL2 and OL3.  Consequently, in upgrading, you should expect a wearisome rewrite of your entire codebase.

OL3 is based upon Google's Closure Library, which compresses code to a far greater extent.  While this has some advantages, for example the reduction in code size described above, it also has some serious disadvantages, the most notable of which is that items that would have been 'in the clear' in OL2 are name-mangled in OL3, and, as will be explained, this has negative consequences for the bug-fixing, extensibility, and the open exchange of techniques that should arise from Open Source software.

Firstly, the end-programmer must ensure not to rely on serendipitous discoveries from examining the debug code, because subsequent testing may show failure with the live script, where most of the property and method names are mangled.

Further, if there is a mistake or lack of foresight in the design of an object, it cannot easily be fixed or enhanced by end-programmers wishing actually to use it.  Several examples of this were found in creating this page, of which I shall use the scaleline and mouse-position controls to explain such problems in greater depth.

To those who were familiar with the problems of the scale and scaleline controls in OL2, it is ironic, but perhaps not particularly surprising, that, at the time of writing in July 2015, there is also in OL3 a minor error in the calculation of the width of the scaleline control.  What is it with OL and scales?!  The problem is that it ignores styling that may be applied by the end-programmer.  Briefly, the control consists of two nested <div>s (this author can't see any need for the outer) and sets the CSS width property of the inner.  However, although in the OL3 example the default styling in ol.css creates a 1px border around three sides of the inner <div> to create the scaleline, and with this default styling the scaleline does display correctly, the documentation allows for end-programmer styling, which, if actually applied, would often cause the calculation of the width of the scaleline to be in error, because it doesn't take account of the possibility of either a thicker border (2px is about right on an average desktop monitor, but the calculation is then 1px in excess, and a mobile phone or tablet may be different again) or left or right padding (which will increase the error still further by the sum of the two).  Also, there is nothing to stop the end-programmer choosing to style the border of the outer <div> rather than the inner, requiring a different calculation again!  The CustomScaleLine control in this page's source corrects the former version of the problem, but the inaccessibility from child objects of the name-mangled properties of parent objects makes it something of an ugly kludge, as this author would be the first to admit.  Really, the scaleline control needs to be simplified to use one <div>, and its width calculation corrected to accommodate padding and border thickness.

One of the problems with the MousePosition control is that the function handleMouseOut is documented as @protected, which, depending on programming language, implies some level of accessibility to child objects, but in fact it is name-mangled.  This has two unfortunate consequences, firstly that should an end-programmer write an enhanced function with the clear name, it will never be called, because the listener has been fed the mangled name rather than the clear name, secondly that if nevertheless the end-programmer adds a listener to call the new clear name version of the function, it is not possible to call the parent version from this child version, because its name is mangled!  Effectively, it is no longer possible in OL3 easily to have the control display the map centre when the mouse is outside of the map, as is this author's preference.

I will also mention that this demo doesn't use ol.control.Attribution to display the required Ordnance Survey copyright message, because the result is pig-ugly.  Instead it uses a custom Title control, but for more general use it should be noted that without extra programming this will not maintain a selection of attributions depending on and appropriate to the layers that are currently visible on the map.

In summary, while OL3 is more compact, and probably better encapsulated, for this author these fairly minimal advantages over OL2 do not yet justify, nor are expected to justify any time soon, the major coding effort involved in upgrading even the few pages on this site that currently use OpenLayers.

Updated Description
08/01/2017 Fixed OL3 version to 3.8.2 loaded from own server as later releases have proved highly unreliable.  Added CSS styling for ol.interaction.DragSelect for upward compatibility with later versions.  Corrected typos.