Error trying to use more than 2 waypoints in new Here Routing API 7.2 - here-api

I have this annoying problem with the new Here Routing API 7.2:
If I want to use more than 2 waypoints (0 and 1) I get error as a responce from the server:
Request:
https://route.api.here.com/routing/7.2/calculateroute.xml?waypoint0=55.67395%2C12.41686&waypoint1=55.6452%2C12.52621&waypoint2=55.9552%2C12.52421&mode=fastest%3Bcar%3Btraffic:disabled%3BboatFerry:-1&language=en_US&verbosemode=0&alternatives=1&app_code=XXXXXX&app_id=XXXXXXXXXX&routeattributes=wp,sm,sc,sh,bb,lg,no
ERROR RESPONSE:
<ns2:Error xmlns:ns2="http://www.navteq.com/lbsp/Routing-Errors/1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" type="ApplicationError" subtype="NoRouteFound" xsi:type="ns2:RoutingServiceErrorType">
<Details>Error is NGEO_ERROR_INVALID_PARAMETERS</Details>
<AdditionalData key="error_code">NGEO_ERROR_INVALID_PARAMETERS</AdditionalData>
<MetaInfo>
<Timestamp>2016-02-18T15:30:21Z</Timestamp>
<MapVersion>8.30.61.154</MapVersion>
<ModuleVersion>7.2.66.0-1329</ModuleVersion>
<InterfaceVersion>2.6.21</InterfaceVersion>
</MetaInfo>
</ns2:Error>
If I take away the waypoin2 in above request it aswers ok:
Request:
https://route.api.here.com/routing/7.2/calculateroute.xml?waypoint0=55.67395%2C12.41686&waypoint1=55.6452%2C12.52621&mode=fastest%3Bcar%3Btraffic:disabled%3BboatFerry:-1&language=en_US&verbosemode=0&alternatives=1&&app_code=XXXXXXXXXX&app_id=XXXXXXXXXX&routeattributes=wp,sm,sc,sh,bb,lg,no,legs
OK RESPONSE:
<rtcr:CalculateRoute xmlns:rtcr="http://www.navteq.com/lbsp/Routing-CalculateRoute/4">
<Response>
<MetaInfo>
<Timestamp>2016-02-18T13:38:57Z</Timestamp>
<MapVersion>8.30.61.153</MapVersion>
<ModuleVersion>7.2.65.0-1222</ModuleVersion>
<InterfaceVersion>2.6.20</InterfaceVersion>
</MetaInfo>
<Route>
<Waypoint>
<LinkId>-840260969</LinkId>
<MappedPosition>
<Latitude>55.6739539</Latitude>
<Longitude>12.4166495</Longitude>
</MappedPosition>
<OriginalPosition>
<Latitude>55.6739499</Latitude>
<Longitude>12.41686</Longitude>
</OriginalPosition>
<Type>stopOver</Type>
<Spot>0.5252525</Spot>
<SideOfStreet>left</SideOfStreet>
<MappedRoadName>Hvissingevej</MappedRoadName>
<Label>Hvissingevej</Label>
<ShapeIndex>0</ShapeIndex>
</Waypoint>
<Waypoint>...</Waypoint>
<Mode>...</Mode>
<Shape>...</Shape>
<BoundingBox>
<TopLeft>
<Latitude>55.6739539</Latitude>
<Longitude>12.4158812</Longitude>
</TopLeft>
<BottomRight>
<Latitude>55.6408489</Latitude>
<Longitude>12.5263282</Longitude>
</BottomRight>
</BoundingBox>
<Leg>...</Leg>
<Summary xmlns:rtc="http://www.navteq.com/lbsp/Routing-Common/4" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="rtc:RouteSummaryType">
<Distance>11768</Distance>
<TrafficTime>951</TrafficTime>
<BaseTime>951</BaseTime>
<Flags>motorway</Flags>
<Flags>builtUpArea</Flags>
<Flags>park</Flags>
<Text>
..etc
Why does it not work with more that 2 waypoints???
This looks like a big fat bug to me, but I cant find anything about it on the here.com or anywhere on the internet... :((
THIS Request with 3 waypoints used to work in the old version 6.2:
http://route.nlp.nokia.com/routing/6.2/calculateroute.xml?waypoint0=55.67395%2C12.41686&waypoint1=55.6452%2C12.52621&waypoint2=55.9552%2C12.52421&mode=fastest%3Bcar%3Btraffic:disabled%3BboatFerry:-1&language=en_US&verbosemode=0&alternatives=1&app_code=bSU31J0m--3cnUyNdSj4cw&app_id=dj92lxIBAWPAwMtNxCgm&routeattributes=wp,sm,sc,sh,bb,lg,no
OK RESPONSE:
<rtcr:CalculateRoute xmlns:rtcr="http://www.navteq.com/lbsp/Routing-CalculateRoute/4">
<Response>
<MetaInfo>...</MetaInfo>
<Route>
<RouteId>
REM8tfQAAAHRkVz-Q9ZLQGgFhqxu1ShAAAAAYETWS0AAAADAUtUoQAAAAAAAAPB_AAAAAAAA8H-XourNKMKGp1dKLwEVoKaWrTWkAAEAAABcSi8BAQAAAOk1pAABAAAAAADA_wEAAAAAAMD_ZSl--Cc6kst_SH8JSB2PGaiMIQUIAAAAlEh_CQgAAABwhiEFCAAAAAAAAP4PAAAAAAAA_s9seQ_mg7mwYJAXWCYYxLg-_P8yOgx7Z_zGqIBBluHNBoM
</RouteId>
<Waypoint>...</Waypoint>
<Waypoint>...</Waypoint>
<Waypoint>...</Waypoint>
<Mode>
<Type>fastest</Type>
<TransportModes>car</TransportModes>
<TrafficMode>disabled</TrafficMode>
<Feature weight="-1">boatFerry</Feature>
</Mode>
<Shape>...</Shape>
<BoundingBox>
<TopLeft>
<Latitude>55.9671898</Latitude>
<Longitude>12.4158802</Longitude>
</TopLeft>
<BottomRight>
<Latitude>55.6408501</Latitude>
<Longitude>12.5335598</Longitude>
</BottomRight>
</BoundingBox>
<Leg>...</Leg>
<Leg>...</Leg>
<Summary>
<Distance>62581.0</Distance>
<TrafficTime>2916.0</TrafficTime>
<BaseTime>2916.0</BaseTime>
<Flags>motorway</Flags>
</Summary>
..etc
Can please someone help me solve this?

The combination of a via point (using the waypoint2 parameter) and alternative routes (using the alternatives parameter) is not supported within the Routing API as a single request.
The Routing API reference states:
alternatives
Maximum number of alternative routes that will be calculated and
returned. Alternative routes can be unavailable, thus they are not
guaranteed to be returned. If at least one via point is used in a
route request, returning alternative routes is not supported.
So you can either find:
a single route from A to B to C or
a multiple alternate routes A to B without intermediate waypoints.
Of course if you make two separate requests you could find:
A to B with alternative routes then
B to C with alternative routes

Related

Why the parameter TransitRadius in HERE Routing API with public transport do not change the response

Trying to use the parameter TransitRaduis in the routing API of HERE. It works well with 'car mode' but when using it with 'public transport' it seems to me that it changes nothing !
So setting one waypoint with the following three differents ways, gives the same result !
&waypoint0=geo!37.7914050,-122.3987030
&waypoint0=geo!37.7914050,-122.3987030;50
&waypoint0=geo!37.7914050,-122.3987030;500
To request a public transport route using the CalculateRoute service you need to specify a departure time as
https://route.api.here.com/routing/7.2/calculateroute.json?app_id={YOUR_APP_ID}&app_code={YOUR_APP_CODE}&waypoint0=geo!52.530,13.326&waypoint1=geo!52.513,13.407&departure=now&mode=fastest;publicTransport&combineChange=true
For further details kindly go through the documentation
https://developer.here.com/documentation/routing/topics/request-public-transport-routes.html
Good Luck !

HERE LinkId from route not found in PDE (Platform Data Extension)

UPDATE: It's happening again, also with Fleet API. Please see additional examples at end of the post.
I'm using HERE's REST API to calculate a route, then ask for additional data for each link / route segment by querying HERE's Platform Data Extension (PDE). This usually works fine, but now I've run into a link id that is not recognised by PDE.
Are these services not in sync, or am I doing something wrong?
I didn't have any issue in the past weeks, and it still works fine for most link ids, so this could either be a new problem or a very singular issue. I searched in the HERE API documentation and on Stackoverflow, but couldn't find anything related.
Route request (A24 Berlin towards Hamburg): https://route.api.here.com/routing/7.2/calculateroute.json?waypoint0=geo!52.7091,13.0356&waypoint1=geo!52.7193,12.9608&mode=fastest;car;traffic:disabled&representation=navigation&app_id=xxx&app_code=yyy
The json response (below) contains a link with permanent id 1199057935 at Anschlussstelle Kremmen.
The PDE request gives an empty response: https://pde.api.here.com/1/index.json?layer=ROAD_GEOM_FCn&attributes=LINK_ID&values=1199057935&app_id=xxx&app_code=yyy
{"Layers":[]}
Instead, I would expect the data of the containing tile, e.g. what I get for 1199057936
{"Layers":[{"layer":"ROAD_GEOM_FC1","level":9,"tileXYs":[{"x":548,"y":405}]}]}
I also tried the PDE request with ROAD_GEOM_FC1 and prefixing the id with + (values=+1199057935). Other link ids of the route return the expected tile information.
For completeness, here's the link's json from the routing response:
{
"linkId":"+1199057935",
"shape":["52.7175629,12.976613","52.7177131,12.9749393"],
"firstPoint":28,
"lastPoint":29,
"length":114,
"remainDistance":1095,
"remainTime":39,
"nextLink":"+1199057936",
"maneuver":"M2",
"speedLimit":33.3333359,
"dynamicSpeedInfo":{"trafficSpeed":16.3888893,"trafficTime":7,"baseSpeed":27.5,"baseTime":4,"jamFactor":5.7118645},
"flags":["motorway"],
"functionalClass":1,
"roadNumber":"A24",
"timezone":"+0100",
"roadName":"",
"consumption":0,
"_type":"PrivateTransportLinkType"
}
UPDATE 2019-05-27:
I get a route that contains link id 1239826684 from https://route.api.here.com/routing/7.2/calculateroute.json?waypoint0=geo!52.5066,13.4299&waypoint1=geo!52.5282,13.4265&mode=fastest;car;traffic:disabled&representation=navigation&app_id=xxx&app_code=yyy
Using fleet endpoint redirects to same call as above, including link id 1239826684: https://fleet.api.here.com/2/calculateroute.json?waypoint0=geo!52.5066,13.4299&waypoint1=geo!52.5282,13.4265&mode=fastest;car;traffic:disabled&representation=navigation&app_id=xxx&app_code=yyy
PDE returns [] for that link id: https://pde.api.here.com/1/index.json?layer=ROAD_GEOM_FCn&attributes=LINK_ID&values=1239826684&app_id=xxx&app_code=yyy
Fleet API returns [] for that link id: http://fleet.cit.api.here.com/1/index.json?layer=ROAD_GEOM_FCn&attributes=LINK_ID&values=1239826684&app_id=xxx&app_code=yyy
Seems the underlying geo-data is not in sync, and using different APIs does not help. Any other solution?
You can try Fleet telematics group of API's over basic routing and PDE as Fleet Telematics provides whole routing solution .
Please find the below API request which is giving expected response for the id-1199057935
http://fleet.cit.api.here.com/1/index.json?layer=ROAD_GEOM_FCn&attributes=LINK_ID&values=1199057935&app_id=xxxx&app_code=yyyy
Response :
{
Layers: [
{
layer: "ROAD_GEOM_FC1",
level: 9,
tileXYs: [
{
x: 548,
y: 405
}
]
}
]
}
for more information kindly go through the below documentation
https://developer.here.com/documentation/fleet-telematics/api-reference.html#operation%2FindexJSONUsingGET
Hope this will help.

When to use Nancy StaticConfiguration.DisableMethodNotAllowedResponses

We recently changed some Nancy routes, and had a test fail with a 405 MethodNotAllowed.
After debugging through Nancy we came across the StaticConfiguration.DisableMethodNotAllowedResponses property. Setting this to true means the test fails with a 404.
My question is, when / why is it preferable to return 405 rather than 404? I can understand this makes sense if for example you tried to POST to a route which only supports GET, however I don't think that is the same as our scenario.
Before route change:
Get["/web/api/somepath/{param1}/{param2}"]
Post["/web/api/somepath/{param1}"]
After route change:
Get["/web/api/somepath/{param1}/{param2}"]
Post["/web/api/somepath/{param1}/{param2}"]
Our (out of date) test is POSTing to /web/api/somepath/param1Value
Maybe this is just an edge case related to how Nancy scores route matches?
Additional note: I noticed in DefaultRouteResolver.Resolve() when the following line runs, allowedMethods contains only GET (I am not able to debug into the RouteResolverTrie code for some reason):
var allowedMethods = this.trie.GetOptions(pathDecoded, context).ToArray();
(To clarify, I would expect allowedMethods to contain GET and POST).

meanuver's direction attribute in Routing service's Response

I'm testing the routing service in API 3.0 and I canĀ“t find the attribute "direction" in meanuver, this attribute exists in API 2.5, it attribute indicates the direction of the instruction for example "forward, straight, right.."
Does anybody know if there is some attribute that indicates the direction of the instruccion in the API 3.0?
Thanks.
As discussed in the migration guide, there is a fundamental shift in the use of services between the 2.x and 3.0 Here Maps APIs for JavaScript - previously the Manager objects decided a fixed format of for the request to the underlying REST APIs and encapsulated the response. Whereas now the full range of parameters can (and should) be set by the developer.
In the routing case the question is not so much "What can the 3.0 API do?" as "How was the REST request fixed by the 2.x API and how can I mimic the parts of that request that I need?".
Looking at the Legacy API playground simple routing example, the underlying REST request is:
http://route.cit.api.here.com/routing/7.2/calculateroute.json?routeattributes=shape&maneuverattributes=all&jsonAttributes=1&waypoint0=geo!52.516,13.388&waypoint1=geo!52.517,13.395&language=en-GB&mode=shortest;car;traffic:default;tollroad:-1&app_id=APP_ID&app_code=TOKEN...
This can be reproduced precisely in the 3.x API with the following:
var router = platform.getRoutingService(),
routeRequestParams = {
routeattributes: 'shape',
maneuverattributes: 'all',
jsonAttributes :'1',
waypoint0: '52.516,13.388',
waypoint1: '52.517,13.395',
language: 'en-GB',
mode: 'shortest;car;traffic:default;tollroad:-1'
};
router.calculateRoute(...);
The next question here is what parameters do you really need for your application? The list for the calculateRoute endpoint of the underlying REST Routing 7.2 API includes the description of maneuverattributes showing how to obtain directions - with maneuverattributes=...,direction
So it may be possible to reduce the routeRequestParams to something like:
var routeRequestParams = {
routeattributes: 'shape',
maneuverattributes: 'position,length,direction',
...etc...
So in summary, you'll need to consult the REST Routing API documentation to define what you need first, before passing those parameters into the query of the Maps API for JavaScript calculateRoute() call.

Defining Multiple Proxy Endpoints

This is probably an unusual case as I'm trying to define a new Proxy Endpoint in an API Proxy.
Let's say I have a default Proxy Endpoint with a Conditional Flow to match /myflow and action == GET and that works fine.
then I defined a new Proxy Endpoint (new_endpoint) with its own Conditional Flow to match /mynewflow and action == GET.
/mynewflow works fine and goes to the new_endpoint as expected.
however
/myflow is also now going to new_endpoint! (i used the Trace tool and confirmed it).
Here is the HTTP Proxy Connection Settings for both:
<HTTPProxyConnection>
<BasePath>/v2</BasePath>
<Properties/>
<VirtualHost>default</VirtualHost>
<VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
<RouteRule name="default">
<TargetEndpoint>default</TargetEndpoint>
</RouteRule>
Is this expected? If it is, how do I make sure that /myflow routes to default Proxy Endpoint?
Looks like you're missing your <RouteRule> in your proxy. Just like the ConditionalFlow, you need a second RouteRule to point to your new target, which would look something like this:
<HTTPProxyConnection>
<BasePath>/v2</BasePath>
<Properties/>
<VirtualHost>default</VirtualHost>
<VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
<RouteRule name="new_endpoint">
<TargetEndpoint>new_endpoint</TargetEndpoint>
<Condition>(proxy.pathsuffix MatchesPath "/mynewflow")</Condition>
</RouteRule>
<RouteRule name="default">
<TargetEndpoint>default</TargetEndpoint>
</RouteRule>
You don't need to include individual verbs, because we can assume everything to /mynewflow is going to go to the new_endpoint target.
Also, make sure you put the conditional RouteRule above the default RouteRule -- Apigee will match the first one so if default (no condition) is first, you will never match the condition on the remaining rules.
I learned something today: apparently it's HttpProxyConnection/BasePath dictates which Proxy Endpoint is selected
as soon as made sure that the BasePath is different for both endpoints, routing started the way I expected it to.

Resources