Donate using PayPal

CycleStreets blog

News from CycleStreets

Archive for the ‘Vacancies’ Category

Intern vacancies Summer 2018

Wednesday, April 11th, 2018

CycleStreets is seeking one or more paid interns to work on a variety of projects this summer.

About CycleStreets

CycleStreets is a social enterprise based in Cambridge, working to help get more people cycling by the provision of information on cycle-friendly routes, and various tools for use by cycle advocacy groups.

We are best known for our journey planner, aimed at finding practical cycle routes in urban environments. To do that effectively requires collating data from a variety of sources and configuring a routing engine to make the same decisions a knowledgeable cyclist would make to find a route to their destination. We are aiming to provide the highest quality cycle routing in the world that tries to ‘think like a cyclist’.

Our bike routing is used by our own website and apps, as well as in a range of third-party apps (such as Citymapper, Bike Hub, London cycle hire apps, etc.), as well as a variety of transport companies (SDG, Virgin East Coast, mxdata, Traveline Wales/Scotland, etc.). It is also being used for academic research and transport planning, e.g. the Propensity to Cycle Tool and CyIPT projects.

The website also includes our Photomap – around 80,000 user-contributed photos of cycling related infrastructure from around the UK and beyond. These are used by activists to promote good practice and highlight problems to avoid in future. The Photomap also powers Local Authority websites such as the Urban Cycle Parking website for TfL. Further tools that present transport data that affects cycling are also in development.

CycleStreets also manages Cyclescape, a geographically-based discussion forum increasingly used by cycling campaign groups across the UK.

With our limited resources given over to focussing on keeping the core services up-to-date and responsive several areas have been left lagging and with work to do. We have a powerful API suite, but the front-end website and apps do not currently reflect its abilities in design and UI terms.

A wide range of potential development areas

Although improvements to our main codebase – the website – is our ideal focus, we’re happy to see work on any of our projects – routing engine, mobile apps, Cyclescape, etc.

The codebase for the main website is a rich collection of page-generation code, database procedures and webpage classes, system configuration scripts, and a low-level routing engine implementation – all written in commonly used mainstream languages. The codebase has been reorganised thanks to help from a previous year’s intern. This codebase primarily consists of over 200 PHP classes, using traditional inheritance/loading techniques, arranged as a fairly purist MVC structure. Much of the core functionality has been converted to a public API (with over 40 calls in total) that powers the website and third-party apps/sites.

Much of our code is on Github and we are trying to get the main website there too.

Some specific areas which we would welcome help with (though this is not exhaustive) include:

1. System coding and refactoring

Ours is a large codebase, with large amounts of functionality. There is always plenty of development that can be done throughout the system. Our previous intern’s work on refactoring was particularly beneficial and further work can be done; new functionality is also very welcome.

2. Overall website design, including integration with mobile

There’s an opportunity to update how CycleStreets presents itself to give the service a ‘personality’ – particularly on mobile. Here we’re mainly thinking about the look and feel but also what can be done with it. The codebase can serve webpages based on templates, and these are ready to be used by responsive stylesheets that will work on a variety of screen widths. Developments in this area could provide a major benefit to users on mobile In general, we are aiming to unify our various interfaces into a single implementation.

3. Usability

Interaction with the journey planner works smoothest on desktop but there is a lot of scope for improving mobile interactivity. Interaction of the journey planner with the map is one area that needs work, but there a lot of small things that would help such as, for instance prompting users’ frequently used locations when they search.

4. Cycle route quality

Changes to the cycle routing engine are perhaps beyond the scope of a summer intern, unless you are starting from a more advanced base of knowledge. A major challenge is how to know if the suggested cycle route is good – and whether changes to input data or configuration parameters produce a better route or not. Ideas and developments of the testing regime could make a significant difference to route quality.

5. Elevation data

The routing engine takes into account the cost of hill climbing and that depends on accurate elevation data. There’s scope for adding to our library of data provided by countries such as Australia and Finland.

6. Geocoding

Maintaining an up-to-date way of translating text into a location has proven quite a distraction over the years. We’d really like to get on top of this issue and resolve it once and for all. It’s quite a well-defined isolated project, primarily involving sysadmin and code integration work.

7. Work on our mobile apps

If you have skills in Java for Android or Objective-C/Swift, we would also be willing to consider work on these also. The apps have been created by colleagues rather than the two of us who will be running the internship; accordingly we can’t provide training on the actual programming languages, but things like code structure and UI would be possible to be covered. A new design has been created and is almost ready to be implemented.

8. Bikedata site

We’ve been working to get lots of public data on our new Bikedata site. There are many ideas for development here – new layers, new features, graphing, visualisations, API improvements, etc.

About the internship

This is an opportunity to get involved with a live and dynamic project that faces continual resource challenges. The successful candidate will have a choice of which projects to work on based on their own preferences and ideas. We’ll provide supervision and work together to define goals and help solve problems.

As an intern, you will be a proper part of the CycleStreets team, as a fully-paid employee over the summer period, with daily training and co-working.

Read about how our previous intern, Patrick, found the process.

The intern will be hired as an proper salaried employee. Our intern(s) will earn £400 per week, are regarded as part of the team from day one, and the internships last for 10 weeks. We will also come to a flexible arrangement regarding working locations and/or expenses for public area working to ensure that the successful employee is never out-of-pocket.

The paid internship will be based in Cambridge (UK). This is because we feel it is important that there is daily contact as this is aimed to be a two-way process providing lots of training.

As our two current employees work mainly from home, we’ll expect the intern to find their own workspace as we cannot provide an office environment. We’ll meet with you to discuss and plan your work schedule and ideas at internet cafés or meeting rooms in Cambridge, as well as online.

We are not expecting someone with many years of development experience, as such a person would be in a stable job, and the salary level is not intended to reflect this. What is more important to us is someone with the right mindset, a fast learner, who can work at a good rate. Being an internship, this will be a two-way arrangement, with us helping give the student knowledge of working in a large codebase and the challenges this brings – though we do want someone who is a self-starter.

How to apply

To apply, all we need is your CV and a covering letter, sent via e-mail by the end of Monday 30th April 2018. Your covering letter should explain your interests, and include some thoughts on our site (such as a critical analysis, max 1 page), and point us to any code you have written (public code on Github is always a good sign). Feel free to contact us if you have any questions.

We will contact all applicants by the end of Tuesday 1st May.

Interviews will take place on either 2nd/3rd May, according to your availability.

Hiring soon – to work on routing engine challenges

Saturday, May 21st, 2011

CycleStreets will shortly be hiring a full-time core developer to work on our routing engine and website. The aim is to enable us to implement improvements to the routing and implement lots of feature requests a lot more quickly.

This is possible thanks to a series of contracts and grants we've recently obtained, some of which we've recently reported about on this blog.

Our core aim with CycleStreets is to create "routing that thinks like a cyclist". This means including some things, such as turn delays and complex rules that would seem to be challenging to implement with off-the-shelf engines.

We're therefore wanting to take someone on who is able to work on what are interesting computer science problems (as distinct from purely "web development"). However, we'd hope that a suitable person can help work on the website (e.g. backend/frontend integration, general web development. refactoring) as well.

Background info: about our routing engine

The CycleStreets routing system finds, quietest, fastest and balanced cycling routes between two points in the British Isles. It does this by building a route planning version of the map (known as a graph) for each of these types of route.

Each graph consists of vertices and edges that correspond to junctions and streets. On each graph the length of an edge corresponds to the cost for that route type of travelling along a street. So, roads and wide cycle tracks will have relatively short links on the graph for fastest routes, but the links that represent footpaths and bridleways where the cycling speed is slower will be longer. By contrast, on the graph for quietest routes, cycleways and park paths will be short relative to busy roads.

The optimal route of a certain type will then be the shortest path on the graph for that type.

So there are two main parts to the CycleStreets routing system: (1) Building the graphs (2) Finding the shortest path. The quality and performance of CycleStreets is governed by how well we do 1 and 2 respectively.

The current OpenStreetMap (OSM) map of UK & Ireland contains 2 million streets that pass through 20 million points. Streets are usually represented by their centre line, with nodes at junctions. The characteristics of each street, including for example the type of road, whether it is hilly, has a cycle lane, or is a one-way street are used to measure the suitability for cycling. In graph theory speak, they translate into the cost of an edge.

These costs are measured during our daily translation of OSM's UK & Ireland map into a graph by application of a series of rules.

That system is currently rather more complex and opaque than we'd like. Choosing the right values for all of those numbers has been an iterative process as we've tuned the routing engine, often in response to our user's feedback.

We need to:

  • Review the ruleset, re-examining the assumptions they are based on and the order they are applied
  • Make it much clearer to users how the rules have influenced the chosen route (this will confer greater confidence in the generated advice)
  • Include additional sources of information (more information to be published soon on this)
  • Handle junctions better, which is of particular interest currently.

Here in more detail is discussion on some of these:

Junctions – reducing wiggly routes

Simple graphs constructed from maps of street centre-lines lack are limited in their capacity to express how easy it is to cycle through a road junction. This series of photos introduces the problem.

In essence, the simple graph cannot represent banned turns, and nor can it indicate that a right turn across a busy road might incur quite a wait until it is safe to cross. However, some of the turn delay modelling can be derived automatically, knowing the 'before' and 'after' street types, and the turn angle. We believe that accurately representing that sort of information has the best chance of improving the quality of routes recommended by CycleStreets.

The way this route wiggles on and off Glasgow Road is a good example of this problem. (NB Click on the + button in the top-right corner of the map and switch to the OpenCycleMap view to get a better map background.)

Implementing turn delays at every node presents real challenges in terms of the use of a standard A* routing engine. This is further more difficult given the need to avoid very large amounts of RAM being needed.

Solving this problem is a significant technical challenge. It needs to be transparent so that there is a clear link between each piece of data and each rule used in the solution and the decisions that a knowledgeable cyclist would make. The solution must also be scalable, so that neither the amount of time taken to find a route nor the amount of data required to represent the problem, increase significantly. That will make it attractive and manageable. A solution also needs to avoid creating excessive hardware cost requirements.

Finding the shortest path

Shortest path algorithms are very familiar to computer science students, and there are many well established standard techniques that solve the problem. CycleStreets currently uses the A* algorithm, which is implemented in a combination of a Python program and a C++ module.

The 2 million streets and 20 million points of the map, become 5 million edges, and 4 million vertices in a graph. These are compressed by a non-standard technique, called Cell Optimisation (Cello), into 2 million edges and 1 million vertices.

The Python/C++ program can scan the compressed graph to find a route from Land's End to John O'Groats in 2.1 seconds. The vast majority of routes we're interested in are about 10 miles, which can be solved by this program in milli-seconds.

The process of interpreting the generated route from a list of edges and vertices into an itinerary that includes street names and turn directions – the 'unpacking stage' – and storing in a database takes much longer. Performance seems to vary quite a bit, sometimes its very quick but it can take several seconds to process, even for a typical-sized route.

This issue will grow in significance as the number of users of CycleStreets continues to grow, and as new ways of using the routing system emerge.

We want to make the performance aspect of the routing itself, as well as the 'unpacking' stage, as fast and efficient as possible.

More types of route

There is a growing clamour for many more customisable types of routing. Ultra-quiet routes, routes where there is no dismounting and routes that are indifferent about hills.

We should also consider taking into account intermittent links, such as ferry crossing times, or gates that are closed at night.

Our system uses pre-compiled graphs, so each new routing type potentially means adding a new graph. Ulitmately RAM sizeputs a cap on that approach.

Are you the kind of person who can tackle these interesting problems?

We think that these and other challenges form interesting computer science problems.

Do get in touch if you'd be interested in an informal discussion to discuss things further. A formal job description and other details, including application deadlines and details will be online very shortly.

We welcome your feedback, especially to report bugs or give us route feedback.

My comments relate to: *

Your comments: *
URL of page: *
How did you find out about CycleStreets?:
Your name:
Our ref: Please leave blank - anti-spam measure

* Items marked with an asterisk [*] are required fields and must be fully completed.