Matching to Highway Lanes

[tilo]

Consider a DiMa computation where one endpoint resides on one specific lane of a highway. In our experience, the distance will correspond to a route that uses to exact same lane even if it is far longer than just going to a different lane on the same highway. Is there any way to turn off this feature with xDima? We are aware that switching to xRoute could resolve the problem.

I have attached an image for clarification. Here, we are interested in a route that would be very similar to air distance.

[Bernd Welter]

Hello Tilo,

I clearly understand the problem. It raises two questions in my mind:

• Who wants to start/stop a travel on a highway lane and why?
• Looking at the map: what criteria could help?

You already used xRoute to demonstrate the issue itself.
Changing to xRoute wouldn't resolve the issue.
The relevant topic is the proper "linking" point which would be the same for each and every relation.
Imagine we would change this linking point's coordinate in a way that "Waypoint1 to Waypoint2" is then as expected: I guess that the consequence is that "Waypoint2 to Waypoint1" is not correct anymore.

Maybe we can help if you give us more details about the usecase scenario (question 1).
Even the xserver.routing.SideOfStreetRestriction wouldn't help from scratch.

Bernd

[tilo]

Hi Bernd,

thank you for the swift reply.

• Who wants to start/stop a travel on a highway lane and why?
  We are estimating average distances between two zip code regions here by sampling several positions from each region. The exact position is not really relevant to us.
• Looking at the map: what criteria could help?
  Shifting the coordinates slightly usually helps (just a few 10 meters).

Changing to xRoute wouldn't resolve the issue.

We would be very happy with the following solution: Specify a center location and a radius for each endpoint and retrieve the shortest possible route that runs between each pair of circular areas. I believed this was already possible with xRoute but not with xDima.

Cheers
Tilo

[Bernd Welter]

About question/answer #1:
You mention zip codes. My first assumption was "shouldn't ZIP codes be located in urban areas?". Therefore I checked "1225 Budapest" with xServer1 and xServer2:
xServer1 : geocoding put's the coordinate in the city (populated area)
xServer2 : in fact this API positions the reference point close to the highway
Developer: same as xServer2 - the highway.

I forwarded this to colleagues from DEV - please stay tuned,

Bernd

[Bernd Welter]

Here's some more feedback from DEV:

1. Jochen describes the diference between xLocate1 / xLocate2 / Developer:

The way we determine the zip code reference points differs between xlocate1 and xLocate2 (Lucene):
In xLocate 2 we attach the zip code link to some kind of an average link position based on all links we have for the same zip code. In some rare cases highways could be attached to such a zipcode and this could drag the "average position" in the direction of a highway.

2. Frank gives some hints about how to deal with the highway linking:

Maybe OnRoadRouteLocation.considerAlternativeNearByRoads is what you are looking for.
This feature is not available in xServer1 so if you want to solve the challenge in xDima1 / xRoute1 you might want to apply the limitation to the proper network class (minimumNetworkClass) to 1 or 2. This will prevent the router from linking to a HIGHWAY. In xServer1 there's also AUTO_LINKING and further parameters available...

Best regards,
Bernd