Fast calculation of xDima-createDistanceMatrix even though HPRN is georestricted for another country

[CAPcargo]

Hi,

We have an unexpected behavior from our PTV server which we cannot explain and we need a bit of help in finding an answer

In short, this is what`s happening:

I select 50 orders from the Netherlands and I intentionally choose a HPRN (for the distance matrix creation) that was generated with a geo-restriction for Spain.
So in this case I`m expecting that the xDima-createDistanceMatrix API call will take the same amount of time as if I was calling it without HPRN (because it doesn`t have the necessary data to make the calculations fast), but instead I do get a fast response.

These are the details of our test case:
1) First we do a xDima-createDistanceMatrix API call without a HPRN defined so we can measure how much time does it takes, and the result is 30 seconds for 50 orders (which is expected for a HPRN-less API call).

2) Then we use the same 50 orders (all from the Netherlands) and we do a new xDima-createDistanceMatrix API call with a HPRN which was created with a geo-restriction for Spain. So here the result gets back in 652 milliseconds which I would have expected if the HPRN was created with a geo-restriction for the Netherlands.

So the question is how does the PTV server calculates the result for the Netherlands orders so fast?
Maybe there is some default HPRN file for these case, or we`re not noticing some detail?

I`ve attached the HPRN creation request,DIMA creation request/response, xTour request/response files, and some screenshots as well so you can take a look at the details.


Looking forward to your reply,
Marko Arsovski

[Bernd Welter]

Here's some analysis I did with your dimas:

• The "ES"-HPR based dima (1st row) contains 2'352 airline based approximations. That 49²-49 : all relations besides then diagonal ones. Be aware that the purpose of the DIMA call is to provide traveltimes and distances - even if the relations need to be extrapolated due to "wrong geography".

  

  Overview of your dimas

• Do not mix this with "violated" relations where the geometry isn't the problem but the restrictions on roads (returns routing based quality, directDistance will show up as FALSE but the VIOLATED is TRUE)

  

  Analysis of the HPR dima

• The Conventional dima (2nd row) seems to contain routed quality.

  

  Analysis of the CONV dima.

[CAPcargo]

Hi Bernd,

Thanks for your response.

If I understood you correctly, you`re explaining that in our case the calculations are done based on airline distance?

Based on this assumption, I`ve checked the distanceMatrixOptions routing type property and we have it set to "HIGH_PERFORMANCE_ROUTING", which according to the documentation:
"If it is used as input and no such network which fits the current profile settings is available an exception is thrown."


So I was expecting that an exception will be thrown in our case (which is actually our wanted behaviour), but it doesn`t happen.

So, did I understand you correctly, and if yes then how can we make the exception to be thrown?

RoutingType documentation: https://xserver2-dashboard.cloud.ptvgro ... outingType

Regards,
Marko Arsovski

[Bernd Welter]

Hello Marko,

"matching network" refers to the profile and routing options such as

• Request / stored profile (with it's >100 properties)
• Geographic restrictions including allowedCountries / forbiddenCountries, searchSpaceBounds
• TimeConsiderationMode

and last but not least within the given scope.

So in your case the search was successfull - the HPR with the ID "1350f8b9-f00b-4e8f-abc8-a9d663c54e46" satisfies the dima request criteria.
But as the involved coordinates are outside the "geography" the dima routings escalate to the airline based approximation.

Maybe we should discuss your requirement 1:1...

Bernd

[CAPcargo]

Hi Bernd,

Sure, we can make a call. I`ll send you an email with the details.

Regards,
Marko Arsovski