Leaflet

Edit: The code below is for a very early version of Leaflet and is not the best way to use Leaflet now. Much has been improved and extended. The range of plugins has grown enormously too.  Take a look at the Leaflet site for more information.

Vladimir Agafonkin announced that CloudMade have released Leaflet, a new open source JavaScript library for displaying map tiles as a slippy map. I've used OpenLayers up to now, so I thought I'd take a look at it.

I have a love-hate relationship with JavaScript. It is great that there is a powerful language that runs in browsers, but the environment it runs in is horrible: DOM, various browsers supporting various features, a fiddly run-time that makes debugging horrible etc. Firebug helps.

I decided that a reasonable test was to reproduce a slippy map page I already have to see how it works with Leaflet. That would help me compare with OpenLayers, but does run the risk of me using Leaflet in an OpenLayers way, which I hope I've avoided. It also only covers a small part of what Leaflet offers, but I seems like a start.

My page needs to display a slippy map with markers on it. A side bar will display details and photo for any marker that is clicked and a small message bar will explain the current situation. To get the layout I used a very simple HTML page and a simple style sheet. I tend to not embed styles in HTML or JavaScript, but to use either IDs or Classes to apply styles and declare these in separate style sheets, sometime more than one. I rarely embed JavaScript in HTML either, other than calling functions in events, so JavaScript goes into separate files too. All of these files are available to download, see the links at the end. The Leaflet JavaScript and style sheet are also included. The map is intended to show the locations and information about a series of sculptures around the City of Hull, as part of the Philip Larkin celebrations. They are no longer in place, but I had the data so I used it.

The first part seemed very easy: display a slippy map. The map is displayed in an HTML div. Ours has an id of map. The code to make the map appear is:

var map;
var hull = new L.LatLng(53.775, -0.356);
function initmap() {
map = new L.Map('map');
var osmUrl='http://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png';
var osmAttrib='Map data © openstreetmap contributors';
var osm = new L.TileLayer(osmUrl,{minZoom:8,maxZoom:18,attribution:osmAttrib});

map.setView(hull,11);
map.addLayer(osm);
}


That is a fairly simple piece of code to display a slippy map. The variables map and hull were defined outside of the function so they are available to other functions as global variables. The single most confusing part is probably the line

map = new L.Map('map')

The first part is a map variable used throughout the code. The second (L.Map) is the leaflet-defined object for a map. This defines how the map object behaves. The last part ('map') is because the div that displays the map has an id of map, which is in the HTML code. The URL includes {s} for the server prefix needed, {z}, {x} & {y} for the zoom, x and y tile coordinate. This allows various tile providers' tile structure to be used.  Now the map needs markers.

Adding markers with Leaflet is very straightforward when you have the longitude and latitude for each marker. However, displaying a map with hundreds or even thousands of markers slows things down a lot, so I like to only add the markers that are visible in the currently displayed part of the map. You can get this by calling the getBounds() method of the map object. This returns the north and south latitude and the east and west longitude that describe the edges of the displayed map. Of course this can change as the slippy map is dragged to a new position or the map is zoomed in or out. So the way to handle this change is to respond to map events. The one which seems to fit the bill for us is moveend. This is called whenever the map is moved, including zooming. We supply a function that is called whenever the moveend event is fired. This is achieved by adding the line

map.on('moveend', onMapMove);

Now, whenever the the map is moved our function onMapMove will be called. In our example onMapMove simply calls the function askForToads() which gets the location of the markers we want. I use this extra layer of functions to make debugging easier.

We still don't know where the markers are to be placed, I do that by using AJAX to request the information about all the markers that fall within the bounds of the current map display. askForToads calls the getBounds() method of our map object, extracts the north, south, east and west coordinates and wraps it up into a call to a PHP routine that finds the list of markers and returns this in a JSON format. This returned list is processed by the stateChanged() function which is called as part of the AJAX process. The JSON provides a neat way to return this data, because simply calling eval on the returned string turns it into an array of, in our case, marker data. I then remove any markers already shown and recreate the new markers one at a time, attaching the data for that marker to a data field and recording each marker in an array (toadlayers.push). Working through the array allows me to delete the markers when the map changes.

You now need to respond to each marker that is clicked. This means that the click event needs to be responded to. This needs the line

toadmark.on('click',markerClick);

to ensure that any marker that gets clicked is responded to by the markerClick() function. Here the details from the data field are displayed in the side bar.

Throughout the process the message div displays messages about the progress of fetching the marker info and how many toad markers are being displayed.

This may seem a lot of work to display the markers, but we are making two substantial changes to the normal system of displaying markers, firstly we are only displaying some markers. If there were thousands of potential markers spread across a wide area this would make the process manageable by only displaying a few at a time. Secondly instead of just displaying a popup we are making something outside of the map div change, which opens up a wide range of actions.

How does this compare with OpenLayers? Most of it is simpler. OL provides an interface to AJAX which makes the process a bit simpler. It also puts a collection of markers together into a single layer which is easier to manage - Leaflet makes each marker independent so I had to keep track of the markers I had added. I like Leaflet, and for many things it is something I will use.

You can find the code examples on github If you want the database definition or even the data I can supply that too. You can see the working example here.

PSMA and open data don't mix

I've been trying to encourage local authorities to consider using openstreetmap for a while on and off. It seems that Ordnance Survey (OS) recognised the growing competition and have forestalled these efforts. Local authorities use maps so much that they often have a dedicated GIS team. They base most of their activities on OS maps, which is not surprising, OS being the national mapping agency of Great Britain. Until recently the local authorities had to negotiate with OS about what products they wanted to licence. However the UK Government announced that this was to change for the current financial year and a new ten-year Public Sector Mapping Agreement (PSMA) was being introduced.

This agreement allows various public sector bodies access to core geographic datasets from OS, free at the point of use. This sounds very appealing to local authorities since they get to use any of the OS datasets included in the core set as and when they want and they don't have to worry about the cost. What could be wrong with that?

Well actually it is a very shrewd move by OS. The money to fund their licences with public bodies mostly came from central government. Most money that local authorities spend comes from central government. Council tax, for example, only covers about a quarter of local authority spending. The Government have naturally taken away the money they used to give to public bodies for OS licences and put it into the central pot to fund the PSMA. OS receive that cash, so they get the same money as ever, but now have much less effort in renewing the licences each year.

The really smart part is the way OS have tied the hands of local authorities into using OS datasets. When local authorities paid for an OS product, if they found a replacement the brave ones could have chosen not to licence the OS data and use the replacement instead. That would have saved them money - a great incentive. Now they get the OS datasets seemingly for free so why look at anything else?

Why does this matter? Well it matters a great deal if you are interested in open access to data from local authorities and other public bodies. If they want to publish information as text or tables they can do as they please, but as soon as they want to display the data as a graphic overlaid on a map their only option is to use an OS map as the background and suddenly they can't release the data as they choose because they are bound up by the draconian restrictions OS place on their map data. The local authority are not likely to use any other form of map, without these restrictions, because of the effort to move away from the seemingly-free OS datasets.

I am sure that for most of their work OS data suits local authorities very well. I'm not well placed to know if the PSMA is good value for money overall - clearly it is not free as some local authorities have claimed. I want to see a viable way of publishing data from a public body in an open way on maps that is not restricted by the licence of another public body, OS. PSMA has made that less likely to happen and has strengthened the hand of OS as a dominant GIS provider.

Another trip into the wolds

The lovely weather tempted us out into the Wolds again. This time around Millington and Huggate. Last time we were in the area a few days ago we got talking to a guy with an expensive HD camera trying to film Red Kites. Today we saw him again. Last time we had rather too long a conversation which seemed mainly to convey just how money he has and actually convinced me that he has more money than sense. So this time we stopped somewhere else to have a drink and were pleased to see and hear a willow warbler.

The roads in the Wolds have very few name boards, even in the small villages. We found a few new, small residential roads that we had either missed before or were new. One thing I did see, which is worth following up on another visit, is the newly signed National Cycle Network trails. I understand that some of the existing NCN trails are having some sections renumbered where there are optional or alternative routes. This however is a newly designated route which I have yet to follow properly.

One of the roads that show up on the OS Locator tiles was Cobdale Lane. Like most of the roads is the area I wasn't expecting to find an hint of the road name, but I was wrong. The name started at a bend in the road and a pleasant cottage was set on the dip and turn in the road. The name of the cottage was Cobdale Cottage. A few hundred metres futher down the road there was Cobdale Farm too. Maybe the road name is Cobdale Lane as suggested. 

Lovely day in the wolds

The rolling hills of the Yorkshire Wolds is close to home and is a constant draw when I want to fill my lungs with fresh air. We went out today for a simple ride out, but I couldn't resist checking a few things for OSM. There's a roundabout near Pocklington that is being built - the road now used the roundabout in part at least. There was a small road that has altered in Shiptonthorpe. The main event today though was the scenery bathed in sunshine. It was about 21°C which is certainly warm for mid April.

We looked out for birds at the spot pictured as we enjoyed some tea. We saw distant red kites and buzzards. I heard a green woodpecker a few times, but it remained stubbornly hidden. I think I'll be back, if only to catch a glimpse of that woodpecker.

More villages and lint chasing

A couple of years ago we added what we thought was the last road to OSM within the boundary of Hull. That turned out to be a bit optimistic, but fairly close to the truth. We have taken much longer to move towards completion of the East Riding of Yorkshire. There is a still a long way to go, with towns like Bridlington and Hornsea still requiring a bit of work and a few largish villages still needing attention. The countryside is pleasant and now the spring is arriving with blackthorn hedges bursting into better shows of flower than I remember for many years.

Recently we have surveyed Beeford and Brandsburton. Both were easy to do, but the difference in the ambiance in each village was marked. Beeford was pleasant, Brandsburton was distinctly odd. The list of villages needing their roads and basic facilities mapping in East Yorkshire is now probably about 40, and some are tiny needing only a brief, passing visit. There are still surprises though. We found a secondary road heading out of Beeford which was not mapped. I need to check if there are any more that need adding in the county.

The process of checking roads has been assisted by the release of Ordnance Survey's Locator data. This defines a bounding rectangle and centroid for every named road in the UK. This has proved particularly useful in settlements since it shows up roads that are newly added in an area since it was surveyed. To get this I use the highly useful transparent tiles that ITO World produce. I added them to my own overlay, which now also includes postcodes at high enough zoom levels. The OS Locator data is also available in OS Locator Musical Chairs.

Like all lint tools there are some drawbacks, the main one being that people are tempted to just use the name from the OS Locator dataset rather than going out to check what is really there. On many country roads there are no name boards and OS Locator is usually right, but even so I prefer to go and look before using the OS name. At this time of year the ride out is always worth it.

Lint tool providers have a duty, in my mind, to be as impartial as possible. They can wield quite a lot of power in the way they chose to flag up errors. Many people quickly adopt the scheme as the standard way to tag and there is a flurry of activity to reduce the 'errors' for their area.  Recently there has been some discussion about the way national speed limits are tagged. I strongly believe that tagging schemes should be designed to assist the surveyors and mappers, but some seem to think that the consumers of data should be treated preferentially over mappers. Here's why I don't agree:

• There are never enough mappers in an area. Attracting them and keeping them is hard. An overly complex tagging scheme means they will quickly get fed up. "All that just to add a speed limit? No thanks."
• Complex schemes mean mappers make mistakes. These are then likely to be 'fixed' by some bot or mass edit. These are not done by mappers who have visited so surveyed data can be lost or changed.
• Mappers must use a tag over and over again, each time they encounter the thing that needs tagging. Complex schemes means adding many tags for one object every time you see it which increases the mapper's workload.
• Programmers write code to recognise and use a tagging scheme once. The map or analysis or whatever that they produce can then be run over and over again with little or no effort, consuming the tags that mappers took hours to add.
• Retrospectively increasing the complexity of tagging for a commonly encountered object, like a speed limit, means you are asking people to resurvey huge lengths of road. If you don't need a resurvey then the increased complexity is not needed as it can be inferred some other way in a program.

One thing I have noticed and has been commented upon elsewhere is that many of the people suggesting that data consumers need this tag or that tag to make sense of the data have never actually tried to used the data in a program. They have no idea what is really involved and what techniques can be applied to get around any problem.

Fairy land

Another string of pronouncements have been made on the Talk mailing list by the ODbL deniers about why OSM should not accept the new licence and contributor terms. Grant despairingly wonders why they should come to these conclusions.

People come to these conclusions because it suits their agenda, not because of the facts. Why let a carefully written licence and all of the discussions that have gone before get in the way of a good conspiracy theory? The world is full of conspiracy theorists and FUD mongers; the fact that OSM attracts them simply shows the project is big enough to attract the cranks as well as the serious.

Some people will always glaze over when confronted with a big blob of words, whether that's a licence agreement or something more important like an explanation of how dangerous radiation is. They then seem to go off into fairy land, inventing fearful scenarios and outcomes that are wrong.  Doing thought-experiments is a great way to test the limits of a licence, but you have to keep checking that you have not exceeded the bounds defined by the licence otherwise you end up in fairy land.

I fully and wholly respect anyone who has an objection to the licence change and who wants to use the CC-BY-SA licence as it is, I just haven't been convinced by their arguments. What I don't respect is the underhand way some people undermine the licence change process by spreading FUD and untruths about what it means and the way the project will work when the change is complete.I support the change to ODbL. I believe it will benefit OSM, but even ODbL is not powerful enough to drag everyone out of fairy land.

HU14

We've been working on addressing close to home. Bing aerial imagery came along and I realised that although Bing is not as good here as elsewhere, it is just about good enough to trace buildings. I traced a few buildings and then took the existing addressing and applied it to buildings. It was much better, so we gathered the remaining addresses for Swanland. I then tried to gather all the addresses for nearby Melton in a day (and didn't quite manage it). Then Blackadder announced he had completed a whole postcode, and I realised that I was more than halfway through HU14, so I just had to polish off North Ferriby. Just! What was I thinking about.

I decided to try Blackadder's scheme of drawing the gardens too. That means working out where the boundaries of private gardens are. This is harder to work out than it may seem. Some are masked by trees, some of the photography is a bit blurry and so on. Then there's the age of the photography - about ten years old. A lot has changed in ten years. I have had to use OS StreetView for a few areas where new housing has been built since the Bing photos were taken. I have tried to represent the differences between hedges, fences and walls as best as I could. I tried to take note of hedges or fences as we wandered around gathering the addresses.  My verdict on drawing gardens: DON'T. It is a pain and makes the difficult job a lot harder.

Gathering the addresses seems a bit easier, it's probably just that we can do it on auto-pilot. I draw the buildings as blanks before we gather the addresses, we can then write on the real addresses as we go round and sketch in any additions. It is still a lot of work. You can see more here.

I'm not doing any more addressing for a while, but I think I will do some more again. The prospect of gathering the addressing for the whole of Hull is overwhelming and would take years.