Options.RmdThe core list of options to pass to the API is summarised in the table below:
| Option | Default Value | Explanation |
|---|---|---|
| travelType | "bike" |
The chosen travel type - car, walk, bike or transit (or multiple, for routes) |
| travelTimes | list(600, 1200, 1800) |
For polygons, the travel times to return (in seconds) |
| intersectionMode | "union" |
For polygons, the calculation to apply for multiple sources (union or intersection) |
| carRushHour | FALSE |
Whether to account for rush-hour congestion for the car travelType |
| walkSpeed | 5 |
The default walking speed, in km per hour |
| walkUpHillAdjustment | 10 |
The percentage increase in walking time if uphill |
| walkDownHillAdjustment | 0 |
The percentage increase in walking time if downhill |
| bikeSpeed | 15 |
The default bike speed in km per hour |
| bikeUpHillAdjustment | 20 |
The percentage increase in cycling time if uphill |
| bikeDownHillAdjustment | -10 |
The percentage in increase in cycling time if downhill |
| transitDate | NULL |
The date (YYYYMMDD) on which public transport is calculated (NULL defaults to most recent possible) |
| transitTime | NULL |
The time in seconds from midnight at which public transport is calculated (NULL defaults to now) |
| transitDuration | NULL |
The time window in which public transport is calculated (s or .h.m.s) |
| transitMaxWalkingTimeFromSource | NULL |
Max seconds walking from source to bus/train etc |
| transitMaxWalkingTimeToTarget | NULL |
Max seconds walking from bus/train etc to target |
| transitEarliestArrival | FALSE |
Whether to calculate public transport routes based on earliest arrival (or shortest duration) |
| transitMaxTransfers | NULL |
Maximum number of changes on public transport (NULL = no limit) |
| edgeWeight | "time" |
Whether to calculate based on travel time or distance |
| maxEdgeWeight | 1800 |
Maximum time/distance to consider (in seconds/metres or .h.m.s) |
| elevation | FALSE |
Account for terrain elevation? |
| serializer | "geojson" |
The data serializer to use - geojson or json |
| srid | 4326 |
The SRID of the returned data (currently only 4326 supported) |
| minPolygonHoleSize | NULL |
Minimum area of holes in polygons |
| buffer | NULL |
Parameters for manipulating the returned polygons |
| simplify | NULL |
Parameters for manipulating the returned polygons |
| quadrantSegments | NULL |
Parameters for manipulating the returned polygons |
| decimalPrecision | NULL |
Parameters for manipulating the returned polygons |
Sometimes, things go wrong! With all the TargomoR services, there are several extra arguments which may help you:
To each of getTargomo* and addTargomo*, you can add verbose = TRUE - this will print out the full API request to the console so you can check what’s going on. Example output is below:
-> POST /britishisles/v1/time?key=<TARGOMO_API_KEY> HTTP/1.1
-> Host: api.targomo.com
-> User-Agent: libcurl/7.64.1 r-curl/4.2 httr/1.4.1
-> Accept-Encoding: deflate, gzip
-> Accept: application/json, text/xml, application/xml, */*
-> Content-Length: 448
->
>> {
>> "edgeWeight": "time",
>> "maxEdgeWeight": 1800,
>> "elevation": false,
>> "sources": [
>> {
>> "id": 1,
>> "lat": 51.5007,
>> "lng": -0.1246,
>> "tm": {
>> "bike": {
>> "speed": 15,
>> "uphill": 20,
>> "downhill": -10
>> }
>> }
>> }
>> ],
>> "targets": [
>> {
>> "id": 1,
>> "lat": 51.5055,
>> "lng": -0.0754
>> },
>> {
>> "id": 2,
>> "lat": 51.5117,
>> "lng": -0.1246
>> }
>> ]
>> }
<- HTTP/1.1 200
<- Date: Wed, 20 Nov 2019 22:59:11 GMT
<- Content-Type: application/json
<- Content-Length: 109
<- Connection: keep-alive
<- Access-Control-Allow-Origin: *
<- Access-Control-Allow-Headers: origin, content-type, accept, authorization, x-requested-with
<- Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, HEAD
<- Content-Encoding: gzip
<- Server: Targomo | service.targomo.com
<- Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
<- X-Frame-Options: DENYFor long-running requests you can add a progress bar with progress = TRUE:
|========================== | 50%If you need to set extra config settings for using httr, do so with the config argument. A common use case might be if you’re behind a proxy server - in this case you would do (for example):
If you’ve got long requests that need more time and are deploying your code in an environment with a default curl timeout (often 10 seconds), try using timeout = n, where n is the number of seconds to wait before giving up. Internally this is passed to httr::timeout.