Tag Archives: API

Matters relating to Application Programming Interfaces (API)

Exploring traffic times data

A recent investigation here at Cranfield University considered the sources of road journey traffic time data, and this blog recounts some of that investigation. First of all comes the sources of the data.

Highways England Data

Thanks to the fantastic open data revolution we now have a huge wealth of public data available via the www.data.gov.uk portal. Here for example we can source data on traffic times from the Highways England agency. Their traffic times data can be obtained from https://data.gov.uk/dataset/dft-eng-srn-routes-journey-times.

This data series provides average journey time, speed and traffic flow information for 15-minute periods since April 2009 on all morotways and ‘A’ roads managed by the Highways Agency, known as the Strategic Road Network, in England, with journey times and speeds estimated using a combination of sources, including Automatic Number Plate Recognition (ANPR) cameras, in-vehicle Global Positioning Systems (GPS) and inductive loops built into the road surface.

For example, we downloaded the CSV file: ‘Feb15.csv‘ relating to February 2015 data. The first line of which by example reads:

LinkRef	Link Description	Date	Time Period	AverageJT	Average Speed	Data Quality	Link Length	Flow
AL215	A120 between A133 and A1232 (AL215)	2015-02-10 00:00:00	67	305.47	105.12	1	8.9200000762939453	286.50

This line of data relates to a stretch of road north of Colchester, UK on the A120. Key information here being that on 10^th February 2015, for this c.9km stretch of road, it took 287 seconds (c4.8mins) to drive. The time of day is given as 67. This number is one of 96 15-minute intervals in the day that the data refers to (0-95 where 0 indicates 00:00 to 00:15). 67 is therefore 4:45:00 PM to 5:00:00 PM (see a useful table at the end of this article for working this out).

Google Traffic Data

Another useful source of data is from Google. The Google routing and traffic functions can be used by making a call to the Google ‘Distance Matrix’ API, described here:

https://developers.google.com/maps/documentation/distance-matrix/intro#traffic-model

Using the excellent ‘Postman‘ tool, We can formulate and test a REST call to the Google distancematrix API.

https://maps.googleapis.com/maps/api/distancematrix/json?units=metric&origins=enc:{s{{H{ovD:&destinations=enc:g{t{HqtiE:&departure_time=now&traffic_model=best_guess&key=<API KEY>

Parameters for this API are as follows:
units = metric values (e.g. km)
origins = startint point (encoded)
destinations = finish point (encoded)
departure time = can’t be historical, ‘now’ = keyword
traffic model = best guess (not optimistic/pessimistic)
API key = the personal API

The parameters origins and destinations hold locations in latitude and longitude. As an alternative to decimal degree values for these, there can be encoded values used in the URL. To encode loctions the polyline utility can be used: See https://developers.google.com/maps/documentation/utilities/polylineutility

The resultant response to this REST call, made using Postman to send query off (GET), is:

{
    "destination_addresses": [
        "A120, Colchester CO7, UK"
    ],
    "origin_addresses": [
        "A120, Ardleigh, Colchester CO7, UK"
    ],
    "rows": [
        {
            "elements": [
                {
                    "distance": {
                        "text": "8.0 km",
                        "value": 7993
                    },
                    "duration": {
                        "text": "5 mins",
                        "value": 278
                    },
                    "duration_in_traffic": {
                        "text": "5 mins",
                        "value": 301
                    },
                    "status": "OK"
                }
            ]
        }
    ],
    "status": "OK"
}

Key information here being that at the time of making the call (‘now’), for this c.8km stretch of road, it took between 278 to 301 seconds (c4.6 to 5.0 mins) to drive. Key to this is the difference between the ‘duration’ and ‘duration_in_traffic’ values. Google note the allows you to ‘receive a route and trip duration (response field: duration_in_traffic) that take traffic conditions into account’. Note that ‘the departure_time must be set to the current time or some time in the future. It cannot be in the past’.

So in this way the Google approach allows a definition of the delays in drive time caused by traffic conditions. Although this cannot be determined retrospectively, a speculative future date can be selected whereby a prediction is made based on previous traffic conditions.

Utilities

The table used to calculate the time period for the Highways England data, described above:

Period	From	To
0	12:00:00 AM	12:15:00 AM
1	12:15:00 AM	12:30:00 AM
2	12:30:00 AM	12:45:00 AM
3	12:45:00 AM	1:00:00 AM
4	1:00:00 AM	1:15:00 AM
5	1:15:00 AM	1:30:00 AM
6	1:30:00 AM	1:45:00 AM
7	1:45:00 AM	2:00:00 AM
8	2:00:00 AM	2:15:00 AM
9	2:15:00 AM	2:30:00 AM
10	2:30:00 AM	2:45:00 AM
11	2:45:00 AM	3:00:00 AM
12	3:00:00 AM	3:15:00 AM
13	3:15:00 AM	3:30:00 AM
14	3:30:00 AM	3:45:00 AM
15	3:45:00 AM	4:00:00 AM
16	4:00:00 AM	4:15:00 AM
17	4:15:00 AM	4:30:00 AM
18	4:30:00 AM	4:45:00 AM
19	4:45:00 AM	5:00:00 AM
20	5:00:00 AM	5:15:00 AM
21	5:15:00 AM	5:30:00 AM
22	5:30:00 AM	5:45:00 AM
23	5:45:00 AM	6:00:00 AM
24	6:00:00 AM	6:15:00 AM
25	6:15:00 AM	6:30:00 AM
26	6:30:00 AM	6:45:00 AM
27	6:45:00 AM	7:00:00 AM
28	7:00:00 AM	7:15:00 AM
29	7:15:00 AM	7:30:00 AM
30	7:30:00 AM	7:45:00 AM
31	7:45:00 AM	8:00:00 AM
32	8:00:00 AM	8:15:00 AM
33	8:15:00 AM	8:30:00 AM
34	8:30:00 AM	8:45:00 AM
35	8:45:00 AM	9:00:00 AM
36	9:00:00 AM	9:15:00 AM
37	9:15:00 AM	9:30:00 AM
38	9:30:00 AM	9:45:00 AM
39	9:45:00 AM	10:00:00 AM
40	10:00:00 AM	10:15:00 AM
41	10:15:00 AM	10:30:00 AM
42	10:30:00 AM	10:45:00 AM
43	10:45:00 AM	11:00:00 AM
44	11:00:00 AM	11:15:00 AM
45	11:15:00 AM	11:30:00 AM
46	11:30:00 AM	11:45:00 AM
47	11:45:00 AM	12:00:00 PM
48	12:00:00 PM	12:15:00 PM
49	12:15:00 PM	12:30:00 PM
50	12:30:00 PM	12:45:00 PM
51	12:45:00 PM	1:00:00 PM
52	1:00:00 PM	1:15:00 PM
53	1:15:00 PM	1:30:00 PM
54	1:30:00 PM	1:45:00 PM
55	1:45:00 PM	2:00:00 PM
56	2:00:00 PM	2:15:00 PM
57	2:15:00 PM	2:30:00 PM
58	2:30:00 PM	2:45:00 PM
59	2:45:00 PM	3:00:00 PM
60	3:00:00 PM	3:15:00 PM
61	3:15:00 PM	3:30:00 PM
62	3:30:00 PM	3:45:00 PM
63	3:45:00 PM	4:00:00 PM
64	4:00:00 PM	4:15:00 PM
65	4:15:00 PM	4:30:00 PM
66	4:30:00 PM	4:45:00 PM
67	4:45:00 PM	5:00:00 PM
68	5:00:00 PM	5:15:00 PM
69	5:15:00 PM	5:30:00 PM
70	5:30:00 PM	5:45:00 PM
71	5:45:00 PM	6:00:00 PM
72	6:00:00 PM	6:15:00 PM
73	6:15:00 PM	6:30:00 PM
74	6:30:00 PM	6:45:00 PM
75	6:45:00 PM	7:00:00 PM
76	7:00:00 PM	7:15:00 PM
77	7:15:00 PM	7:30:00 PM
78	7:30:00 PM	7:45:00 PM
79	7:45:00 PM	8:00:00 PM
80	8:00:00 PM	8:15:00 PM
81	8:15:00 PM	8:30:00 PM
82	8:30:00 PM	8:45:00 PM
83	8:45:00 PM	9:00:00 PM
84	9:00:00 PM	9:15:00 PM
85	9:15:00 PM	9:30:00 PM
86	9:30:00 PM	9:45:00 PM
87	9:45:00 PM	10:00:00 PM
88	10:00:00 PM	10:15:00 PM
89	10:15:00 PM	10:30:00 PM
90	10:30:00 PM	10:45:00 PM
91	10:45:00 PM	11:00:00 PM
92	11:00:00 PM	11:15:00 PM
93	11:15:00 PM	11:30:00 PM
94	11:30:00 PM	11:45:00 PM
95	11:45:00 PM	12:00:00 AM

Building a mobile mapping application

Leaflet mobile mapping application

Our earlier articles on mobile application development demonstrated the process of getting an app up and running on an Android phone using Adobe PhoneGap and GitHub. For the purposes of this article we’re going to assume that you are now comfortable with that process and will demonstrate how easy it is begin building mobile mapping applications. This is something we are developing a lot of interest in here at Cranfield University.

As with previous examples, the app is going to be based on a package of HTML, CSS and JavaScript code and will therefore use one of the many JavaScript web mapping APIs available. Any of the following APIs would work well:

Google Maps API
ArcGIS API for Javascript
Leaflet
OpenLayers
OS OpenSpace API

The decision on which one to use will depend on what the functional requirements of your app are, how familiar you are with a particular API and a number of other factors. For this example we are going to build a simple mobile web map using the Leaflet mapping API. Leaflet is an extremely lightweight JavaScript library which makes it ideal for bundling with a mobile app, as we shall see shortly. It is also relatively simple to use and has great flexibility for puling in geospatial resources from a number of different sources, in a variety of formats.

The Leaflet website provides a page of useful examples to get you started with creating basic web maps. Below is a typical web page that would display a basic web map using Leaflet. You can save this code to a HTML file and view it in a browser to test it out for yourself.

<!DOCTYPE html>
<html>
<head>
<title>Basic Leaflet Map</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<link rel="stylesheet" href="http://cdn.leafletjs.com/leaflet-0.7.1/leaflet.css" />

<style type="text/css">
body {
	padding: 0;
	margin: 0;
}
html, body, #map {
	height: 100%;
}
</style>
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" />
</head>
<body>
<div id="map"></div>
<script src="http://cdn.leafletjs.com/leaflet-0.7.1/leaflet.js"></script> 
<script>
	var map = L.map('map').setView([52.04, -0.73], 12);
        L.tileLayer('http://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png', {
		maxZoom: 18			
	}).addTo(map);
</script>
</body>
</html>

The process of turning this into a mobile app is very straightforward, assuming you’ve already got your PhoneGap/Cordova framework in place. Rather than build a new index.htm for our project, we’ll take the default index.htm that has been created for us and drop in the relevant sections of the Leaflet map example above into the correct places. The index.htm file that sits within the www folder of you mobile app framework (taken from the default PhoneGap example on GitHub) should look something like this:

<html>
    <head>
        <meta charset="utf-8" />
        <meta name="format-detection" content="telephone=no" />
        <meta name="viewport" content="user-scalable=no, initial-scale=1, maximum-scale=1, minimum-scale=1, width=device-width, height=device-height, target-densitydpi=device-dpi" />
        <link rel="stylesheet" type="text/css" href="css/index.css" />
        <title>Hello World</title>
    </head>
    <body>
        <div class="app">
            <h1>PhoneGap</h1>
            <div id="deviceready" class="blink">
                <p class="event listening">Connecting to Device</p>
                <p class="event received">Device is Ready</p>
            </div>
        </div>
        <script type="text/javascript" src="phonegap.js"></script>
        <script type="text/javascript" src="js/index.js"></script>
        <script type="text/javascript">
            app.initialize();
        </script>
    </body>
</html>

The key parts of the Leaflet map example are as follows:

<link rel="stylesheet" href="http://cdn.leafletjs.com/leaflet-0.7.1/leaflet.css" />

This ensures the appropriate CSS files are loaded so that the map is is styled correctly.

body {
	padding: 0;
	margin: 0;
}
html, body, #map {
	height: 100%;
}

Here we are defining some layout parameters, including how much space the #map element of the page should use

<div id=”map”></div>

This is the container in the body of the page that will house our map

<script src="http://cdn.leafletjs.com/leaflet-0.7.1/leaflet.js"></script>

Load in the Leaflet API

<script>
	var map = L.map('map').setView([52.04, -0.73], 12);
	L.tileLayer('http://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png', {
		maxZoom: 18			
	}).addTo(map);
</script>

This is the code that generates and renders the map on the page.

Dropping these elements into our existing index.htm whilst retaining the important components (such as app.initialise(); and the calls to phonegap.js and js/index.js) that are already there, gives a page that looks as follows:

<html>
    <head>
        <meta charset="utf-8" />
        <meta name="format-detection" content="telephone=no" />
        <meta name="viewport" content="user-scalable=no, initial-scale=1, maximum-scale=1, minimum-scale=1, width=device-width, height=device-height, target-densitydpi=device-dpi" />
        <link rel="stylesheet" type="text/css" href="css/index.css" />
		<meta name="viewport" content="width=device-width, initial-scale=1.0">
		<link rel="stylesheet" href="http://cdn.leafletjs.com/leaflet-0.7.1/leaflet.css" />
        <title>Basic Leaflet Mobile Map</title>
    </head>
    <body>
        <div class="app">
            <div id="map"></div>

        </div>
	<script src="http://cdn.leafletjs.com/leaflet-0.7.1/leaflet.js"></script> 
	<script>
		var map = L.map('map').setView([52.04, -0.73], 12);		
	        L.tileLayer('http://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png', {
			maxZoom: 18					
		}).addTo(map);
	</script>
        <script type="text/javascript" src="phonegap.js"></script>
        <script type="text/javascript" src="js/index.js"></script>
        <script type="text/javascript">
            app.initialize();
        </script>
    </body>
</html>

This can now be compiled and deployed to your device using the process detailed earlier to give you a simple mobile mapping application.

Hosting libraries and APIs locally

Before we finish, we shall make one more minor alteration to our app to improve efficiency and performance. Currently the app loads up the Leaflet API from http://cdn.leafletjs.com/leaflet-0.7.1/leaflet.js. We are going to take a copy of the full API, copy it to our app’s folder tree and deploy it to the phone so that our app can reference it locally rather than having to load it over web each time the app is launched. This will reduce the reliance on network connectivity and speed up application launch times as well as eliminate any reliance on the Leaflet website; we want our app to continue to work regardless of whether any remote websites may be experiencing problems of their own.

The full leaflet API can be downloaded here:
http://leafletjs.com/download.html
Unpack the zipfile and place the contents into a subfolder of your www folder named leaflet within your mobile app framework. All that needs to be done now is to modify the calls in your code that load the Leaflet API and CSS so that they reference your local copies. They should be changed from

<link rel="stylesheet" href="http://cdn.leafletjs.com/leaflet-0.7.1/leaflet.css" />
<script src="http://cdn.leafletjs.com/leaflet-0.7.1/leaflet.js?2"></script>

<link rel="stylesheet" href="leaflet/leaflet.css" />
<script src="leaflet/leaflet.js"></script>

This change will make your app almost fully self sufficient, without any reliance on loading libraries from external websites. Note that the map tiles that make up your map are still being loaded from the following location:
http://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png
Your app will therefore still require a working internet connection in order to function correctly. In our next post we’ll discuss bundling a selection of map tiles with your application so it can be used completely offline with no internet connection

Leaflet mobile mapping application

Spreading some festive cheer

Before we wrap up for the Christmas and New Year break at Cranfield University, here’s fun little map we’ve put together. Using the twitter4j Java library and the Twitter API, we collected a sample of 80,000 geotagged tweets over a three day period this week that matched a short list of festive and Christmas related keywords. The data was then plotted onto a map of the UK and grouped by county. The totals were then normalised against a random sample of 38,000 tweets, also grouped by county, that were collected earlier in the year. This removed the effect of Twitter population density, leaving the concentration of Christmas tweets in relation to that county’s normal levels of Twitter activity.

The Highlands, Cumbria, North Yorkshire, Norfolk and central Wales certainly seem to be getting into the spirit of things. The south of England on the other hand has some catching up to do, in comparison. We should add that at no stage have we measured sentiment (good or bad), simply instances of related keywords.

Merry Christmas and a happy New Year from all at Geothread!

Santa sightings

It seems appropriate that we leave you with something festive and fun before we take a break here at Cranfield University for Christmas and New Year. We’ve pooled together our mapping and data processing expertise and are proud to present you with The Unofficial Santa Sightings Map, 2012. The map takes its data from Twitter in the form of geotagged tweets posted over the past few days. It would appear Santa’s been doing a fair bit of travelling this week, with a surprising number of sightings as far north as the Highlands of Scotland.

A very merry Christmas and happy New Year to you all, see you in 2013.

Santa sightings, 2012

GeoThread

Cranfield Uni GeoSciences blog