TravelTime is a platform that can be accessed via our API, by any website / app / or geo-spatial database. The platform then sits in the background, crunching that website’s locations using our travel time data. We return their locations, ranked and sorted by travel time, to or from an origin (or multiple origins).

We don’t build any user screens – that’s something our clients’ do (they know their users better than we do). So for example a retailer will build their own store-locator page and we’ll sit in the background instantly calculating a user’s travel time to the stores they can reach fastest, and show them the route.

We have RESTful API which you access by making a JSON call.
You can also request the data in WKT (Well Known Text). We are adding new support for GeoHash search and Bounding Box search which should be ready in September 2015.
In essence, the API has 3 parts:

  1. TimeMap – which outputs a polygon showing the area accessible by time from a user’s location.
  2. TimeFilter – which assigns a time to a lat/lng point
  3. Routes – which is a door-to-door route planner.

Most developers who use the API really like it – the usual comments are ‘it’s really easy to use’, and ‘it just works’. Ask us for an API key and see what you think.




The TravelTime Platform is different because it allows maps to be searched by time instead of distance.
Currently, a search of locations is by distance “what is within 5 miles”. That’s a problem because results shown by distance take no account of how long it takes to actually get there. 30 minutes to get to one side of a radial search, might be 15 mins to get to the other side.
But when someone searches for a location, the odds are that they intend to travel there. And when travelling they care more about time than distance. That’s why TravelTime returns massively more relevant results for people who plan to travel to your locations (shop, property, date, restaurant, hotel, job etc). For example this map shows what you can do within 30 mins of London ‘right now’. It show all possible locations within 30 minutes (the highlighted area – TimeMap). On top of this it ranks all locations by travel time (TimeFilter). And then we also return the best route to each lat/long.

Google Maps / CityMapper / Bing / Sat Nav … and many more facilities …calculate A to B routes. They’re great when you know where you need to go. But what we do is the bit before that, when you say “where could we go”, or “where’s the shop / restaurant / job / hotel (etc) I can get to fastest”. We enable maps / data to be searched by travel time. We instantly match your visitors to your physical locations by travel time, so that they can find what they want and you can get more people through your doors. That’s why we’re different. And that difference is really important.

We license this technology to people who make their money from locations. Clients include:

  1. CountryWide – The UKs largest group of estate agent –
  2. Zoopla – UK property Search –
  3. A new iOS app that allows you to search for jobs within a commutable distance
  4. Microsoft even wrote a case history about our work with Countrywide (who use Bing Maps) where TravelTime generated a 300% increase in conversions (vs distance)

What makes us different

Within a single API, the TravelTime provides your users with 3 pieces of travel info that mean they won’t leave your site (till they walk in through your front door)

  1. Discover an area (TimeMap)
  2. Decide which location to visit (TimeFilter ranks & sorts all locations by travel time)
  3. Directions there (Routing).

Your user doesn’t have to dip out of your site to check travel times and routes on someone’s site – so won’t be exposed to your competitor’s ads. With TravelTime you can give them all the travel info they need with a single API. And that’s really important.

We don’t provide maps or map tiles. We search large amounts of data by travel time instead of distance and we return the results to our client who can display it however they want. Our platform works with all mapping API’s – Google, Bing, OSM, Leaflet. We have clients who have used Bing, Google and Mapbox. On some of the iOS apps they default to Apple Maps. And we have some clients who don’t use a map at all and present their users with a list.

So – think of us as a plugin or enhancement to these platforms, not a replacement for them.

Whatever device your user currently uses to view your site, can also show results from TravelTime. So, all web-enabled devices which in the main means mobile, tablet and desktop.
Pretty much, as many as you want. You can send us 1,000’s of lat /longs, and in under a second we’ll have assigned a travel time to each, for each mode of transport, and returned the data to you. We include 2,000 locations in the first 1 API call (per transport mode).
Yes – it’s exactly what do. They show properties suitable for 2 people who want to live together but work in different places (see the Venn diagram feature). We create 2 travel time areas (1 per person) and lay them together to find the overlap where they can live.

You can have as many overlap areas as you want – 2, 10, 100… your choice.

Train (intercity, suburban, DLR … all types), tram, underground, driving, walk, bus, and most ferries. Pretty much, if it goes on roads, rails, footpaths, cycle tracks, or it has a route or a timetable, we’ve got it covered. Not planes. Not yet. Watch this space.
We include all public transport timetables, and average road speeds by time of day.
For both walking and cycling we use an average speed – and we know that some people go faster than others (lycra vs a bike with a basket).
Absolutely, that’s one of the really good things about the TravelTime platform – it’s fully multi-modal. Searching by all modes can generate a journey that is ‘drive to the station, catch a train, then the tube, then a bus, and then walk to the destination’.

The images below are for a trip by public transport from Sennen Cove (Land’s End) to John O’Groats – on a map and as a list.


1. Senen to JOG

Sure. If someone is searching a recruitment site for ‘suitable jobs within 60 minutes commute using all modes’, it’s unlikely that they’ll actually walk for the full hour.
So you can cap walking at say 15 minutes, and return results for up to 15 mins walking with the remainder of the requested travel time on public transport.
A journey involving driving and train will route you to the station that is served by the train that gets you to your destination fastest.
That might be a more distant station but which is served by a faster train at the relevant moment. The TravelTime platform makes this calculation automatically.
If your journey includes changing platforms, then we include the time it takes to move from one platform to another. On some underground stations it takes ages to get from one line to another, and we know the time from any line to any other line.
We also factor in that the user needs to be on the platform 30 seconds before the train leaves – that’s when the doors shut.

We’re trying to generate results that are useful to humans. We know we can never be 100% right (for example the traffic lights just changed to red; or 100 people decide to cross the pedestrian crossing in front of you) and that’s OK. We’re trying to produce results that real people can get to, routes real people can actually travel, so we make the calculations as human as we can.

We mean from Lat/Long to Lat/Long, step by step, following real paths, roads, rails, bus routes etc. We don’t ‘get fairly near’ and then guess (as some other sites do).
And our data can be shown on a map, or given as a list of turn-by-turn instructions.

The image below is Buckingham Palace to Guildford, via Waterloo Station, and it shows the walk on footpaths through Green Park.


It’s possible, though every client who has asked about this, then found that our platform is so fast that they haven’t needed it.
We don’t currently offer real-time information, although the platform does accept some real-time feeds (from TfL for example).

The reason we don’t make real-time available is that most of our clients don’t want it. If you operate a property website, it’s more useful for your users to know the area they can normally reach at a particular time of day, than that the traffic is really slow today because there’s been an accident.

But scheduled roadworks or public transport delays, are picked up in our twice weekly platform update.


Here’s an example. Perhaps you run a recruitment site and want to tell registered job seekers about new vacancies as they get posted to your site? We’ll match the location of new & suitable vacancies being posted to your site, to your database of jobseekers. We’ll let you know when there’s a geographic fit – i.e. it’s the right opportunity and it’s within the travel time / transport mode that your job seeker specified. We’ll return that information to you and how you then use it is up to you. Send them a text, an email, an alert on your site, a message by pigeon post … whatever works for you and them.

We’re hosted on dedicated servers in London, duplicated in Germany, and then backed up on Amazon Web Services.
Since launching commercially in late 2013, we’ve had zero downtime.
As we deploy in more territories so we’ll keep an eye on latency and use local hosting where needed.
We know consumer-facing sites (in particular) need to return instant results – we’ve built the platform to deliver just that (and we continually work to reduce latency even more).
Our speeds depend on the search being conducted, but as an example of a complex (i.e. slow) search, we can take;

  • A user’s request for 60 mins driving from the middle of London, and produce a TimeMap
  • Match 4,000 locations (e.g. houses) to that TimeMap and rank & sort them all by their individual travel times (TimeFilter)
  • Return this to our client’s site or app within 600 milliseconds.
  • And when the user wants to know the route to any of those 4,000 locations, we’ve already calculated it as a part of TimeFilter and can return it in milliseconds.

It’s important to note, our platform does all the heavy lifting – there’s no calculation being performed on the user’s device (so there’s no SDK). It’s just a JSON call to our RESTful API.

  1. There’s no cost while you develop your solution and we’ll help you (without charge).
  2. The cost comes when you want to go live, and the amount varies. We’ve found most clients prefer a fixed monthly fee and unlimited API calls – they say it makes budgeting easier than trying to cope with a variable amount each month (as their usage fluctuates).
    So we general agree country specific, 2 year contracts, for a fixed fee (where that fee has some regard to projected usage and any other specific client criteria).
  3. But if you have a different idea, we’re up for the conversation. Ultimately what we want are happy clients deriving value from TravelTime.
We ask for this to be capped at 150 concurrent calls (that’s 150 exactly simultaneous calls to our server). As an example, think of glasses of water (API calls) being poured into a jug (our servers). Our current ‘jug’ can cope with 150 ‘glasses’ being poured at the same time so if we want to add glass 151, we need to pause while we ‘drink’ one of the first 150 glasses (i.e. finish one of those 150 searches). Pausing impacts our ability to deliver our SLA to our customers – hence the 150 cap. But if you think you’re going to need a higher concurrency, talk to us because we can rapidly add more jugs (increase server capacity) – we simply need to know in advance. We’ve built the platform to scale up very easily.

  • ‘The TravelTime Functionality shall be available to the Licensee for 98% of the time calculated on a calendar month basis, exclusive of any scheduled maintenance, such scheduled maintenance to be between the hours of midnight to 6.00 a.m. UK time, and iGeolise shall notify the Licensee in advance of such maintenance least 24 hours in advance, by email or by phone call.’


  • While you’re developing. The API is straight forward and most developers say it’s one of the easiest they’ve ever used. Our fastest implantation to date has been 2 days. And we’re here to help – by email, on the phone, face to face, and we’re always happy to have client developer days.
  • Once you’re live. We’re still here … email, phone, face to face. Here’s the thing – we want our clients to get the most value they possibly can from TravelTime, so we’ll do what it takes to help. Whether it’s coming up with ideas, or sitting alongside your developers while build. Tell us what you want and if we can do it, we will.
Live as at July 2015 are the UK, the Republic of Ireland, Thailand, Switzerland, New South Wales in Australia, East & West coast USA and France.

Many more countries have been successfully trialled and will go live over the coming months. And the next stage will be to link countries together and add air travel.

Best often means fastest – but it could also mean ‘fewest changes’, ‘disabled access’, ‘lowest CO2 emissions’ or perhaps ‘lowest financial cost’ (‘walk-up fares’ are a feature of the platform). We can enable them all.

You decide what your users will think is ‘best’, and that’s what we’ll deliver. Or maybe, give them the choice?

Absolutely – it’s our favourite question.

  • Email us at
  • Phone us on +44 (0) 207 096 1473
  • Or use the live chat box, and talk to us now

We can get you an API key right away.

We used it all up tomorrow. Clean out of stock for today. But come back yesterday – we may have some more in.