A bit more cycle route

We discovered a section of cycle route signed with the NCN signs with the number 164. It seemed to be a newly opened route with the number 164. It seems to be part of a route designated the Yorkshire Wolds cycle route, but I didn't understand the numbering system.

We had followed a section from Beverley to South Newbald (see last post), so yesterday we then picked up from there, following the route onward. It headed through South Newbald and through North Newbald before turning up a rural lane called Stoneknowle Hill. The local council started to use a specific style of road sign about a year or so ago, so new signs are easy to spot and this sign is one of them. The road did not have a name tag in OSM, so I was pleased to add it.

The cycle route then leaves the road for a rather stony track, that in wet weather might also be rather muddy. This seems to be the only way of keeping the route off the A1034, which is not the safest road to cycle on. Another short stint on a quiet road and the route then crosses the A1079 - the main road from York to Hull which can be busy and carries fast-moving traffic.

Where did the 164 go?

The route coasts down a quiet road towards the disused railway line that runs from Beverley to Market Weighton which now carries the Hudson Way.  At the T junction under the old railway bridge there was an NCN sign but not for the NCN164, only for the NCN66. I guessed which way to go and followed the signs for the NCN66 towards Market Weighton, but then realised that the signs had the 66 label on them but also Yorkshire Wolds. This is where the confusion lay and I only sorted things out in my mind when I had got home. The cycle route is called the Yorkshire Wolds Cycle Route, but it uses various numbered routes, including the 164, 66 and 1.

The route goes through Market Weighton, climbs towards Londesborough and into Pocklington following the NCN 66, before striking out again on NCN 164 again. At this point it is joined by the Way of the Roses, which is a coast-to-coast cycle route. This is the best part of the Wolds route by far, meandering through the rolling hills and valleys around Millington and up to the village of Huggate. Near Huggate we found a sign for another cycle route, NCN 167, which was signed as going to Malton, but exactly what the route is I don't know, so there's another journey to investigate. The NCN 164 now drops down a long gentle slope to Tibthorpe, which is where we left it to head for home.

Marbled white

Clustered bellflower

The route was very well signed, once I'd understood that it wouldn't be signed with the same number throughout. The scenery in the Wolds is wonderful, with views through the hills and out over the Vale of York and the Holderness plain. We saw some birds, including yellowhammers, linnets, swallows and goldfinches. We watched a marbled white butterfly flutter through the flowers, which included a clustered bell flower.

I would recommend a visit and I really look forward to investigating the rest of the route and the other route too.

NCN 164

Out and about today in Beverley we stumbled on a new National Cycle Route, which it seems has recently opened. The NCN 164 circles the Yorkshire Wolds and has "Yorkshire Wolds" on the the bigger Sustrans signs. We followed a bit of it on a somewhat diverted journey home. I look forward to following some more of it, which seems to be a circular route mostly on rural roads.

If you are interested in a cycling in a quiet, rural space with gentle rolling hills, villages with B&B and pubs and wildlife still to be seen, try the Wolds. When this cycle route is added to OSM it will be worth following, but there are other delights in the Wolds too.

Docks and footpaths

Shepherded between steel fences

Docks and public footpaths don't often mix. The modern dock area has to be secure, not only to prevent theft, but also to prevent unauthorised access to ships for people wanting to make unauthorised entry or exit of the country. The idea of having a public footpath running straight through a dock is a bit awkward, but there is an answer in Albert dock in Hull that is a bit unusual.

The walkway above the warehouse

The first part of the footpath is what you might expect, herded between steel fences to ensure you don't stray into forbidden areas. The next part goes over the lock gates, again carefully fenced to prevent any access to the main part of the dock.

The view along the warehouse roof

Then a surprise as the footpath mounts a steep set of stairs leading to the roof of a warehouse and the path follows a steel walkway along the roof of the warehouse to a short bridge and set of stairs that lead to the footpath along the outside of the rest of the dock. The view out over the dock and the Humber is pretty good but the novelty alone is worth the short walk from the Hull Marina to take a look at the footpath over the roof of a warehouse. You can see the map here.

A rather quiet Albert dock

Albert dock is fairly quiet now, mostly doing small refits on ships, including some large sailing boats. The view over the dock was particularly quiet today, but often there is a ship or two being worked on in there. The reason we revisited was to complete the footpath through the docks because the last time we tried the lock gates were open to allow a large ship out that only just fitted and since the footpath uses the lock gates we couldn't get across.

Crossing or not

I noticed a small change to OSM close to home, so, as usual, I looked to see what the change was. A guy known as Valentijn had added a gate to public footpath and a comment about it being locked. I contacted him to ask about this and following his helpful message I went to see what was going on.

There is a public footpath on a paved track from Dunswell Road to the service road that runs around the Creyke Beck substation just north of Cottingham, as shown here. What Valentijn had found was that the gate either side of the railway crossing was chained and padlocked, and that was what I found too. There were the usual notices that Network Rail put up on unmanned crossings so it looked as though the crossing was intended to be used, but that someone had locked the gates. It seemed to me that the public footpath had been blocked so I contacted the local council.

I got a prompt and helpful reply from an Assistant Engineer (definitive map) who explained that the footpath only went as far as the crossing gates at each side of the railway and that the crossing was a private crossing for a local farm. He sent me a definitive map, but I haven't copied it here since it bears the Crown Copyright notice.

He went on to explain that the farm has had a road built connecting it to Cottingham (part of the work on the substation expansion I suspect) and so the crossing is no longer the main way of getting to the farm. After some incidents elsewhere in the country Network Rail's Health and Safety Team looked at all such crossings and put up gates where the public right of way did not cross the railway. It is entirely clear that the public right of way that no longer crosses the railway is completely pointless, but Network Rail have clearly avoided a serious health and safety risk.

I and countless others have used the crossing for many years with no incident but we have now been saved from our carelessness by the timely intervention of the Muppets the Health and Safety Team at Network Rail, to whom I am indebted for doubtless saving my life.

I have, however, made a useful and helpful contact at the local council and thanks to Valentijn the map is now a more accurate reflection of the real situation.

OS Locator and being thirty years too late

In May the latest Ordnance Survey OpenData was released for OS Locator. This has been turned into something useful by Robert Scott in his Musical Chairs application and ITO World's OSM Analysis. ITO also provide a tile layer which I have used on my site, oscompare. These tiles get used in the editor imagery layers too.

The ideas of these tools is to show the places where OSM road names differ from the road names provided by the data in the OS Locator dataset. They both take a different approach, but both showed that two new roads had appeared in the OS Locator data that were not there before. We set out today to investigate them, and what we found couldn't have been more different.

The first road that OS Locator showed up was Stanmore Close. This area is part of the redevelopment of the Ings Road area of Hull. I have been anticipating needing to survey this area because some of the old council homes have been standing empty waiting for a bulldozer. When we got there we found that not only has the bulldozer done its work, but the builders are in busily replacing the houses. Some of the roads from Mitcham road, which were cul-de-sacs now join Mitcham Road with Camberwell Way. They have names ending in Close, but they are not now a close, however the names stand. I have extended all of the new roads that I could get access to, it looks like a bit more to come yet.

This is by far the best use of OS Locator in my book. It showed me that there was an area of Hull that had changed, I went out to check what had changed and improved OSM in the process.

We then moved to look at the second new road in the city, Garrison Side. This is an area I know fairly well, and I was very sceptical about there being any new road there. As soon as we arrived it was clear that something odd was going on.  The site is close to the place the river Hull flows into the Humber. There was a defensive garrison built there in the seventeenth century, very long since ruined and disappeared. The road suggested by OS Locator would have been along the garrison boundary with the river Hull. A new river crossing over the Hull was opened in 1981 and the bridge cut through the place this road would have been. The photo shows one of the bridge piers slap bang on the place Garrison Side would have been. At the other side of the bridge there is a small remnant of a cobbled street in exactly the right place.

The last time it could have been there was before the bridge was built, so why has this obviously non-existent road suddenly appeared in the latest dataset from Ordnance Survey? If anyone needs reasons to check all the OS data on the ground before adding it to OSM, look no further. In fact if you're looking for Garrison Side you're thirty years too late.

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.