Bug: Here routing isolines API returning same polygon for all distances - here-api

For some coordinates, the Here isoline API returns the same polygon for all the time distances, regardless of the range[values] value.
The example is for Burlington GO train station, ON, Canada, and changing the coordinates a few meters causes invalid data.
example:
curl --location -g --request GET 'https://isoline.router.hereapi.com/v8/isolines?transportMode=pedestrian&range[type]=time&range[values]=50,600&destination=43.339900,-79.809388&apikey=XXXXXX'
{
"arrival": {
"time": "2022-08-31T06:28:52+00:00",
"place": {
"type": "place",
"location": {"lat": 43.33981,"lng": -79.80958},
"originalLocation": { "lat": 43.3399,"lng": -79.8093881}
}
},
"isolines": [
{
"range": {"type": "time","value": 50},
"polygons": [{"outer": "BG86o1yC3mmn4E1C2GhI2C1KAhI1CArF4K1KgI1CiIqB2CgEA4G" }
]
},
{
"range": {"type": "time","value": 600},
"polygons": [{"outer": "BG86o1yC3mmn4E1C2GhI2C1KAhI1CArF4K1KgI1CiIqB2CgEA4G"}
]
}
]
}
If I change the coordinates just a few meters, to "lat": 43.3403845, "lng": -79.8089106 then it returns correct isolines.
Is there a best practice when selecting destination coordinates, any extra parameter I should use to make the results more predictable?
I consider this a bug, if you cannot return valid results you should throw an error, not return invalid data to clients.

I think you can get better results if you use the additional parameter "radius" (meters) for the place (lat, lng) that you provided.
This parameter instructs the router to consider all places within the given radius as potential candidates for route calculation. This can be either because it is not important which place is used, or because it is unknown. Radiuses wider than 200 meters are not supported.
For example: destination=43.339900,-79.809388;radius=100.
I hope this information is useful for you.
Regards.

Related

How to quantize specific layers on OpenVINO Workbench?

I have a trained onnx model that needs to be quantized to INT8. But I want my last fully connected layers are still in FP32 or FP16. So how can I choose specific layers to quantize (or not to quantize)?
PS when I was working with NNCF, I just use parametr ignored_scopes. Maybe is there something similar here at Workbench?
Use "ignored" parameter in configuration file to exclude nodes or operation types from optimization.
"algorithms": [
{
"name": "DefaultQuantization", // Optimization algorithm name
"params": {
"ignored": {
// List of nodes that are excluded from optimization
"scope": [
"<NODE_NAME>"
],
// List of types that are excluded from optimization
"operations": [
{
"type": "<NODE_TYPE>",
// Includes excluding by attributes
"attributes": {
"<NAME>": "<VALUE>" // Lists of values is not included
}
},
{
"type": "<NODE_TYPE>" // Excluding only by type
}
]
}

HERE Routing API - How to use publicTransportTimeTable mode with multiple waypoints using calculate route resource?

I'm using calculateroute resource to calculate a route between multiple waypoints.
https://route.api.here.com/routing/7.2/calculateroute.json?app_id={APP_ID}&app_code={APP_CODE}&waypoint0=-25.4327193,-49.2806026;;0&waypoint1=-25.4392733,-49.2722581;;1&waypoint2=-25.4367652,-49.2833011;;2&waypoint3=-25.4327193,-49.2806026;;3&waypoint4=-25.4327193,-49.2806026;;4&waypoint5=-25.4392733,-49.2722581;;5&departure=2019-09-09T07:10:00-03:00&mode=fastest;car;traffic:disabled;motorway:0&improveFor=distance&language=pt-br&representation=navigation&metricSystem=metric&vehicletype=diesel,5.5
I was using departure parameter to set the initial date of the route, but now, instead of departure, I need to use arrival time in some cases. I was using car mode, but as arrival parameter requires publicTransportTimeTable, I set it this way.
https://route.api.here.com/routing/7.2/calculateroute.json?...&mode=fastest;publicTransportTimeTable;motorway:0..
Then the return was this error message: "Time Table Transit Routing is only supported for two StopOver waypoints", then I set the waypoint0 and waypoint5 as stopOver and the rest as passThrough, and yet, I receive the same error.
GET REQUEST
https://route.api.here.com/routing/7.2/calculateroute.json?app_id={APP_ID}&app_code={APP_CODE}&waypoint0=stopOver!-25.4327193,-49.2806026;;0&waypoint1=passThrough!-25.4392733,-49.2722581;;1&waypoint2=passThrough!-25.4367652,-49.2833011;;2&waypoint3=passThrough!-25.4327193,-49.2806026;;3&waypoint4=passThrough!-25.4327193,-49.2806026;;4&waypoint5=stopOver!-25.4392733,-49.2722581;;5&arrival=2019-09-09T07:10:00-03:00&mode=fastest;publicTransportTimeTable;motorway:0&improveFor=distance&language=pt-br&representation=navigation&metricSystem=metric&vehicletype=diesel,5.5
RETURN
{
"_type": "ns2:RoutingServiceErrorType",
"type": "ApplicationError",
"subtype": "InvalidInputData",
"details": "Time Table Transit Routing is only supported for two StopOver waypoints",
"additionalData": [
{
"key": "waypoint",
"value": ""
}
],
"metaInfo": {
"timestamp": "2019-09-10T13:40:27Z",
"mapVersion": "8.30.99.156",
"moduleVersion": "7.2.201935-5091",
"interfaceVersion": "2.6.68",
"availableMapVersion": [
"8.30.99.156"
]
}
}
as stated in the documentation, you can only use the arrival parameter when mode is set to publicTransportTimeTable. And this type of routing currently supports only two stopover waypoints (waypoint0 and waypoint1) and no passthrough waypoints.

Is there a way to get permanent link ids directly in HERE traffic flow result?

I want to use traffic flow data to enhance a route with traffic information like the jam factor.
The recommended way seems to get a route, download TMC tiles for all functional classes and areas of the route, and match the route links to the TMC codes in the traffic flow data, e.g. see How to use HERE Maps to develop custom routing algorithms? .
However, the traffic flow documentation (TrafficML_RealTime_Specification_v3.2.2.docx) mentions a tag "SHP/LID" in the Flow Item Description to contain the link id, which could simplify the whole process:
SHP/LID:
LinkID associated with the SHP reference. The linkID will be in
driving direction order; “F” represents travel direction FROM
reference node, “T” represents travel direction TO reference
node (For example, 123456789T or 987654321F).
In my API call I explicitly request shapes (responseattributes=sh) and receive them, but there is no "LID" field given.
https://traffic.api.here.com/traffic/6.2/flow.json?corridor=52.5396895,12.9778897;52.5394964,12.9782331;52.5390244,12.9769778;52.539078,12.976774;52.5392067,12.9762483;52.5395072,12.9750788;52.5396144,12.974714;52.5397754,12.974124;52.5400114,12.9732764;52.5405693,12.9723108;52.5409126,12.9719353;52.5415349,12.97068;52.5416744,12.9694784;52.5404727,12.9654121;52.5387347,12.9640496;52.5384343,12.9646397;52.5380695,12.9651332;52.5379193,12.965219;52.5370181,12.9656482;52.5359452,12.9659379;52.5349581,12.9661417;52.5339067,12.9663348;1000&responseattributes=sh,fc&app_id=xxx&app_code=yyy
{
"RWS": [
{
"RW": [
{
"FIS": [
{
"FI": [
{
"TMC": {
"PC": 10213,
"DE": "Berlin-Spandau",
"QD": "+",
"LE": 4.18578
},
"SHP": [
{
"value": [
"52.55838,12.96583 52.55761,12.96545 52.55705,12.9652 52.55641,12.96494 52.55588,12.96473 52.55577,12.96468 "
],
"FC": 1
},
{
"value": [
"52.55577,12.96468 52.55566,12.96464 "
],
"FC": 1
},
...
{
"value": [
"52.55935,12.96635 52.55838,12.96583 "
],
"FC": 1
}
],
"CF": [
{
"TY": "TR",
"SP": 120,
"SU": 121.78,
"FF": 105,
"JF": 0,
"CN": 0.99
}
]
},
Is there a way to receive permanent ids with the flow data?
There is a similar question and solutions.
Please have a look at below.
Why does not the TMC from traffic data match with the TMC from PDE layers LINK_TMC_FC?

Retrieving previously calculated route [HERE Maps] using RouteeId fails with RouteNotReconstructed error

I'm calculating routes based on user input. Then storing the routeId and any additional informations I need. But the shape of the road is something I need occasionally; when the user wants to get a preview of the road again.
Since I don't want to store all the points from shape I tried using getroute endpoint (https://developer.here.com/documentation/routing/topics/resource-get-route.html#resource-get-route) but I get this response:
{
"_type": "ns2:RoutingServiceErrorType",
"type": "ApplicationError",
"subtype": "RouteNotReconstructed",
"details": "Error is NGEO_ERROR_ROUTE_DESERIALIZATION",
"additionalData": [
{
"key": "error_code",
"value": "NGEO_ERROR_ROUTE_DESERIALIZATION"
}
],
"metaInfo": {
"timestamp": "2018-08-01T15:01:56Z",
"mapVersion": "8.30.86.150",
"moduleVersion": "7.2.201830-34436",
"interfaceVersion": "2.6.34",
"availableMapVersion": [
"8.30.86.150"
]
}
}
So the question is: why do I get the error? Following the API documentation https://developer.here.com/documentation/routing/topics/resource-type-error-route-not-reconstructed.html I can exclude wrong routeId (it works for routes saved e.g. today but not for the older ones).
The route was calculated using the same version (7.2)
Is the routeId stored only for a certain amount of time?
If so, how long?
RouteID changes with map version.
https://developer.here.com/documentation/routing/topics/request-route-information.html
You'd need to recalculate periodically to get up to date RouteIDs.

Wrong intent in Alexa Skill Request when using the simulator

I set up my intents using this intent schema:
{
"intents": [
{
"intent": "StartIntend"
},
{
"intent": "AMAZON.YesIntent"
},
{
"intent": "AMAZON.NoIntent"
}
]
}
My sample utterances look like this (it's german):
StartIntend Hallo
StartIntend Moin
StartIntend Guten Tag
Why does the Amazon Developer Console generate the following request, when I use the utterance "Yes" or "Ja"?
{
"session": {
"sessionId": "SessionId...",
"application": {
"applicationId": "amzn1.ask.skill...."
},
"attributes": {},
"user": {
"userId": "amzn1.ask.account...."
},
"new": true
},
"request": {
"type": "IntentRequest",
"requestId": "EdwRequestId...",
"locale": "de-DE",
"timestamp": "2017-02-17T21:07:59Z",
"intent": {
"name": "StartIntend",
"slots": {}
}
},
"version": "1.0"
}
Whatever I enter, it always is using the intend StartIntend.
Why is that? What have I forgotten / what have I done wrong?
The schema and utterance look correct.
I tried duplicating what you are seeing by performing the following steps:
Copied them as-is into a new skill on my account
Selected the North America region on the Configuration page.
Set the lambda to point to an existing lambda that I have. For testing purposes, I just need a valid ARN. I'm going to ignore the response anyways.
Then entered "Yes" into the service simulator
It indeed sent the Lambda the AMAZON.YesIntent.
So I conclude that there's nothing with the data you posted.
I tried entering Ja which resulted in the StartIntend, but I guess I would expect that since Ja is not "Yes" in North America.
Have you set the region to Europe, and entered a Lambda for the Europe region?
I talked about it with the Amazon Support. After some experiments it turned out, you have to write "ja" in lowercase. It seems to be a bug in the simulator itself.
When creating the skill in the Alexa Skills Kit, you need to choose the correct language i.e. German, see screenshot below.
Everything else seems to be correct.

Resources