1. Mapumental + net yield = an advantage in the property market

    Our Mapumental software shows journey times on a map, with exciting results.

    But there’s more: combined with other datasets, it can answer a wide variety of questions, be put to a wide variety of uses across many industries.

    Most recently, we worked on a version for the Dolphin Square Foundation. Their remit requires them to find properties within a specific travel time from the centre of London, and with the best net yield—a perfect challenge for Mapumental. You can read what we did here.

    You may see some similarities with our Mapumental Property, which combines house prices with transit time, so property hunters can see what’s available both within their budget and within a tolerable commute of their workplace.

    We’ve used Mapumental for many a time-based travel conundrum, like our project with the Fire Protection Agency that drew on fire engine response times to  calculate risk-based insurance premiums for any given postcode. Or the work we did for the Welsh Government, plotting accessibility of schools.

    Like we said, Mapumental is flexible enough to work in all sorts of fields, for all sorts of purposes. Take a look at our Dolphin Square case study to find out more about its latest incarnation.

     

    Image: Garry Knight (CC)

  2. A new home—and a new purpose—for ScenicOrNot

    My last blog post ran through the history of our ‘rate the view’ site ScenicOrNot.

    I was expecting to wrap up with a final paragraph describing its graceful retirement. But no — it turns out that, even as I wrote, emails were going back and forth to secure a whole new career for ScenicOrNot.

    Here’s what its new owners at the Warwick Business School have to say:

    Does living in picturesque areas make you feel healthier? Urban planners and think tanks have puzzled over this question for years, but have been held back by a lack of data on the beauty of our environment.

    We were immensely excited to discover the data being collected by ScenicOrNot, as it gives us a crucial opportunity to finally get some answers to this age-old question.

    Our initial analyses of the ScenicOrNot data suggest that people living in more scenic environments report better health, even when taking variables such as income and greenspace into account. These results suggest that the beauty of our everyday environment might have more practical importance than has previously been realised.

    We’ve written a paper describing these analyses, which is currently under review. Keep in touch with us via Twitter (@thoughtsymmetry or @thedatascilab) and we’ll let you know when the paper is published.

    We’re very honoured that mySociety are passing the ScenicOrNot site into our care. We’re excited about having the opportunity to customise the site and gather more data for our research, and we’d also love to expand this work to other countries. Stay tuned to hear what comes next!

    We’re excited too, of course — and really pleased that ScenicOrNot has been redeployed in such a useful way.

    The good news for you is that you can carry on rating photos for scenicness over at the site’s new home, all in the knowledge that you are increasing our understanding  about the correlation between health and our environment.

    Oh, and meanwhile: how would you rate the view from your window? You might want to talk to your doctor about that.

    Image: Brainflakes (CC)

  3. The story of ScenicOrNot

    Take a look out of the window. How would you rate the view, on a scale of one to ten?

    Your response can probably tell us a little about the beauty, or otherwise, of the area around you. That’s the premise that ScenicOrNot, one of the mySociety sites that we recently stopped running, was founded on. Happily, ScenicOrNot has now found a home and will continue under new ownership: more about that in a future blog post. Meanwhile, we’d like to celebrate it with a potted history.

    An exercise in crowdsourcing, ScenicOrNot served up a series of random images, each representing one square kilometre of Great Britain, and invited users to rate them (the images were sourced from the Geograph project, itself a fascinating open source repository). The results fed into a database of ‘scenicness’.

    ScenicOrNot collected that data and also permits anyone to download it, under an Open Data Licence, for their own ends.

    What was it for?

    To understand why we made ScenicOrNot, you have to go back to the beginnings of our transit-time mapping technology, Mapumental.

    Mapumental shows journeys in terms of how long they take, and it was intended to help people make decisions about where to live, work, or go on holiday. We’d figured out how to display bands of public transport journey times, but we knew that those weren’t the only factors that feed into such important life choices.

    House prices, average salaries, and, yes, the beauty of the surrounding area all have a part to play. We wanted to be able to add them to Mapumental so that users could get a really rounded picture.

    But while there are public databases for house prices and average salaries available, until the creation of ScenicOrNot, there was no such thing for scenicness. There was just one solution: we would have to make our own.

    ‘Hot or Not’ for scenery

    Rather than go and look at every part of the country ourselves, it was time to harness the wisdom of the crowd.

    ScenicOrNot, the building of which was managed by the Dextrous Web, launched in 2009. It served users with an unending random series of images showing landscapes from around the country, and was an early foray into both crowdsourcing and gamification for mySociety.

    Rating images, as also seen in Kittenwar (and other, less fluffball-centric sites like HotOrNot) is a pleasingly compulsive activity, and within just a few months, every kilometre of the country had been rated at least once.

    And as time went by, we reached a critical milestone: the project amassed a minimum of three votes for each image, helping to ensure that the results were less likely to be skewed by eccentric or unusual opinions about what makes a place scenic.

    Slotting ScenicOrNot into Mapumental

    We now had our ‘scenicness’ data, and house price and salary data from other sources. The decision we made about how to incorporate these data sets was an important one which has worked well for subsequent Mapumental projects like the work we did for the Welsh government, or for the Fire Protection Association.

    Effectively, you can think of each data set as a map layer, which may be slotted in our out, as needed. Our showcase site Mapumental Property demonstrates this – it’s effectively the vanilla transit-time Mapumental, with a house price layer (from Zoopla) added in.

    A new lease of life

    If we hadn’t found a new owner for ScenicOrNot, we’d have shut it down. Happily, though, it’s found a new home and a whole new purpose: we’ll be explaining more about that in our next blog post.

     

    Image © Copyright Derek Harper (CC)

  4. Self-service at Mapumental

    whatcouldyoudo

    From today, it’s much easier to buy transit-time maps from Mapumental. We’ve added a self-service shop which allows you to generate your own maps, instantly and easily.

    The technical amongst you may like to know that the service queries the Mapumental API; for everyone else, it’s probably enough to say that your maps will just appear, as if by magic.

    Mapumental maps are cheaper when you buy in bulk, so we’ve also integrated a credits system. If you know you’ll have an ongoing need for our maps, stock up on credits (also completely self-service) and you’ll soon start benefiting from some substantial discounts. We’ve included a nifty little credits calculator on the page, so you can find the price band that best suits your needs.

    Check out the new interface at Mapumental now. All the benefits of a self-service checkout, none of those irritating “unexpected item in the bagging area” announcements.

  5. Order the map you need: Mapumental Public Transport Maps

    Mapumental order this map

    Mapumental just became self-service! Now you can order maps as images or data, right from the Mapumental website.

    Public transport travel times to Birmingham meet-up, from Mapumental by mySocietyMapumental creates maps that display transit time rather than distance. The results, showing time bands in an array of colours, are both useful and rather beautiful (see the example, right).

    We’ve added new functionality so that you can download your maps direct – just go to www.mapumental.com and click the ‘try it’ button.

    Once you’ve input a postcode and moved the slider bar to reflect the maximum travel time you want to display, you can go ahead and click on ‘order this map’, and choose parameters including direction of travel,  zoom level, size and title.

    Mapumental maps as data

    Choosing the ‘data’ option will export your map as a 500m resolution GRASS ASCII raster, which can be imported directly into your preferred GIS software.

    Mapumental maps as images

    You may prefer to simply download the end product – a graphic image that you can save to your own hard drive and use in presentations or reports, on websites, or anywhere else you choose.

    It’s as easy as that

    Payment is via a credit system: the more credits you buy, the cheaper each map is.

    We hope you’ll find the self-service Mapumental useful – we’d love to hear feedback about your experience using it, and how you utilise the resulting maps.

    Don’t forget that we can also create bespoke maps with your own data – get in touch to find out more.

  6. 12 exciting projects mySociety was hired to deliver last year

    Image by Craig Sunter

    Not many people realise that we fund a proportion of our charitable work by carrying our commercial development and consultancy work for a wide range of clients.

    Last year, we scoped, developed and delivered a real variety of digital tools and projects. Some of the projects were surprising. Some of them made us gnash our teeth, a bit, as we grappled with new problems. But all of them (and call us geeks if you like) got us very excited.

    Here are just twelve of our personal high points from last year. If you have a project that you think we might be able to help you with in 2015, we’d love to hear from you!

    1. We Changed the Way in Which Parliament Does Digital

    Palace of Westminster by Greg DunlapThis time last year, a small team from mySociety was poring over analytics, interview content and assorted evidence from Parliament projects dating back last 2-3 years, to help us put together a simple set of recommendations to conclude our review.

    11 months later, Parliament have announced their first Head of Digital, fulfilling one of our key recommendations.

    2. We helped the MAS and the FCA protect financial consumers

    Bubble Car by Allen WatkinTwo of our projects helped people financially.

    We built the Money Advice Service’s (MAS) first responsive web application, the Car Cost Calculator.

    This tool takes one simple thing you know (the car you wish to buy) and tells you roughly how much it’ll cost to run that car against any others you might be interested in. It has been one of MAS’ most successful online tools in terms of traffic and conversion.

    We also built the Financial Conduct Authority’s Scam Smart tool, aiming to prevent financial scams.

    This tool helps users considering a financial investment to check a potential investment. Users enter information about the type of investment, how they heard about it and the details of the company offering it to them and get back tailored guidance and suggested next steps to help them ensure the investment is bona fide.

    3. We Gave Power to the People of Panama (soon)

    Alaveteli homepageWorking with the The National Authority for Transparency & Access to Information (ANTAI) and the Foreign & Commonwealth Office (FCO), we set up our first government-backed instance of our Freedom of Information platform, Alaveteli, in Panama.

    This project will ensure that Panama’s FOI legislation is promoted and used, but it will also shine a light on ANTAI, who are responsible for ensuring ministries and organisations publish their information, and handling case appeals.

    4. We Mapped All the Public Services in Wales

    Bws Ysgol - Image by Aqwis via Wikimedia, CCAfter we extended the Mapumental API to produce data output suitable for GIS (geographical information systems), the Welsh Government were able to map public services in Wales for their Index of Multiple Deprivation calculations.

    Over the course of the year they have calculated travel times for over seventy thousand points of interest.

    5. We Launched a New Organisation in Four Weeks

    Simply SecureSimply Secure approached us in dire need of a brand, an identity and a website to accompany the launch of their new organisation to help the world build user-friendly security tools and technologies.

    Cue four weeks of very intense work for mySociety’s designer, supported by members of the commercial team. And we did it.

    6. We Printed Stuff BIG (and found people jobs)

    Public transport travel times to Birmingham meet-up, from Mapumental by mySocietymySociety developer Dave Arter figured out how to generate A1 sized maps from Mapumental for every job centre in the UK – all 716 of them.

    Xerox will be using these with the DWP to help job seekers find work that is within reach by public transport. As a byproduct, Mapumental now handles high-fidelity print based outputs: get in touch if that is of interest.

    7. We Opened Up Planning Applications

    open-planning-shotWith Hampshire County Council we had the opportunity to build a new application to help assist members of the public and business better understand what was happening around them. For us, it was also the first application in which we worked closely with a provider of a linked data store, in this case Swirrl.

    When Open Planning goes live, it will look to help improve social engagement and the economy of Hampshire through better understanding and transparency of planning data.

    8. We Proved (Again) That FixMyStreet Isn’t All About Potholes

    CollideoscopeAfter a spate of cyclists’ deaths in London last year, we felt that the moment was right to build something that would support cycle safety in the UK.

    We launched Collideoscope on October the 7th with our first sponsor—Barts Charity, with the aim of generating data both on incidents involving cycles, and near misses.

    9. We Helped Launch a Film

    A map of old Norse place namesWe built a tool for the British Museum, to go alongside the general release of Vikings Live. The Norse Names project brought a sense of context and personalisation to a dataset gathered by the University of Nottingham.

    10. We Made Data More Exciting

    To the Trains by Nic McPheeIn 2013, we built an interface to help people explore the data in the National Rail Passenger Survey (NRPS) data explorer  for Passenger Focus.

    This year, they asked us to build something similar for bus users. We’re entering the final week of development now, and the finished product should be launched in March.

    The main aim of this site? To take data that could be considered pretty dry, and make it a lot more engaging.

    11. We Fixed Yet More Potholes

    Fixed, by Tup WandersThis year Warwickshire, East Sussex, Hart & Harrogate joined the list of councils using FixMyStreet as their main street fault reporting platform.

    That means that residents of those places can now make their reports direct from their council’s website, or via FixMyStreet, and either way they’ll have all the benefits of FixMyStreet’s smooth report-making interface.

    12. We Showed Parliament the Way

    Parliament Square by Duncan HarrisAnd so, we end where we began. While Parliament were busy interviewing candidates for their new ‘Head of Digital’ position, we were commissioned to demonstrate what Hansard might look like were a platform like SayIt used instead of the largely print-based publishing mechanisms used today.

    The result was shared internally. While SayIt may not be the end solution for Parliament, it’s great to have had some input into what that solution might be.

    And in 2015…?

    Got a project that you’d like us to be involved in?

    Get in touch and tell us about it.

    Image credits:

    Eggs: Craig Sunter; Parliament: Greg Dunlap; Bubble car: Allen Watkin; To the Trains: Nic McPhee; Potholes: Tup Wanders; Parliament Duncan Harris. All Creative Commons.

     

  7. Accessibility of Welsh schools by public transport – visualised

    A commission from the Welsh Government has resulted in new functionality for Mapumental, which now has the capability to display multiple points and to produce RAW data compatible with GIS applications. Here’s how it happened.

    Bws Ysgol - Image by Aqwis via Wikimedia, CCHow accessible is your nearest school, post office, or GP’s surgery? In Wales, that’s not always a simple question: the country’s mountainous landscapes, rural populations, and sometimes infrequent bus services can mean that those without cars are rather cut off from public service provision.

    But of course, like any other authority, the Welsh Government has an obligation to quantify just how accessible their services are.

    For many years, they have done so using a number of different methods. Some of these involve literally millions of point to point calculations – so, naturally, when Bill Oates, Head of Geography & Technology, Knowledge Services at the Welsh Government, approached Mapumental, he was keen to discover whether we could simplify things.

    We were keen to try it, too – plotting multiple points would add a whole new slew of possibilities to Mapumental. Previously, Mapumental has been all about travel from a single point, and this functionality would bring new applications across all kinds of industries and users.

    There’s only one way to find out

    The sensible way forward was to pick a single service and see what we could do. One of the government’s open data sets showed positioning of all the secondary schools in the country, and would give us a very good indication of how manageable the task would be across all other provisions.

    So we set ourselves this aim: to display the shortest transit time to get to any secondary school in Wales, from any point in that country.

    This project was not like the map we made for the Fire Protection Association last year, with its postcode input and interactive sliders. It bore more relation to our static maps, but with the additional dimension that the single map would have multiple points plotted on it. Each point would display its own associated journey times, and where travel to one school was quicker than to another, it would have to override the data of the school that was further away.

    And here’s the (very pretty) result

    Welsh secondary schools travel times mapTransit times by public transport to secondary schools in Wales, with an arrival time of 9:00am.

    Time bands are in 15-minute increments, with red areas being those where schools are accessible within a 15-minute journey (the centres of the red dots therefore also represent the positions of the schools).

    Purple areas are those where journey time is between 1.75 and 2 hours, and the colours in between run in the order you see bottom right of the map. White areas (much of which are mountainous and sparsely-populated) are outside the two-hour transit time.

    But there’s more – data for GIS

    Plotting all the schools on a single map required quite a bit of modification to Mapumental, but there was another important part of the project that also had to be worked on, if the output was to meet all the needs of the Welsh Government.

    They needed to be able to export the raw transit time data to their own GIS tools – the tools that they use to feed into official statistics. This allows the transit time data to be  combined with other datasets, such as population density, for in-depth analysis.

    We added a feature which allows Mapumental to produce what is known as a ‘raster grid’ output – basically, an enormous matrix that gives every pixel on the map a travel time value. To do this, we used the open source GRASS format.

    What’s next?

    Bill Oates is keen to see where this project can go:

    “I’m really excited at the prospect of combining the power of Mapumental with our open data, and fully understanding how accessible Welsh public services are by public transport.”

     

    To him, the benefits are clear:

    “Mapumental’s approach is significantly quicker than our current methods, so this work will help save us time as well as providing a more engaging output.

     

    “We hope that future work with mySociety will give us a sustainable approach to calculating the accessibility of local shops, hospitals, post offices and other services on an ongoing basis to help ensure that we’re meeting the needs of our citizens.”

     

    We’re looking to build on our success, and offer this service to others – initially on request but via our API as soon as we can. We’ll keep you posted as to our progress.
    You can see multiple-point mapping in action, on our Mapumental Property project – now the tool allows house-hunters to take more than one person’s commute into consideration when choosing where to live.

    Who might use Mapumental?

    Now that Mapumental can plot transit times from multiple points, and provide RAW data for GIS applications, we have great potential for use by anyone interested in travel and accessibility. That could be in central and local government strategy, town planning, architectural consultancy, transport provision, large enterprises looking to save on parking, or start-ups in the green transport space…to name but a few.

    Could Mapumental help you with your mapping needs? If so, please do drop us a line at hello@mysociety.org.

    Photo of Welsh school bus (bws ysgol) by Aqwis (CC)

  8. Fire, fire! Mapumental and fire engine journey times

    Image by William Murphy Mapumental can turn vast datasets into visual tools that everyone understands. Faced with highly complex, yet crucial data from the Fire Protection Association, we had a chance to really put our technology through its paces.

    Just how quickly could fire engines reach a given postcode in case of a fire? It’s a question that’s pivotal to decisions made by both the emergency services and the insurance industry.

    But previously, it has been a challenge to present the data simply, because it involves so many variables.

    Every region has its own factors, each of which will impact on fire engine response time. The number of vehicles at each station, the hours during which the station is manned, and the response policy of each individual fire authority will all play a part – and that’s before you even consider how geography might affect things.

    Dr. Jim Glockling is Technical Director at the Fire Protection Association and Head of the Risk Insight, Strategy and Control Authority (RISCAuthority), an organisation for the advancement of risk management within the fire and security sectors. Jim approached mySociety with this question: how could we map this crucial, yet complicated data in a way that could be understood by RISCAuthority members at a glance?

    It was clearly a job for Mapumental. Our transit-time mapping software was originally built to visualise public transport journey times, but its beauty is that ‘layers’ of data can be swapped out, allowing it to be used for all kinds of purposes.

    Read more about mySociety’s data visualisation services here.

    Assessing a property or postcode

    How quickly could 4 fire engines get to AL10 0XR in 10 minutes and 10 seconds?

    How quickly could 4 fire engines get to AL10 0XR in 10 minutes and 10 seconds? (Click to enlarge)

    And here’s the result of our pilot project. The maps on the right answer the following questions (click each image to see it at full size):

    How quickly could 4 fire engines get to AL10 0XR ?

    FPA: arrival times one engine

    FPA: arrival times one engine (click to enlarge)

    How does that change if the severity of the fire just requires one fire engine?

     A user inputs a postcode, and can assess exactly how quickly a fire could be tackled in that area. The different levels of severity are measured by how many response vehicles are required, and changes in this number are immediately reflected on the map.

    Assessing the general area

    FPA  - what it looks like when you have no postcode

    Which areas can four fire engines get to within 9 minutes 30 seconds at midday on a Saturday?

    It’s also possible to assess the region’s overall response capability, without inputting a postcode. The user sets severity levels (number of fire engines, or High Volume Pumping or Aerial Appliance (ladder) is needed), the time and day of the week.

    FPA - aerial response arrival within 15 minutes

    Where can an aerial appliance get to within 15 minutes at 2am on a weekday?

    The FPA tool immediately highlights the areas that are accessible within the chosen parameters, drawing on the underlying data of journey times and information such as vehicle numbers and hours of operation for each individual fire station in the region.

    Simplicity itself

    With RISCAuthority, we tested the concept using data from one fire authority –  Hertfordshire. mySociety’s task was to create a usable, elegant web interface that was as simple as possible to use, while still giving insurers the key data they needed.

    The project called on everything we knew about clean design, usability and data structures. A key part of what makes Mapumental’s data visualisation so intuitive are its sliders: this enables the user to quickly explore variables on a map.

    A tool with purpose

    Dr Glockling explains: “Whilst not necessarily used as a component of insurance pricing, this information helps insurers administer risk control and fire protection advice to their customers in the context of what the Fire and Rescue Services will be able to achieve on their behalf.”

    The response time is just one factor that insurance surveyors will take into account when they are assessing a building. “Where response and arrival times are not coherent with protecting the viability of the business in the event of fire, additional forms of in-built protection and control might be recommended, such as the installation of sprinkler systems.”

    “In the longer term it is hoped such information will impact beneficially on the annual cost of fire in the UK.”

    Results

    The pilot tool was well received by the FPA community, and the plan is now to work with RISCAuthority to roll it out to more fire authorities shortly, and then nationwide.

    Dr Glockling explains the pilot study helped them to understand two factors:

    • Would they get buy-in from both insurers and Fire and Rescue services on the viability and usefulness of the project?

    • Was it possible to present such a massive amount of data in a format that was readily palatable to the intended audience?

    He says, “Mapumental’s team displayed an immediate understanding of our requirement. Delivery was to time and the result has perfectly satisfied the de-risking ambition. The working relationships were very good throughout and we intend now to extend the pilot to full UK rollout.”

    During this phase, we will be inputting still more detail to the data, including information on the types of fire engine available to each region, and the plotting of fire stations on the map.

    The tool will be a valuable resource for the FPA and the insurance industry, and we really look forward to the roll-out later this year.

    Mapumental specialises in visualising complex geographic data sets on intuitive, easy to use map tools. If you have a data visualisation project that will benefit from Mapumental, just get in touch. Or read more about mySociety’s data visualisation services here.

    Photo by William Murphy (CC)

  9. Mapumental Property – extra insight for househunters

    If you’re searching for a new home, give Mapumental Property a try. lt narrows property results down, only showing you houses that fall within a decent commute time from the places you visit regularly – like work, school, or the shops. Here, have a go – it’s fun.

    Mapumental Property screenshot

    Irritation is the mother of invention

    Several years ago,  some of our colleagues were looking for a house to rent.

    They weren’t set on a particular town. There were two important factors: that it was within a reasonable commute from central London, where they frequently attended meetings; and that the rent was affordable.

    Faced with these requirements, most of us would sift through property sites and cross-reference the listings manually with public transport information. It’s rather time-consuming, and slightly irritating, but hey-ho, it has to be done.

    But mySociety is in the business of building useful web tools, so when something irritates us like this, we look to see if we can solve the problem through the magic of code. In a stroke of good timing, it was at just around this time that the Department for Transport approached us to ask us to work with their public transport data – and Mapumental was conceived.

    Early days

    The key was to combine Ordnance Survey postcodes with the DfT’s data about journey times, NPTDR (National Public Transport Data Repository). This data set takes a  ‘snapshot’  of every public transport journey in Great Britain for a selected week in October each year.

    Sounds simple? The process was not without its challenges. Prime among them was the problem of displaying map tiles, plus the vast quantities of transport data, within a reasonable amount of time, no matter which postcode or zoom level the user chose. As we know, a  ‘reasonable amount of time’  for a page to load is a metric which is forever shrinking.

    By 2006, we had created Mapumental’s first iteration. Users could input a postcode and see all areas of the country that could be reached by public transport, divided into coloured travel-time bands. In 2009, Francis Irving, the mySociety coder behind Mapumental’s early endeavours, explained the technology he’d used. It was Flash-dependent, and a few years later, developer Duncan wrote about some of the technical hurdles he overcame replacing the Flash elements, in view of the rise of the iPhone, which famously doesn’t  ‘do’  Flash.

    Hoorah! Now our colleagues could type in a central London postcode and see everywhere that fell within a 40-minute journey from there. It wasn’t long before we added median house price data, too.

    Beauty is in the eye of the crowd

    We even added a ‘scenicness’ rating: if the beauty of your surroundings was important to you, you could rule out anywhere below a certain level of attractiveness.

    How did we assess how scenic every area in the UK is? By crowdsourcing the information – our ScenicOrNot website displays a random photograph from every square mile of the British isles, inviting people to rate them. It is surprisingly compulsive.

    ScenicOrNot from mySociety

    A showcase tool

    Mapumental may have been born from our own needs, but we knew from the beginning that it would have wider applications. It has always been the sort of project that got people excited, once they saw it in action.

    We wanted to show how elegantly Mapumental can handle all kinds of data, starting with houses for sale and rent – so we developed Mapumental Property. It’s not intended as a serious competitor to the giant property websites out there. Rather, it’s an all-singing, all-dancing demonstration of Mapumental’s strengths.

    In this case, the data is from the property website Zoopla, and you can narrow it down to show rental or sales property within your chosen price bands and commute distances. You can even add multiple destination points, so that households of two or more people can find their optimum location.

    Versatility rules

    But Mapumental is not just about property: swap out that Zoopla layer, and you could put in anything else you can imagine – hospital locations, supermarkets, schools, job vacancies… you name it.

    The beauty of Mapumental is that now we’ve done the really hard part, incorporating new data layers is relatively simple. Recent work for the Fire Protection Association and the Welsh Government, among others, has shown its versatility.

    Now how about you?

    We believe that Mapumental’s possibilities are pretty much endless. Have you got an unloved, difficult-to-navigate dataset that Mapumental could breathe new life into? Or would your stakeholders benefit from being able to see your data displayed on a map? Let us know.

  10. Mapumental’s Secret Sauce: A Map Overlay Rendering Technology You Might Find Interesting

    I am Duncan Parkes,  a developer for mySociety, a non-profit full of web geeks. One of the things we try to do well here is to take complicated data and turn it into really usable tools – tools which are attractive to people who aren’t web (or data) geeks.

    For some considerable time I’ve been working on Mapumental – a project that is about turning public transport timetable data into pretty, interactive maps featuring isochrones, shapes that show people where they can live if they want to have a commute of a particular time. You can play with the new version we just launched here. That particular map shows the commuting options to where the Queen lives. Slide the slider for full effect.

    There are a couple of hard problems that need solving if you want to build a service with an interactive journey times overlay like this. You need to be able to calculate a *huge* number of journeys extremely quickly, and you need to be able to make custom map layers so that it all looks nice. But what I think might be most interesting for you is the way in which the contours get rendered on top of the maps.

    It all started about three years ago, when the first version of the app – co-developed with the geniuses at Stamen – used Flash/Flex to draw contours on the maps, and to let people play with them. You can still play with a couple of versions of that technology from way back in 2007, that is, unless you’re using an iPad or iPhone, which of course don’t do Flash.

    Colour Cycling

    What was going on inside this Flash app was as follows. We needed to show the user any one of hundreds of different combinations of journey times (5 minutes, 12 minutes, 56 minutes, etc) depending on where they set the slider. Sending each one from the server as a tiled map overlay would be dead slow. Even Google – who have chosen to send new tiles each time – end up with a service which is surprisingly slow (try choosing a different time on this map).

    With some help from Stamen, we decided that the way of making it possible to show many different contours very quickly was send the client just one set of tiles, where each tile contained all the data for a variety of journey times. What does that mean? Simple: each colour in the tile represented a different number of minutes travelling on the map. So a batch of pixels that are colour X, all show places that are 15 minutes from the centre of the map.

    So, in this old Flash system, when you slide the slider along, the Flash app makes some of the coloured pixels opaque, and the others transparent. It was, in short, a form of colour cycling, familiar to lovers of 8 and 16 bit computer games.

    However, from about 2010 onwards, the march of iOS spelt the end of Flash. And that meant that we couldn’t launch a shiny new site based on this technology, as lovely as it was. We had to work out some approach that would use modern web standards instead.

    The Death of Flash Makes Life Difficult – for a while

    How do we replicate the experience of dragging a slider and seeing the map change like in the original Mapumental demo, but without Flash? One of the things that made the original Mapumental nice to use was how smooth the image changes were when you dragged the slider. Speed really matters to create that sort of organic effect that makes the demo so mesmerising.

    So as we started to tackle the question “How do we make this work in a post-Flash world?”. And the first thought was “Let’s do away with those map tiles, filled with all that journey time data!”. After all – why send any tiles to a modern browser, if it can just render nice shapes on the fly?

    So we had a go. Several goes. At first we tried rendering SVG circles around each public transport stop – but that was too slow, particularly when zoomed out. Then we tried rendering circles in Canvas, and whilst that was OK in sparsely populated places it sucked in the cities, where people would actually want to use it.

    Eventually, we decided that as wonderful and powerful as modern web rendering techniques are, if you exclude WebGL (on the grounds that so few people have it still), all the current techniques result in pages that just hammer your browser, whilst producing an experience which isn’t up to our previous Flash-based standards. To see this in action, see the wonderful Mapnificent site, developed by the super talented Stefan Wehrmeyer. He’s a great guy and a friend of mySociety, but the Javascript circle rendering just grinds, and that’s with far, far fewer data points than we have in our system. (Sorry for potentially crashing your browser there. This is in the interest of Science.)

    Back to Colour Cycling – Using Web Standards

    So, we thought, why not look again at colour cycling the pixels within pre-rendered map tiles? After all, there are some examples out there, like this waterfall, all in Javascript.

    So, I had a bit of a look at the waterfall. It seems to work by holding in memory a structure which has all the pixels which change and all the colours they should change to and when. This works beautifully for the waterfall picture, but only a limited number of the pixels in that image actually change colour, and the image is quite small. For a full screen web browser with a big map in, this didn’t seem promising, although I’d love to see someone try.

    Then I thought: browsers have always been very good at displaying images quickly – that’s sort of vital. Perhaps we could get our tile generating server to output PNG images where, as before, the colours represent travel times, but using a palette. Then by putting this in a canvas layer in the JavaScript mapping framework Leaflet, and by changing the palette of the images on the canvas as the slider is dragged, we could get our animation.

    Unfortunately, there is no way to change the palette of an image that you’ve put on the canvas. In fact, there’s no way to change the palette of an HTML img element: all you can do is assign it a new src attribute.

    But this gets back to the original problem – we don’t want to download new mapping for every different position on the time slider. We definitely can’t afford to have the client downloading a new image source for every tile whenever the slider is moved, so we had to find a way to make that src at the client end and get that into the src attribute.

    The Breakthrough – Data URIs and Base64 encoding

    So we started trying data URIs. For those of you not familiar, these allow you to put a whole object into your HTML or CSS, encoded in Base64. They’re commonly used to prevent pages having to make extra downloads for things like tiny icons.

    So I thought, “Here’s a way we can set an image src in JavaScript to something we’ve calculated, rather than something we’ve downloaded.” And this turned out to be the key insight that allows for the relatively smooth, attractive overlays you see in Mapumental today.

    My new plan was that the client, having downloaded each palette-based image, would make a Base64 encoded version of it, which it could then use to build a version with the right palette and assign this as a data URI of the tile.

    However Base64 encoding all these images in the JavaScript seemed like unnecessary processing to do there, so the final evolution of this technique was to do the Base64 encoding at the tile server end, and while we’re at it, not to bother sending over the parts of the image that we always replace at the client end.

    So in summary, what we built does this:

    1. The server calculates the journey times and renders them to palette-based tiles.
    2. It sends these to the client, encoded in Base64, and with the initial bits up to the palette and transparency chunks removed.
    3. At the client end, we have a pre-prepared array of 255 ‘starts’ of PNGs that we combine with the later parts of the ’tiles’ from the tile server to make data URIs.
    4. When you drag the slider it combines the appropriate ‘start’ of a PNG with the bulk of the tile that has been downloaded from the server, and assigns that to the src attribute of the tile.

    And that’s how the nice overlays on Mapumental work. But as so often in coding, the really interesting devil is in the detail – read on if you’re interested.

    Diving into Base64 and the PNG file format – The Gnarly Bits

    So – why are there 255 of these ‘starts’ of these PNGs, and what do I mean by a ‘start’ anyway?

    PNG files are divided up into an 8 byte signature (the same for every PNG file) and a number of chunks, where each chunk consists of 4 bytes to tell you its length, 4 bytes of its name, some data, and 4 bytes of cyclic redundancy check. In this case, what I call a ‘start’ of a PNG is the 8 byte signature, the 25 byte of the IHDR chunk, and the PLTE (palette) and tRNS (transparency) chunks. The PLTE chunk has 12 bytes of overhead and 3 bytes per colour, and the tRNS chunk has 12 bytes of overhead and 1 byte per colour.

    Base64 encoding is a way of representing binary data in text so that it can be used in places where you would normally expect text – like URIs. Without going into too much detail, it turns groups of 3 bytes of binary gumpf into 4 bytes of normal ASCII text without control characters in it, which can then be put into a URI.

    Why do we have 255 colours, rather than the maximum 256 which are available in a palette? Because we need the break between the end of the tRNS chunk and the start of the IDAT chunk in the PNG file to align with a break between groups of three bytes in the Base64 encoded image. We need the length of these starts to be a multiple of 3 bytes in the original PNG format, which translates into a multiple of 4 bytes in the Base64 encoded version, so we can cut and shut the images without corruption.

    Which just goes to show that even though web GIS technologies may feel like they are approaching a zenith of high level abstraction, there’s still some really gnarly work to be done to get the best out of current browsers.