trafficEngine Query by GeoCorridor breaks after only a few vertices.

[StefanTiess]

Hi,

I want to use the TrafficEngine to look for Traffic Incidents along the route, so I can give drivers a heads up. However, if i run the queryForIncidents call with a GeoCorridor, i will quickly run into problems: If the geoCorridor has a little more than 100 vertices (which happens already after very few kilometers) i get the following exception: 17425-17538/com.myapp.app.debug E/traffic: [ERROR] traffic - Traffic error: web::http::http_exception, what: {"title":"Malformed request","status":414,"code":"E608045","cause":"Request URI is too long. Actual length is 2324 while maximal allowed is 1000","action":"request must adhere to API specification","correlationId":"036d975c-a57b-4bcc-817a-3f711ff55f3d"} ,value: 414

At the same time, the TrafficIncidentsOnRoute i can fetch for the sections of a route are rather useless: as they contain no information whatsoever about the location of the incident and not even an incident ID so I can query additional information about the incidents. i am not quite sure what the purpose of this object in its current shape should be.

[HERE-SDK-Support-Team]

Unfortunately, this is not a bug nor an exception, what you get is the error FAILED_TO_RETRIEVE_RESULT from the engine. And that is because the GeoCorridor is too large. The API Reference says: "The maximum length for the corridor is 500000 meters and the maximum radius is 5000 meters."

Indeed, it seems to happen already after a few kilometers, but depends also on the corridor radius/halfWidthInMeters. We will check if the documentation needs to be updated.

Regarding the TrafficIncidents: You should get all details, including location and ID:

Log.d(TAG, "1st coord: " + trafficIncident.getLocation().polyline.vertices.get(0));
Log.d(TAG, "ID: " + trafficIncident.getId());

Please check also the traffic example app, that shows how to get such details from an incident object. If you still do not get these details, please let us know. Thanks!

[StefanTiess]

Hi datasun, I can't imagine this is expected behavior. The halfWidthInMeters of my corridor is set to 1 and 100 vertices are just about 2 to 4 kms, far away from the 500kms of the specifcations. And what I seem to get is not that the engine issues an failure, but that the request does not even get through as the url is too long.

Concerning the second Point I do not mean the TrafficIncident but the TrafficIncidentOnRoute that would perfectly suit my use case, but does not contain a polyline, an id or any other helpful information: https://developer.here.com/documentation/android-sdk-navigate/4.10.2.0/api_reference/com/here/sdk/routing/TrafficIncidentOnRoute.html

[HERE-SDK-Support-Team]

Hi Stefan, yes, this is correct. Short routes of a few kilometers length can already fail. As I wrote above, we will check if the documentation needs to be updated. Of course, we will also check if there may be another issue. We will look into this.

If you handle the callback correctly like shown in the traffic example app, the engine will report this as failure. Under the hood, indeed the request does not go through, because the URL is too long. This is what you see (in addition) in the logs.

Regarding the second issue: This is then a different topic. There are three ways:

1. Query traffic incidents along a route with TrafficEngine. => This provides full traffic details.
2. Get limited traffic incident information directly from the route's sections.
3. Get traffic flow speed info directly from the route via section.getTrafficSpeeds().

The TrafficIncidentOnRoute class provides not the full data as the TrafficEngine, and it's a known problem that the ID is not present - at least for now, unfortunately. The exact location is also missing, as the use case is rather to indicate this per section (for which the location is known). Eventually, this can be optimized for one of the next HERE SDK releases, but I cannot promise this.

[HERE-SDK-Support-Team]

@StefanTiess The length of supported GeoCorridors has been improved. With release 4.11.1 longer routes should be possible. Which means that the statement in the documentation should work now as expected.