How can I request graph (for drawing polyline) in walking section of Transit Route API?
Here are walking section from JSON Transit Route API result:
{
"id": "R00133e-C2-S0",
"mode": 20,
"Dep": {
"time": "2019-09-15T09:18:00",
"Addr": {
"y": 21.011375,
"x": 105.808079
},
"Transport": {
"mode": 20
}
},
"Journey": {
"distance": 617,
"duration": "PT10M"
},
"Arr": {
"time": "2019-09-15T09:28:00",
"Stn": {
"y": 21.009895,
"x": 105.812835,
"name": "470 ABC",
"id": "702830459"
}
}
},
You need just need to ad the parameter graph:
Requests coordinate pairs to allow the drawing of a polyline for the route. The
possible values are:
1 (enabled), 0 (disabled)
The default is 0.
With &graph=1 you will retrieve the walking segment of the route in a form of sequence of coordinates.
Yes, I did add the parameter graph=1. But the walking section still has no graph field. Maybe it depends on the country?
Related
I am currently trying to use HERE's API to calculate some tours for trucks.
First, I'm using the Tour Planning API to calculate the optimal tours.
In the second step, I'm using the Route Planning API to visualize these tours and get the exact routes that should be driven.
Somehow I've some problems using the avoid features to not plan routes with U-turns and difficult turns. I've come up with a small example that shows the problem. This is my example tour planning request:
{
"fleet": {
"types": [
{
"id": "1561fwef8w1",
"profile": "truck1",
"costs": {
"fixed": 1.0,
"distance": 5.0,
"time": 0.000001
},
"capacity": [20],
"amount": 1,
"shifts" : [
{
"start" : {
"time" : "2022-12-12T06:00:00Z",
"location" : {"lat": 51.4719851907272,"lng": 7.31300969864971}
},
"end" : {
"time" : "2022-12-12T16:00:00Z",
"location" : {"lat": 51.4807604,"lng": 7.3152156}
}
}
]
}
],
"profiles": [
{
"type": "truck",
"name": "truck1",
"avoid" : {
"features" : ["difficultTurns", "uTurns"]
}
}
]
},
"plan": {
"jobs": [
{
"id": "job_0",
"tasks": {
"deliveries": [
{
"demand": [1],
"places": [
{
"location": {"lat": 51.4736547333341,"lng": 7.29935641079885},
"duration": 300
}
]
}
]
}
},
{
"id": "job_1",
"tasks": {
"deliveries": [
{
"demand": [1],
"places": [
{
"location": {"lat": 51.473125253443,"lng": 7.28609119643401},
"duration": 300
}
]
}
]
}
},
{
"id": "job_2",
"tasks": {
"deliveries": [
{
"demand": [1],
"places": [
{
"location": {"lat": 51.4871939377375,"lng": 7.30587404313616},
"duration": 300
}
]
}
]
}
}
]
}
}
The answer is a tour that is 7.1 km long and takes 43 minutes. I'm now asking the route planning API to give me the exact route with the following request:
https://router.hereapi.com/v8/routes?via=51.4736547333341,7.29935641079885!stopDuration=300&via=51.473125253443,7.28609119643401!stopDuration=300&via=51.4871939377375,7.30587404313616!stopDuration=300&transportMode=truck&origin=51.4719851907272%2C7.31300969864971&destination=51.4807604%2C7.3152156&return=summary&apikey={API_KEY}&departureTime=2022-12-12T06%3A00%3A00&routingMode=short&avoid%5Bfeatures%5D=difficultTurns%2CuTurns
The answer now is a route which is 10.8 km long and takes 72 minutes. So the exact route is now more then 3 km longer for this short route. For lager routes I've already seen differences of 15km and more.
When not putting the avoid U-turns and difficult turns features into the requests, the routes have a roughly similar length. In this small example the route of the tour planning API is 6.4 km and the route of the route planning API 6.9 km which is a acceptable difference.
I'm not sure if route planning API and tour planning API are handling U-turns and difficult turns differently or if there is any way to get the exact routes directly from the tour planning API. Does anybody know how I can get properly planned tours with using the tour planning API and avoiding the difficult turns?
In the problem from the description difficult/uTurn happens at the driver stop itself. Tour planning does not consider the difficult turns at the stop. However, they are considered if they are on the way. That led to the discrepancy in the results from Tour Planning and Routing.
HERE REST API fleet.ls
Consider the following REST API call. Note the Long Lats are in Adelaide Australia which has a TZ of +9:30.
https://fleet.ls.hereapi.com/2/calculateroute.json?waypoint0=-34.8751,138.5276&waypoint1=-34.9042,138.5708;sort&waypoint2=stopOver,600!-34.893,138.5546;sort&departure=2021-01-08T17:15:00&mode=fastest;car;traffic:enabled&legAttributes=-li,-mn,le,bt,tt,-tm,sh&routeAttributes=sm,wp&apikey=xxxxxx
The Departure time is set to:
departure=2021-01-08T17:15:00
However the summary returns the following:
"summary": {
"travelTime": 1010,
"distance": 5102,
"baseTime": 882,
"trafficTime": 1010,
"flags": [],
"departure": "2021-01-08T**17:15:00+10**",
"arrival": "2021-01-08T17:31:49+10"
}
The absolute time is incorrect as the location has a timezone of +9.5 (or +10.5 DST). This, is then passed through to other algorithms used and, well, messes everything up by a half an hour.
It appears you are using version 7 of the Calculate Route API, as shown here. It shows timestamps with only whole-hour offsets, such as 2013-07-04T17:00:00+02.
The docs here for version 8+ of the API show a very different format for its output, including timestamps with full hours and minutes in the offset, such as 2019-12-09T16:05:05+01:00. The full example in docs is:
{
"routes": [
{
"id": "bfaed7d0-19c7-4e72-81b7-24eeb148b62b",
"sections": [
{
"arrival": {
"place": {
"location": {
"lat": 52.53232637420297,
"lng": 13.378873988986015
},
"type": "place"
},
"time": "2019-12-09T16:05:05+01:00"
},
"departure": {
"place": {
"location": {
"lat": 52.53098367713392,
"lng": 13.384566977620125
},
"type": "place"
},
"time": "2019-12-09T16:03:02+01:00"
},
"id": "85357f8f-00ad-447e-a510-d8c02e0b264f",
"summary": {
"duration": 123,
"length": 538
},
"transport": {
"mode": "car"
},
"type": "vehicle"
}
]
}
]
}
I suggest you use the latest v8 of the API (8.14.0 at time of writing this). It should give the correct offsets for Adelaide.
What exactly does the PROXIMITY parameter describe, and why do ORIGIN and TO always have the same PROXIMITY?
Please see the below json snippet taken from the HERE Incident API for an example -
EDIT:
My question is not specific to the json example below but a more general question regarding the meaning of the PROXIMITY parameter.
For instance, "midway between" is pretty self explanatory. What does it mean for a traffic incident to be "at" two points or "past" two points?
In addition, for all the data I have looked at ORIGIN:PROXIMITY:DESCRIPTION is always the same as TO:PROXIMITY:DESCRIPTION. Why?
{
"INTERSECTION": {
"ORIGIN": {
"ID": "",
"STREET1": {
"ADDRESS1": "Pletschenau"
},
"STREET2": {
"ADDRESS1": "Schillerweg"
},
"COUNTY": "Calw",
"STATE": "",
"PROXIMITY": {
"ID": "MID",
"DESCRIPTION": "midway between"
}
},
"TO": {
"ID": "",
"STREET1": {
"ADDRESS1": "Pletschenau"
},
"STREET2": {
"ADDRESS1": "Birkenweg"
},
"COUNTY": "Calw",
"STATE": "",
"PROXIMITY": {
"ID": "MID",
"DESCRIPTION": "midway between"
}
}
},
"GEOLOC": {
"ORIGIN": {
"LATITUDE": 48.73873,
"LONGITUDE": 8.73767
},
"TO": [{
"LATITUDE": 48.74108,
"LONGITUDE": 8.73581
}]
}
}
```
We expecting that your use case does match with the example as follows https://developer.here.com/documentation/examples/rest/traffic/traffic-incidents-via-proximity
This example retrieves traffic incident information related to a specific area of Berlin, as defined by a radius of 15km around a specific point (the prox parameter)
The start(origin) and to(destination) both represents same waypoint here. this explains why these two are not different. In case your API call is different, please share the rest API call.
Is it a violation of the JSON-API spec to allow reverse relationships to be created automatically?
I need to create resources that, when I link A to B in a relationship, automatically links B to A. In this way I can traverse A to find all of its Bs and can find the parent A from a B. However, I don't want to POST/PATCH to 2 relationships to get this right. I want to establish the relationship once.
Now I know that it is an implementation detail as to how the server maintains link/references as well as how the behaviour is established but I want to build the API in such a way that it doesn't violate the spec.
Assuming I have resources Books and Authors. Books have Authors and Authors have Books. The question is, once I relate an Author to a Book, I need the reverse relationship to be created as well. Is it a violation of the spec in any way to assume that this reverse relationship can be automatically created by simply doing one POST to the Books resource's relationship?
By way of example, starting with the book.
{
"data": {
"type": "books", "id": 123, "attributes": ...,
"links": { "self": "/books/123" },
"relationships": {
"self": "/books/123/relationships/authors",
"related": "/books/123/authors"
}
}
}
And the author
{
"data": {
"type": "authors", "id": 456, "attributes": ...,
"links": { "self": "/authors/456" },
"relationships": {
"self": "/authors/456/relationships/books",
"related": "/authors/456/books"
}
}
}
If I establish the link from a book to an author with a POST to /books/123/relationships/authors
{
"data": [{ "data": "authors", "id": "456" }]
}
Do I need to explicitly do the same for the Author 456 as a POST to /authors/456/relationships/books?
{
"data": [{ "data": "books", "id": "123" }]
}
Or can I let the server build the relationship for me so that I can avoid the second POST and just see the automatic reverse relationship at GET /authors/456/relationships/books?
From the perspective of the spec this is only one relationship represented from two different sides. author and book have a many-to-many relationship. This relationship could be represented in author's resource object as well as book's resource object and of course also via there relationship links. Actually it would be a violation of the spirit of the specification if representations wouldn't match. Having one-sided relationships is another story but in that case one side wouldn't know about the relationships at all (e.g. a book is associated with an author but the author model does not know which books are associated with it).
A post to either one side of that relationship creates the relationship between the two records. It shouldn't matter which side is used to create that relationship and if it's created as part of a creation / update to a resource via it's resource object or via a relationship link representing that relationship. The same applies to deletion of that relationship.
Maybe an example would make that even more clear. Let's assume a book is created with a POST to /books?include=author having these payload:
{
"data": {
"type": "books",
"relationships": {
"author": {
"data": {
"type": "authors",
"id": "1"
}
}
}
}
}
The response may look like this:
{
"data": {
"type": "books",
"id": "7",
"relationships": {
"author": {
"data": { "type": "authors", "id": "1" }
}
}
},
"included": [
{
"type": "authors",
"id": "1",
"relationships": {
"books": {
"data": [
{ "type": "books", "id": "7" }
]
}
}
}
]
}
According to the spec, resource identifier objects do not hold attributes.
I want to do a POST to create a new resource which includes other nested resource.
These are the basic resources: club (with name) and many positions (type). Think a football club with positions like goalkeeper, goalkeeper, striker, striker, etc.
When I do this association, I want to set some attributes like is the position required for this particular team. For example I only need 1 goalkeeper but I want to have a team with many reserve goalkeepers. When I model these entities in the DB I'll set the required attribute in a linkage table.
This is not compliant with JSON API:
{
"data": {
"type": "club",
"attributes": {
"name": "Backyard Football Club"
},
"relationships": {
"positions": {
"data": [{
"id": "1",
"type": "position",
"attributes": {
"required": "true"
}
}, {
"id": "1",
"type": "position",
"attributes": {
"required": "false"
}
}
]
}
}
}
}
This is also not valid:
{
"data": {
"type": "club",
"attributes": {
"name": "Backyard Football Club",
"positions": [{
"position_id": "1",
"required": "true"
},
{
"position_id": "1",
"required": "false"
}]
}
}
}
So how is the best way to approach this association?
The best approach here will be to create a separate resource for club_position
Creating a club will return a url to a create club_positions, you will then post club_positions to that url with a relationship identifier to the position and club resource.
Added benefit to this is that club_positions creation can be parallelized.