Ignite London: Crowd Sourcing a Map of the World

Almost two weeks ago, I gave a talk at Ignite London about OpenStreetMap, titled "Crowd Sourcing a Map of the World". Ignite's presentation style is 20 slides which automatically advance every 15 seconds. Having never done this before I actually wrote the whole talk out. The presentation that I gave slightly diverges from this but I thought it'd still be good to reproduce here. I did add some links to more information, and if you want to see the recording, you can find it at the end of this post.

1. This talk is about a project, started here in the UK with as its major goal to create a free map of the whole planet. From roads and motorways to country-side footpaths, restaurants and of course pubs. This talk is about OpenStreetMap, the free map of the world.

2. There are of course already plenty of mapping solutions available. Maybe one of the best maps can be acquired through Ordnance Survey. They can be regarded as the national authority on this subject. It's however expensive to get access to their maps, especially the very detailed maps from OS MasterMap. Additionally, it's only for the UK.

3. Besides the commercial solutions, you might wonder why we simply can't do with GoogleMaps? It's mostly freely available for use and also provides you with satellite imagery and StreetView. They even allow you in some areas to update the map through Google MapMaker.

4. But one thing Google doesn't give you access to, is the data behind the map. All you will ever see, is the rendered map tiles and perhaps some APIs to lookup locations and points of interest. Even for data that you have added yourself through MapMaker.

5. Both aspects; the cost of commercial maps, as well as the access to the data that is behind the map tiles is something that the OpenStreetMap project addresses. But which steps have to be taken to obtain this enormous amount of geographical data?

6. We start by getting our wellies and trusty GPS out. Maybe even some pen and paper. We find a location that looks rather empty on the map and travel to that area to see what's on the ground. This is step one: data gathering in the field.

7. In urban areas such as London the roads have often already been mapped and a GPS is not accurate enough to be useful. Then we just use pen and paper to record points of interest, such as shops, landmarks, restaurants and postboxes, my personal favourite.

8. In the country side, donated aerial imagery makes it possible for us to easily trace tracks and footpaths. However, you can't be sure whether the imagery is up-to-date, and you can't always see where fences, streams and local wild life create barriers.

9. In both situations, surveys are best done in groups: at mapping parties. It helps spread the workload and a larger area can be surveyed in one go. As an additional benefit, it allows us to go the pub and discuss our mapping adventures!

10. Doing a survey is important. We take photographs, video and notes with pen and paper of everything that seems to be of interest. This leaves a record that everything we map is actually existing and we can prove that nothing has been copied from other copyrighted maps.

11. After collecting the data, we enter it into the database. This includes basic information such as street names, but we also record whether a café has wheelchair access, or whether a pub has wifi. Updates to the map show up on the site close to real time.

12. Every map object has tags associated with it. Tags tell whether a line is a road, or perhaps a fence. All the tags are free form so you can generally add as much information about an object as you want. Sometimes however, this gets slightly out of hand and people tag pandas in trees and eyes on postboxes.

13. Once the data has been added to the map, we can make use of it. One of the primary uses is obviously showing the data as map tiles. But with all the extra data, we can generate maps that show all the information you're interested in-and nothing more.

14. Clockwise, we have four different visualisations of the map data: we have a cycling-specific style, a style that shows transport routes, a rendering with MapQuest's style sheets and even a water colours inspired style.

15. Having mentioned MapQuest; they were one of the first companies to make use of OpenStreetMap data. They provide, free of charge, map tiles with their own rendering style as well as an instance of Nominatim, OpenStreetMap's geolocation sister project.

16. Lots of companies have already switched to OpenStreetMap. The property search site Nestoria recently switched from using GoogleMaps to OpenStreetMap. Partly because of their costs, but also partly because "The maps are equal or better". geocaching.com, TfL's countdown website and Apple also use OpenStreetMap maps and data.

17. Although OpenStreetMap provides a free and editable map of the world, there are certain requirements for using the data as well. The most important one is that you always need to attribute the OpenStreetMap project.

18. In order to help people start using OpenStreetMap for their mapping needs, the Switch2OSM site has been launched. This website provides background information, case studies and technical information on how to use OpenStreetMap data.

19. Right now, OpenStreetMap has very good data coverage in the country, but we are not nearly finished. A lot of work still has to be done, and we rely on you to improve the data too, even if you add just a postbox.

20. In the last 5 minutes we have looked at what OpenStreetMap is, how the data is gathered and how the data is added to the map. Further more, we had a look at different use cases of the data. OpenStreetMap in the UK: Footpaths and pubs a speciality!

And then I planned showing the "Year of Edits" video, but that sadly didn't work out. I'm including it for good measure here though. (If you want it in HD, follow the link).

The video of the talk itself is at http://vimeo.com/41626116 and is embedded here:

10 years of Xdebug and Xdebug 2.2.0 released

Today it has been ten years since the first release of Xdebug: version 0.7.0. I would like to celebrate this tenth anniversary with a new release: Xdebug 2.2.0. Xdebug 2.2 adds support for PHP 5.4 and provides some new features:

Colours on the command line

First of all there is now var_dump() overloading and colours on the command line. I've already written about that before, but here are the screenshots again:

Linux/Mac:

Windows:

You can find an article about this here.

Better support for closures in stack and function traces

Closures are functions that don't have a function name associated with them. Therefore, Xdebug creates a pseudo function in its stack traces. The stack trace for this example:

<?php
function test1()
{
        $f = function($a, $b) {
                $Q = strlen($a * $b);
                trigger_error('foo');
        };

        $f(5, 25);
}

test1();
?>

Looks like:

Notice: foo in /tmp/closure-stack-trace.php on line 21

Call Stack:
        0.0009     268464   1. {main}() /tmp/closure-stack-trace.php:0
        0.0026     269288   2. test1() /tmp/closure-stack-trace.php:27
        0.0032     270024   3. {closure:/tmp/closure-stack-trace.php:19-22}($a = 5, $b = 25) /tmp/closure-stack-trace.php:24
        0.0038     270496   4. trigger_error('foo') /tmp/closure-stack-trace.php:21

In the 3rd line in the call stack you see {closure:/tmp/closure-stack-trace.php:19-22}($a = 5, $b = 25) where /tmp/closure-stack-trace.php:19-22 contains the filename and line numbers on which the closure is defined at.

The size of arrays is now shown with the overloaded variable output

After this change, each array in the HTML version of the overloaded var_dump() function now looks like:

<b>array</b> <i>(size=5)</li>

Before the change, this was only:

<b>array</b>

Added the method call type to xdebug_get_function_stack

This changes adds another array element to xdebug_get_function_stack() to show whether it was a static or dynamic function call. For example, for:

new Error_Entry(false, $errno);

It now adds the ["type"]=> string(7) "dynamic" element to each stack element:

array(6) {
  ["function"]=>
  string(11) "__construct"
  ["type"]=>
  string(7) "dynamic"
  ["class"]=>
  string(11) "Error_Entry"
  ["file"]=>
  string(%d) "%sbug00241.php"
  ["line"]=>
  int(11)

Extra information to error printouts to tell that the error suppression operator has been ignored due to xdebug.scream

When you have the xdebug.scream option activated, Xdebug will now tell you when it had any effect on the error reporting with a big "SCREAM: Error suppression ignored for" warning prepended to the actual error message.

Changelog

You can find the full changelog for Xdebug 2.2.0 at the Xdebug website where you can also download the latest version. If you are using Windows, and don't know which binary to download, please refer to the wizard.

Support

If you find Xdebug valuable for your PHP development, perhaps you want to support its development by acquiring a "support" contract. See the buying "support" page if you feel generous.

What's next?

Now Xdebug 2.2 is out of the door, I am looking for new features to add to Xdebug. What would you like to see added to Xdebug? Please leave a comment here, or add your feature requests at http://bugs.xdebug.org.

Working at 10gen

As of today I am working for 10gen, the company behind MongoDB. I have been contracting with them for a few months to work on the PHP driver for MongoDB. I am now making the switch to a full time position.

I am responsible for supporting MongoDB in the PHP ecosystem through driver development, integration with open source tools, community support, and developer advocacy. For now, I will concentrate to get the driver into a better shape, and speaking about MongoDB and PHP.

I have already given a few talks on the subject, and if you would like me to speak at your user group or conference, please let me know. If you have any comments on using MongoDB with PHP, I would love to hear them too.

I am looking forwards with the awesome team at 10gen. Both with team in London, as well as with the folks in Palo Alto, New York and Dublin. 10gen is also hiring a few more people for a similar position in New York and Palo Alto. Have a look at the job posting here if you are interested.

New in Xdebug 2.2: Colours on the command line

This is the first article in a series about new features in Xdebug 2.2. Besides support for PHP 5.4, there are a few that might be of interest.

Xdebug has overloaded var_dump() with xdebug_var_dump() for a long time and the overloaded function could be configured with a few configuration settings. There is xdebug.var_display_max_data to configure how much of a string should be shown; xdebug.var_display_max_children to configure how many children in an array should be shown and xdebug.var_display_max_depth to configure how many levels "deep" the var_dump() should go on for. This functionality was available for when PHP had its html_errors setting on as is usually the case in a web environment1.

Xdebug 2.2 adds this same functionality to the non-HTML environment: the command line. Now the overloaded var_dump() and native xdebug_var_dump() functions also accept the three aforementioned settings:

derick@whisky:~$ php \
        -dxdebug.var_display_max_data=8 \
        -dxdebug.var_display_max_children=4 \
        -r 'var_dump( "a longer string", array( 1, 2, 3, 4, 5, 6, 7 ) );'

outputs:

string(15) "a longer"...
array(7) {
  [0] =>
  int(1)
  [1] =>
  int(2)
  [2] =>
  int(3)
  [3] =>
  int(4)

  (more elements)...
}

Now, to be fair. This is all a side effect; and merely an add-on to a patch by Michael Maclean. He wrote a patch that adds colours to the output on the command line by using ANSI escape codes. This patch also made the overloaded var_dump() listen to the limiting settings for variable display. After his patch, the following was the behaviour on the command line as long as stdout is a tty and xdebug.cli_color is set to 1.

I have extended this so that the settings regarding data display also work without xdebug.cli_color set to 1. Further more, in Xdebug 2.2.0RC1, setting xdebug.cli_color to 2 forces the colours from being shown, even if stdout is not a tty.

Initially, the colour coding of errors and var_dump() output, would only work on a Unix system where ANSI escape codes are commonly supported. After the release of Xdebug 2.2.0RC1, Chris Jones submitted a bug report suggesting that this functionality could also be available on the Windows console. I wasn't aware that Windows could do this anymore since they dropped ANSI.SYS but apparently there is a tool, ANSICON, that reimplements this. From the next release, Xdebug 2.2.0RC2, Xdebug will now also check whether the ANSICON environment variable is set, just like Xdebug would check whether stdout is a tty on a Unix platform. As a result, the equivalent console output as shown before looks like the following on Windows (providing ANSICON is installed):

Now the only thing left is adding complete documentation for this feature ;-)

As always, if you think Xdebug is a valuable tool, have a look at http://xdebug.org/buy-support.php.

London at Night

A few days ago I finally wandered into London with a tripod and my camera. I've been meaning to do this for months and take long exposure shots of various places in London, as well as seeing whether I can make cool timelapses. I've only taken a few pictures near the Thames and the London Eye so far, with one timelapse of the London Eye. I am however planning to return for more. This photography trip also coincided with the conjunction of Jupiter and Venus.

Here are some of the images:

And at last item, a timelapse of the London Eye:

This timelapse was recorded with 802 images. Each image is taken 3 seconds after the previous one resulting in a speed-up of 75 times. Lighting has been manually monitored during the taking of the images.

The rest of the images are on flickr.