Closes #1359 Adding pgr_dijkstra(combinations)

[mahmsakr]

Fixes #1359 .

Changes proposed in this pull request:

• gpr_dijkstra combination_sql signature
• documentation of the new function
• developer names

@pgRouting/admins

[cvvergara]

@mahmsakr Thanks for your contribution to pgRouting

[dkastl]

What is the difference between the new combinations SQL and the many-to-many?

Isn't many-to-many or other signatures possible to be used as combinations?

[mahmsakr]

Many-to-many does a cross product. So if the array of sources has [3, 5] and the array of targets has [7, 11], dijkstra is calculated for: 3 -> 7 3-> 11 5 -> 7 5 -> 11 The combinations SQL gives full control on which combinations are desired. For example, given the following query: SELECT * FROM pgr_dijkstra( 'SELECT id, source, target, cost, reverse_cost FROM edge_table', 'SELECT * FROM (VALUES (3, 11), (5, 7)) AS combinations (source, target)'); dijkstra will only be calculated for 3 -> 11 5 -> 7 Best regards, Mahmoud

…

On Tue, Jun 2, 2020 at 4:19 AM Daniel Kastl ***@***.***> wrote: What is the difference between the new combinations SQL and the many-to-many? Isn't many-to-many or other signatures possible to be used as combinations ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1360 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALMIXYJRZLTYIK3NNGRL42LRUROUJANCNFSM4NM7NJCQ> .

[dkastl]

@mahmsakr , thanks! Then I understand it right.

I was wondering if the new signature doesn't allow us to remove other signatures then, because they could be just special cases of the combinations SQL.

For example a distance matrix matrix of two source and target pairs could be written as 4 combinations. Even a standard A -> B route would be a case that consists of just one combination.

So instead of maintaining several signatures we could use the new signature as default, and there could be some helper functions for example to turn a many-to-many matrix into combinations.

[mahmsakr]

Hi Daniel, Your idea is technically correct. The combinations SQL signature has an equivalence to each of the three existing signatures. So it can express all of them, and give the same result. From a usability aspect, the other signature can be more flexible in certain cases. This is a factor that needs also to be taken into consideration. Best regards, Mahmoud

…

On Tue, Jun 2, 2020 at 4:57 PM Daniel Kastl ***@***.***> wrote: @mahmsakr <https://github.com/mahmsakr> , thanks! Then I understand it right. I was wondering if the new signature doesn't allow us to remove other signatures then, because they could be just special cases of the combinations SQL. For example a distance matrix matrix of two source and target pairs could be written as 4 combinations. Even a standard A -> B route would be a case that consists of just one combination. So instead of maintaining several signatures we could use the new signature as default, and there could be some helper functions for example to turn a many-to-many matrix into combinations. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1360 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALMIXYOKEXGVMWRHTCTH743RUUHNNANCNFSM4NM7NJCQ> .