pick & Deliver

[cvvergara]

The soon to be pick and deliver functionality is available for:

• discussion
• test

Code on develop branch sketches of the documentation

related issues/discussions: #774 time types #520 parameters names #443 distance matrix #442 parameter for number of iterations #441 rename function #439 enhancement ideas

Some TODO:

• [ ] Decide functions names
  • [ ] for euclidean
  • [ ] for matrix
• [ ] Decide functions parameters names
  • [ ] for euclidean
  • [ ] for matrix
  • [ ] update code based on decision
  • [ ] update documentation based on decision
• [ ] Decide orders_sql column names
  • [ ] for euclidean
  • [ ] for matrix
  • [ ] update code based on decision
  • [ ] update documentation based on decision
• [ ] Decide vehicles_sql column names
  • [ ] for euclidean
  • [ ] for matrix
  • [ ] update code based on decision
  • [ ] update documentation based on decision
• [ ] Decide return column names
  • [ ] for euclidean
  • [ ] for matrix
  • [ ] update code based on decision
  • [ ] update documentation based on decision

[cvvergara]

@dkastl @robe2 I working on the documentation of pick & deliver. I dont feel very exited with the result column names I made:

• too long,
• to much _time
• finding difficult to explain

Currently for both I have the same columns,

Please see the examples. http://docs.pgrouting.org/dev/en/pgr_pickDeliverEuclidean.html#signatures http://docs.pgrouting.org/dev/en/pgr_pickDeliver.html#signatures

[cvvergara]

I also dont want it to be filled with acronyms, unless they are in spanish ;)

[woodbri]

I think these column names are fine. It is easy to understand what each column means. I don't think they need to be shortened.

On 6/6/2017 1:14 PM, Vicky Vergara wrote:

@dkastl https://github.com/dkastl @robe2 https://github.com/robe2 I working on the documentation of pick & deliver. I dont feel very exited with the result column names I made:

• too long,
• to much |_time|
• finding difficult to explain

Currently for both I have the same columns,

Please see the examples. http://docs.pgrouting.org/dev/en/pgr_pickDeliverEuclidean.html#signatures http://docs.pgrouting.org/dev/en/pgr_pickDeliver.html#signatures

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pgRouting/pgrouting/issues/791#issuecomment-306555184, or mute the thread https://github.com/notifications/unsubscribe-auth/AAxJggQ67MrXkyBImP6aGSXVNuARBhfNks5sBYkIgaJpZM4NfTQN.

---

This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

[cvvergara]

ok, then that takes care about the long and the _time but its still difficult to explain with those names

[cvvergara]

This is a sketch: http://docs.pgrouting.org/dev/en/VRP-category.html#id2

(sorry, gave you a link of my computer)

[dkastl]

I think pgr_pickDeliver sounds good, but pgr_pickDeliverEuclidean feels like there will be longer variations in the future.

Would it be possible to make "euclidean" a boolean argument in the pgr_pickDeliver function, or is this a bad idea?

[PayasR]

@dkastl that doesn't really sound right. Couldn't there be a network-distance variation in the future? Or would that be subsumed by the matrix distance?

[woodbri]

@PayasR Yes, network distance would be handled by the matrix. Euclidean is only a convenience because a lot of the classical benchmarks are based on Euclidean distance. Internally, I think it computes a matrix, but the input is different for the two function signatures.

[cvvergara]

I kind of followed the TSP, there is the euclidean version which is the "classical benchmark" and the one that accepts a matrix like the ones that are generated by any of the functions in this category: http://docs.pgrouting.org/dev/en/costMatrix-category.html

This are the pages that I am working on:

http://docs.pgrouting.org/dev/en/VRP-category.html http://docs.pgrouting.org/dev/en/pgr_pickDeliverEuclidean.html http://docs.pgrouting.org/dev/en/pgr_pickDeliver.html

@dkastl I dont know, Not so sure, because the data given as input is quite different the inner queries, and right now, in the matrix version I am returning the type of the stop, but not the id, that in the matrix version might be very useful. and in postgresql you can not have an overload with the same input parameters, different output parameters.

I left the shorter name for what I feel will be the most used version of the function for people dealing with "street data" and the long name for more "theoretical" people.

[dkastl]

@cvvergara please tell me, if I'm wrong, but my understanding is, that the functions, that use an Euclidean distance for the distance matrix, still use a distance matrix for the optimization. The only difference is, that it doesn't need to be specified but is handled internally.

So let's say for example, pgr_pickDeliver has 4 arguments with the last one being the distance matrix, in case the distance matrix is missing, couldn't we just assume, that euclidean distances should apply?

The only problem I see here is, that for euclidean distance computation location information is necessary, but in case a distance matrix is provided, we don't need to care about locations, right?

[woodbri]

@dkastl technically it is possible to add additional parameters and are only used in some cases, and can be set to NULL in other cases, but this makes documenting the command much more difficult and leads to ambiguous interpretation of the command. For example what if the inter query has locations for the pickups and deliveries and the user include a distance matrix. Which one do we use? We can obviously make up some arbitrary rules but then the user needs to remember the rules. Vicky has done a great job keeping the commands simple and purposeful. I don't see a problem have two commands.

[cvvergara]

@dkastl No, the euclidean version don't use a matrix, the distance is calculated on the fly as needed. So its "processing" time consuming, the matrix version is more memory consuming.

This is an example of a function parameter based documentation: http://docs.pgrouting.org/2.4/en/pgr_trsp.html#trsp

I dont know if you remember how much was discussed to have pgr_trspViaVertices & pgr_trspViaEdges names, they were named during developing stage pgr_trsp also. I can not imagine if pgr_trsp name was kept on those functions: sometimes returns pgr_costResult sometimes pgr_costResult3; user has to check based on the parameters which of them its returning. sometimes id1 is node id sometimes id1 is route id and the node id is on id2.

with the different name:

• the name has meaning
• the user expects a different kind of result, (even a name change of on the columns returned with the types constant is a different output).

Unfortunately, even that on the "outside" the functions have different names, the inside is the same which means that the problem is hidden to the user but it still there. There, you can see there are 4 functions with name my_dijkstra, which one belongs to which of the original four pgr_trsp is still a mystery. To make matters worse: this my_dijkstra makes a call to another my_dijkstra and its not even a recursive function.

Some consequences of the practice "name all the functions with the same name" (the same name is internal, but the consequences are external): https://github.com/pgRouting/pgrouting/tree/master/src/trsp/doc

[dkastl]

@cvvergara OK, I think I got it ... at least partially ;-) Let's try to make function names as self-explaining as possible, so users don't have to lookup a dictionary to pick one. If they become a bit long, it's probably still the better option.

[cvvergara]

@dkastl FYI: I created http://docs.pgrouting.org/gsoc2017/en/index.html I will be using that for posting the progress I make on the pick & deliver documentation so that branch develop does not get disturbed so often. Also there I will be posting the students documentation. I made a little progress here: http://docs.pgrouting.org/gsoc2017/en/VRP-category.html#introduction Not in the inner queries but here yes: http://docs.pgrouting.org/gsoc2017/en/VRP-category.html#description-of-the-result-todo-disussion-euclidean-matrix

[cvvergara]

As pickDeliver wont be part of 2.5 I cleared the mileston, discussion is still open